JaSST'16東京(2)「テストプロセス改善技術から探るテストの改善とは」
2016/3/8(火)~9(水)に開催されたソフトウェアテストシンポジウム'16東京(JaSST'16 Tokyo)に参加しました。私が参加したセッションの内容で印象に残ったことを数回に分けて書いてみます。
JaSST'16 Tokyo 企画セッション:「テストプロセス改善技術から探るテストの改善とは」
(0)セッションの資料
下記、JaSST'16東京のサイトに掲載されています。
http://jasst.jp/symposium/jasst16tokyo/report.html#plan2
(1)テスト改善技術比較
(1-1)TMMi
- 成熟度モデル。
- 未達成のところが可視化できること。
(1-2)TPI Next
- 自己評価と自己評価に基づく自己改善であり、プロセスだけを評価するのではない。
- 16のキーエリアを評価。
- プロセスではない。
- 3つのグループ
- ステークホルダーとの関係
- テスト管理
- テスト業務の専門性
- チェックポイントの塗りつぶし状況から改善の計画が立てられる。
(1-3)ISO33063
- アセスメントモデル
- ISO29119-2
- 対象プロセス
- プロセスに対して当てはまっているか?
- ISO/IEC33020
- プロセス測定方法
- ISO33000系:アセスメント関係
- WTO/TBT協定
- 技術障壁があってはならない
(1-4)TQM
- JIS9005を参考に...
- すべての質を上げる(お客さんだけでなく組織も)
- 明日から少しずつ改善(工夫)
- ベストプラクティスをみんなで取り組む
- おかしさをパターン化する
(2)議論:テスト改善技術の導入
- プロセスだけじゃダメ。
- ○○の達成度やキーエリアを定義してみる。が、あるものを利用すると楽かも。
最後の最後でカスタマイズすると、各々の組織のTPI NEXTになるのでは? - ISO33063は、アセスメントするのみ。
どうするかは別。 - TMMi
進め方は各組織で違う - CMMIはプロセス?
(3)安達氏からの分析
- モデル自体が難しい
TPI NEXT:チェックリストに回答するところからやってみては? - 反対派
- プロセス標準化にコンセンサスできるのが大切。
- 尖ると開発などと上手くいかない。
- 自分たちが何に困るかを共有するのが大切
- 手法や手段より、問題に着目すべき
- 困ったときに考える
困っていることを認識し、環境をつくると勝手に改善する(場作り)。 - モチベーションがない
- 他プロセスとのつながりが?
所感
私が本セッションに参加した目的は、テストプロセス改善の考え方やアプローチはどのようなものがあるか知るためです。製造業系な企業だとTQMが親和性がありそうですが、TMMiやTPI Next、ISO33063で開発現場で実践できそうなところがあると思います。
知見のポインタとして、勉強会コミュニティやワークショップでslideshare(例えば、テストプロセス改善モデルの最新動向(山崎氏@第14回SPIトワイライトフォーラム)やTPI NEXT ざっくり概要(池田氏@長崎IT技術者会 第7回勉強会)、TPI NEXT入門(井芹氏@WACATE2015冬)、)の資料がまとめられていますので、概要を理解しつつ、文献にあたってみようと思います。
その前に、「困った、どうしよう・・・。」という方が開発チーム内外でみつけることが必要ですが...
JaSST'16東京(1)「Software Test Challenges in IoT devices(IoTデバイスにおけるソフトウェアテストの課題)」
2016/3/8(火)~9(水)に開催されたソフトウェアテストシンポジウム'16東京(JaSST'16 Tokyo)に参加しました。私が参加したセッションの内容で印象に残ったことを数回に分けて書いてみます。
基調講演「Software Test Challenges in IoT devices(IoTデバイスにおけるソフトウェアテストの課題)」Jon Hagar(Grand Software Testing)
(1)Pattern1:モデルベーステスト
- UML
UTPの拡張 - 適用が進んでいる分野
電気通信/金融/自動車/航空宇宙 - 自動テストと組み合わせる
- ハードウェアテストする前にモデルでテスト
全部で無いがかなり自動テストできる
(2)Pattern2:数学ベース
- データ分析
数学が必要 - サンプルの問題(Androidの場合)
- 市場のセグメント
- アプリは動くはずだが、違うデバイスでもテストするか?
- ルータ、通信チャンネル、プロトコルを組み合わせるとものすごい量になる。
- Statistical Math Tool:ツールを勉強しよう!
- 組み合わせテスト:PICTなど
- 実験計画法:Taguchi method
- Fazzテスト
- 統計的サンプリング:ビッグデータの専門家の学習ツール
- ブラックボックステスト:境界値/ドメイン分析
(3)Pattern3:スキルや経験ベーステスト
- 探索的テスト
- 後援者が直感でテスト:テスターが知っているパターン
- 仮説を立てる→実験計画
- 性能テストも探索的テスト
- クリエイティブなテスト
- Attack:ソフトウェアの型紙/デザインパターン
- 探索的テストは、ハードウェアテストにも使える
- IoTでの探索的テスト
- 素早いフィードバック
- サンプリング:"Exploratory Software Testing"にもアタックパターンがある
(4)Pattern4:標準ベーステスト
- IEEE1012-2012
- ISO29119
- OMG UTP
(5)これから
- IoTが進化すると、アタックパターンも変わる。
- Seruity and Privacy
Jeepのハッキング - The Current Security Situaltion
- 議会でも問題に
- セキュリティ問題
- 359のうち、88が高リスクの問題
- Security Errors
- セキュリティアタック
- プライバシー:セキュリティとは違う
- 解釈によっては、個人情報をアクセス
- Testing Option for Connectivity
- ミスから学ぶ
- 対応を早くする
- すぐに修正:数分や数日の世界
所感
世界的トレンドや技術の進化により、製品の取り巻く世界が変化する。これまで、CPM(Copy&Paste Modify)法でテスト仕様として通じていたが、今となっては弾の無駄遣いで無力化する。日々、開発技術もテスト技術も進化が必要だと思う。3~10年先の世界を想像しつつ、技術書から得られた知見から開発現場でじわじわと試行して、得られた結果から次に工夫することを思考することを続けよう。
ピクサー展を通じて思ったこと
「トイ・ストーリー」など映画の制作過程で描かれていた展示物を鑑賞して思ったことは、ソフトウェアテストやレビューに応用できそうなネタがあることです。具体的には下記3点です。
- キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。
- キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。
- ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。
1.キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。
私がテスト分析するときは、テスト実行のイメージが具象化するまで、製品と製品の周りの世界を裏紙にポンチ絵で描いては捨ててを繰り返しています。通信機能を有するソフトウェアの場合、送信と受信のやりとりをハンドシェイクのように描いて、開発者にソフトウェアで実現したいことを確認しています。後々、テスト条件で抜けや誤りが無いよう、テスト実行して確認したいことを満たせるようなテスト仕様へブラッシュアップします。
2.キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。
外部仕様に記載されていることを「○○であること」とコピー&ペーストして内容を少し変えただけのテスト仕様にするのではなく、たとえば機能Zの設定Aと設定Bのパラメータが連動しているので、設定Aが変化したとき設定Bがどう変化して、機能Zはどうふるまうのか、外部仕様の要素を分解して要素間の関係を確認してから、機能αと機能Zの関係を確認しています。
3.ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。
外部仕様でお客様の利用シーンが上手く描けていないだけでなく、誤っていたり、機能として意味がなかったりするので、1.のポンチ絵をフローにしてから「機能Zは、□□のふるまいをして、ユーザーは△△という出力を提供しますか?」といった質問を繰り返しながら、開発工程の早い段階で欠陥を発見するようにしています。
さいごに
自分の興味あるものや過去に学問として学んだこと、趣味といった自分の活動から、ソフトウェアテストに限らず開発全般で応用できることがありますので、ソフトウェアテスト(開発全般)が楽しくないと嘆くよりは一味工夫してみて、ソフトウェアテスト(開発全般)が楽になったりミスが減ったりして、やってみてよかったと感じることも大切だなと思いました。
「探索的テストで工夫したこと」(5)総括
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分けて書きましたが、今回が最後です。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
masaoapril.hatenablog.com
masaoapril.hatenablog.com
全体像(再掲)
図中の凡例は、下記5点です。
- 白地の四角
抽象度:低の成果物 - 白地の円
抽象度:低のプロセス(行動、やること) - 黒地の四角
抽象度:高の成果物 - 黒地の円
抽象度:高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度:低の成果物)を集約した情報
なお、ET:"Exploratory Testing(探索的テスト)"と略称しています。
総括
探索的テストで具体的に行っていることをステークホルダに理解頂くため、1枚絵で表現できないか2年程検討を重ねました。1枚絵を描いてみると、自分が考えていることが俯瞰できるので、「独自に工夫していること」「工夫の余地があるところ」「上手く表現できないこと」が明確になったので、さらに工夫すべきことや自分が弱いところが何か明らかになったと思います。
1枚絵を描くことは、探索的テストに限らずスクリプトテストや開発全体で明日以降に工夫することもできますので、技術の棚卸しに最適です。
一言で探索的テストと言うが...
これまでのソフトウェアテストシンポジウム(JaSST:Japan Symposium on Software Testing)で探索的テストに関する発表がありますが、各々で取り組まれている探索的テストは私が1枚絵で描いたものと違うところもあるし、共通するところもあるかもしれません。製品の分野も異なるし、開発の背景も千差万別ですから様々な形があると思います。各々の違いを認めながら、開発で工夫できることを切磋琢磨できればと思いますので、忌憚のないご意見を頂ければ幸いです。
「探索的テストで工夫したこと」(4)探索的テスト実施後:学習
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
masaoapril.hatenablog.com
[3]探索的テスト実施後:学習
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度:低の成果物 - 白地の円
抽象度:低のプロセス(行動、やること) - 黒地の四角
抽象度:高の成果物 - 黒地の円
抽象度:高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度:低の成果物)を集約した情報
なお、ET:"Exploratory Testing(探索的テスト)"と略称しています。
合否判定基準
合否判定基準となるのは、「製品のあるべき姿」がベースになります。例えば、製品やサービスがあることで人やモノの流れ、社会システムにどう変化するかを企画書からくみ取ったり、仕様を検討しているエンジニアが思い描いているものを聞いてみたりします。また、バグが発生することにより人やモノの流れ、もしくは社会システムにどのような影響があるか、想像します。
「製品のあるべき姿」と前回の探索的テスト実施中:観測で得た情報から、テスト実行結果がOKかNGかを総合的に判断します。
問題点
当時、「過去の経験知」「損失」「感情」が絡み合って具象化したものが問題点であると考えていました。前述の3点の他に要素があると思いますが、その要素が何か言語化できないため、モヤモヤしているところです。
「過去の経験知」
バグの発生原因やプロジェクトの失敗事例を挙げましたが、一言で言えば苦い経験です。製造業のメーカーで安全衛生教育として定期的に実施しているKYT(危険予知トレーニング)の絵(「何の危険がありますか?」「このあと、作業者はどうなると思いますか?」)をイメージしていました。
「損失」
過去のプロジェクトや航空会社の搭乗システムが止まってフライトができないような社会的なニュースから、何の損失があるか考えたときに「時間」「金銭」「健康」の3点を見いだしました。
「感情」
例えば、オンラインゲームで課金したのにバグが原因でレアアイテムが入手できないことや株取引中に異常な取引データが発生して損したといった機会損失を発端とした「悔しい」があったり、画像データが消失したことで過去の思い出が一気に無くなったときの「悲しみ」があります。
次回
これまでの話を統括しようと思います。
「探索的テストで工夫したこと」(3)探索的テスト実施中:観測
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
[2]探索的テスト実施中:観測
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度:低の成果物 - 白地の円
抽象度:低のプロセス(行動、やること) - 黒地の四角
抽象度:高の成果物 - 黒地の円
抽象度:高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度:低の成果物)を集約した情報
なお、ET:"Exploratory Testing(探索的テスト)"と略称しています。
探索する目的や手段や探索するスコープ
前回の探索的テスト実施前:情報収集で収集した情報や過去のテストで分かったことを踏まえ、テストで何を知りたいか、知るためにどのような手段を講じるか、現時点での(プロジェクトで確保している)工数でどの範囲でテストを行うかを勘案し、探索する目的や手段や探索するスコープを決めます。
データ出力
テスト実施中に着目するデータをいくつか決めておきます。開発している製品やサービスによって異なりますが、Wiresharkで取得したパケットデータ(TCP/IPなど)の特定部分の変化を観測したりします。アプリケーションソフトでは、バイナリデータとして画像も観測します。
物理的出力
組み込みシステムでは電気的出力として、視覚的なもの:Ethernet PortのLEDの点灯/消灯の時間間隔、聴覚的なもの:電気的スイッチのリレー音(例:車のウィンカーのカチカチ音)の時間間隔や音の大きさ、触覚的なもの:マイコンチップや電源回路から発せられる熱といった人間の五感(センサ)として観測しています。
普段の生活の中で観測した出力をどう研ぎ澄ませるか?
電車通勤では、自動改札機でICカードを読取り部にかざしますが、ICカードと読取り部の距離を5mm余分に離したり近づけたりすることを試し、自動改札機のふるまいを見ることもよいでしょう。また、会社のセキュリティエリアでICカードの社員証をかざし、解錠音が聞こえてからドアノブのレバーを下げるまでの時間を200ms間隔で変えてみて、ドアノブのレバーが完全に下がるか感じてみるのもよいです。
次回
[3]ET実施後について、詳細を説明する予定です。
「探索的テストで工夫したこと」(2)探索的テスト実施前:情報収集
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
前回書いたこと
[1]探索的テスト実施前:情報収集
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度:低の成果物 - 白地の円
抽象度:低のプロセス(行動、やること) - 黒地の四角
抽象度:高の成果物 - 黒地の円
抽象度:高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度:低の成果物)を集約した情報
なお、ET:"Exploratory Testing(探索的テスト)"と略称しています。
何故、ET実施前に情報収集を行うのか?
私だけかもしれませんが、テスト対象で不具合が隠れていると思われる機能を絞り込み、どのような手段でテストを行うか頭の中で検討するためです。また、漠然とテストしたところ、不具合を見つけることができなかったことがありましたので、「テスト対象の怪しいところは何か?」を明確にしたいと考え、「怪しいところ」に繋がる情報を収集したら、不具合が見つかるだろうと考えました。
初めに取り組んだこと
当時、インシデントレポートを多く読んでいなかったのですが、 ソフトウェアテスト293の鉄則の『鉄則055:報告の内容でテストをした“人”がわかる』を読んだ後、「発見したバグは何故修正しないといけないか?」という理由が明確なインシデントレポートを探して読んだら、「テスト対象やシステムのあるべき姿は何かを考えることができるのでは?」と考え、これまで関わったプロジェクトや同僚が関わった過去プロジェクトのインシデントレポートを印刷して読み込みました。
インシデントを何件か読んでいくうちに...
スクリプトテストを実施しながら、「バグが存在することでユーザが困ることは何か?」「どのような手段で、ユーザが困ることを見つけることができるのだろうか?」と思い始め、テスト対象に関する仕様書(要求仕様、製品仕様、テスト仕様)や過去プロジェクトのインシデントレポートを参考情報として、読み漁りました。
読み漁った後...
スクリプトテストで疲れたので、少しリフレッシュしようとペットボトルのお茶を飲んでいたとき、(「そういえば...」と)デジャブを感じるバグが何件かあることに気付きました。バグの傾向をつかみ、インシデントレポートから新たなテストケースを頭の中や裏紙に書きながらテストケースを思いついたので、試しにテストを実施してみたら、偶然バグを発見することができました。
開発者に状況を話したところ、開発者から「それはバグですね。インシデントレポートを書いて、私に送ってもらえますか?」ということで、少しずつですがバグのにおいを感じるようになりました。
次回
[2]ET実施中について、詳細を説明する予定です。
「探索的テストで工夫したこと」(1)全体像
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」の発表を行いました。これからの議論が発展することを願い、当時私が考えていたことを書き記します。
ライトニングトークス「探索的テストで工夫したこと」の以前に考えていたこと
私が考えていたことのベースになりますので、下記に掲載します。
masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
ライトニングトークス資料
全体像は、下記になります。
図中の凡例は、下記5点です。
- 白地の四角
抽象度:低の成果物 - 白地の円
抽象度:低のプロセス(行動、やること) - 黒地の四角
抽象度:高の成果物 - 黒地の円
抽象度:高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度:低の成果物)を集約した情報
なお、ET:"Exploratory Testing(探索的テスト)"と略称しています。
図を書いた目的
探索的テストにおける私のイメージを第3者が共有しやすい形で表現し、探索的テストがad hocではなく、状況を考慮した(高度な)考えと行動であることを示したいため。また、テストを極めることは易しくないことを経営層やプロジェクトマネージャに伝え、製品品質に対するテストチームやQA組織が寄与するために考えていることを説明するため。
全体像からの概要
イメージは、探索的テストで多種多様の情報と人の五感をテスター自身が吸収しながら、テストをグルグル実施しているものです。時間軸は、1分から1時間単位でプロジェクトの状況によってまちまちです。
次回
[1]ET実施前について、詳細を説明する予定です。
【速報】State of Testing 2016の調査レポートが公開されました
"State of Testing Survey 2016"の調査レポート(英語)が先ほど公開されました。2016年1月にアンケートの回答を募集していましたが、世界中の1000名を超える方から回答されたそうです。
調査レポートは、こちらからご覧ください。
〆
システムテスト自動化カンファレンス2015(8)「パネルディスカッションLIVE!テスト自動化“エンジニア”の今とこれから」
2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
本blogでは、聴講したセッションから数回に分け、メモした内容を紹介します。
セッション
講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)
1.テスト自動化のスキルを考えよう! ~テスト自動化エンジニアに求められるスキル、期待される役割~ 早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。 コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た~自動化の現場の真実~ /".reviewrc"→"おいしが" →<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと - /森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部) →<資料>
4.楽天の品質改善を加速する継続的システムテストパターン /荻野 恒太朗(楽天), 菊川 真理子(楽天) →<資料>
5.キーワード駆動によるシステムテストの自動化について /小井土 亨(SQiP 運営委員会メンバー、株式会社OSK) →<資料>
6.Testing Tools for Mobile App /松尾 和昭(クックパッド) →<資料>
7.パネルディスカッションLIVE! テスト自動化“エンジニア”の今とこれから/登壇者:森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ:浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
今回は、「7.パネルディスカッションLIVE! テスト自動化“エンジニア”の今とこれから」について紹介します。
7.パネルディスカッションLIVE! テスト自動化“エンジニア”の今とこれから/登壇者:森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ:浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
(1)TLからの質問
- Q1
IoTの話は無視できないが、工夫していることはあるか? - Q2
サービス内容自体のテストへの関わりが増えているか? - Q3
手動テスト用のテスト設計と自動テスト用のテスト設計の違いは? - Q4
自動テストが進むと、マニュアルテストやレビューの重みが強くなるが、役割分担はどうなるか?
(2)TLからの質問に対する話
- 機械をいじれる方法をやっている。
- 替えが効くものが入手できる時代。
- 0と1の判断できるか?(例:アニメーションがちらつく)
- 事前条件が書けるか?アンニュイな判断。
- 感覚でバグを検知するひとがいる(少し遅いという感覚)。
- 自動テストと手動テストを使い分ける。
- 人間系の問題、仕組みの問題。
- どれくらい繰り返すかによるが、自動化はコストかかる。
- Cheking
- テストデータは自動も手動も変わらない
- アジャイル
- 幸せになること
- 行動心理学
- 作りが妥当か?仕様にバグがないか?
- もっとできたことがあると気付く。
所感
パネルディスカッションを通じ、テスト自動化のキャズムを超えた先にある世界は、手動テストと自動テストの共存が課題だと思いました。また、"Checking"と"Testing"の役割を開発チーム内で議論して、開発現場や組織にとって幸せな開発になるよう、自動テストの技術を進化することも大切だなと思います。現在、私は昨年度末から参入している開発チームで仕事をしていますが、製品特有のテスト(特にパフォーマンス面)やスモークテストをもう少し網羅したいという話(課題)がありますので、製品のあるべき姿を確認するためのテストをプロジェクトマネージャと納得できるように議論しようと思います。
システムテスト自動化カンファレンス2015(7)「Testing Tools for Mobile App」
2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。
セッション
講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)
1.テスト自動化のスキルを考えよう! ~テスト自動化エンジニアに求められるスキル、期待される役割~ 早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。 コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た~自動化の現場の真実~ /".reviewrc"→"おいしが" →<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと - /森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部) →<資料>
4.楽天の品質改善を加速する継続的システムテストパターン /荻野 恒太朗(楽天), 菊川 真理子(楽天) →<資料>
5.キーワード駆動によるシステムテストの自動化について /小井土 亨(SQiP 運営委員会メンバー、株式会社OSK) →<資料>
6.Testing Tools for Mobile App /松尾 和昭(クックパッド) →<資料>
7.パネルディスカッションLIVE! テスト自動化”エンジニア” の今とこれから/登壇者:森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ:浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
今回は、「6.Testing Tools for Mobile App」について紹介します。
6.Testing Tools for Mobile App /松尾 和昭(クックパッド)
(1)モバイルアプリ
組み込みの次に難しい開発。
(1-1)実情
- OS
- 利用場面の多様化
- サービス開発中心
- 開発サイクルの短期化
- サービス成長、コード肥大化
- アプリのデプロイリスク
- iOS:いきなり100%
- Google Play:段階リリース5-100%
- リジェクトリスク
Apple:1week待ちやポリシー変更 - ダウンロード(できない)リスク
- アプリ評価のビジネスへの影響
(1-2)必要されているもの
- 安定したリリースを回す
- 内的要因への対応
リリース前後の不具合や障害増加防止 - 外的要因
外部サービス障害対応など
(1-3)OSの変化
- 環境変化が激しい
- 必然的に標準で提供されるツールが中心
- 破壊的な仕様変更
(2)事例
(2-1)チーム事情
(2-2)発生した障害
- Androidアプリ
1.機能的に問題ない
2.CPU/メモリ資源が過剰消費
3.発覚したきっかけ:レビュー、お客さんからのお問い合わせ
4.対策:資源の監視
(2-3)学び
- 学び
- 計測から:見えないものを見えるように(CPU使用率やメモリ消費量)
- 開発の流れに組み込むことで習慣化
- 失敗
- 開発の流れに組み込まれていない
- 検出できない
- 学びと失敗を踏まえ
必要なものは実装しよう
(2-4)課題
- シナリオ管理
- 結果のフィードバック
開発者やテストエンジニアだけでなく、デザイナへ拡大。 - サーバーとの協調
API変更の追従。
(3)One More Thing:手動テストから現在に至るまでやったこと
- 自動化を進めた理由
- 開発量やリリース頻度が増加したら破綻する。
- ビジネスのコアとして継続的な改善の土壌。
- 実績を残す ソフトウェアテストへの専門性:ディレクターに施策の効果を説明するなど。
- デファクトを変える
これまでの概念を変える。 - マインドマップ
- 仕様の落とし込むと理解
- 複雑さの理解:テンプレートを作り情報整理
- 開発者に近いところに入る
- 外から内へ
- 開発者が機能実装時にGUIテストが書けたりできたりする。
所感
リスクに繋がる予兆を検知するため何の情報(メトリクス)が必要かを見極めた上で、ツールの活用や自前で作成することも開発方針に盛り込み、開発スピードや開発者の体力気力が落ちないように工夫してみようと思います。
システムテスト自動化カンファレンス2015(6)「キーワード駆動によるシステムテストの自動化について」
2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。
セッション
講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)
1.テスト自動化のスキルを考えよう! ~テスト自動化エンジニアに求められるスキル、期待される役割~ 早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。 コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た~自動化の現場の真実~ /".reviewrc"→"おいしが" →<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと - /森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部) →<資料>
4.楽天の品質改善を加速する継続的システムテストパターン /荻野 恒太朗(楽天), 菊川 真理子(楽天) →<資料>
5.キーワード駆動によるシステムテストの自動化について /小井土 亨(SQiP 運営委員会メンバー、株式会社OSK) →<資料>
6.Testing Tools for Mobile App /松尾 和昭(クックパッド) →<資料>
7.パネルディスカッションLIVE! テスト自動化”エンジニア” の今とこれから/登壇者:森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ:浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
今回は、「5.キーワード駆動によるシステムテストの自動化について」について紹介します。
5.キーワード駆動によるシステムテストの自動化について /小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)
(1)システムテスト
- End to Endテスト ユーザに触れる直前なので、GUIテスト。
(2)自動化されたシステムテストの課題
自動テストのスクリプトの工数を減らしたい、楽したい。また、スクリプトを直さずに自動テストしたい。
(3)データ駆動
- テストスクリプトとデータが分離。
- 値をファイルに格納している。
(4)キーワード駆動
- 対象、値、操作
- 対象(単価データとか)と操作(セット、クリックなど)がキーワード。
- 問題点:制御処理(IF文)の記述が難しい
- 同じコードが大量作成。
- コードが共通の部分とバリエーションがある部分が混在。
- キーワード駆動の要素
- 値の設定
- 値の読み込み
- 処理実行
- ログ出力
(5)アーキテクチャ
- 何をどのように検査するか?
- キーワード駆動はゴールではない。
- ルールと指針を決める。
- 誰がやっても間違えない。
(6)使い分け
- 同じ操作
スクリプト - バリエーションがあるところ
データ駆動
(7)デモ
C#とPowerShellを組み合わせた内容。
所感
キーワード駆動テストは、現場周辺で適用している事例は聞いたことがないが、バージョンアップを繰り返す開発が進行していくにつれ、自動テストも開発毎に進化していく必要があるので、本発表から現場で適用するネタを考えようと思います。
また、ISO/IEC/IEEE29119 Part5や書籍『システムテスト自動化標準ガイド』第13章も参考文献として、アイディアを温めようと思います。5年後、10年後の開発を見据えて。
JaSST’16東京のコミュニティブースにお越しいただきありがとうございました@探索的テスト研究会
2016年3月8日(火)~9日(水)に開催された「ソフトウェアテストシンポジウム2016東京(JaSST'16 Tokyo)」のコミュニティブース@探索的テスト研究会で議論いただいたみなさま、ありがとうございました。
所感
「探索的テストのモデル」は議論の余地がありますが、探索的テストのイメージをある程度共有した上で議論すると、課題が徐々に明確なったと実感しています。「探索的テストに関するFAQ」は、いくつかのFAQでみなさんからの悩みや課題、分からないことなどのお話をいただきましたので、研究会でさらに議論して解決の糸口を探索していきます。
「探索的テストのモデル」及び「探索的テストに関するFAQ」の正式版公開について
今回発表した「探索的テストのモデル」及び「探索的テストに関するFAQ」はβ版です。みなさんと議論した内容を踏まえ、正式版として公開する予定です。
「探索的テストのモデル」及び「探索的テストに関するFAQ」の正式版が公開されましたら、本blogでお知らせします。