はじめに
- メーカーとコンサルでアプローチが違ってくると思うが、発表者2人の経験を元に話す。
テスト自動化とプロジェクトの成功について
- テスト自動化を成功したつもりだったが失敗した。
- テスト自動化の成功定義、テスト自動化の目的がメンバーや上司と意見が一致しないはず
- テスト自動化の成功を定量的に示す
定量化って難しい
- メトリクスを取ろう→150個作ってしまった
- 真剣にやったがために目的が見えなくなる
- 絞り込むのは必ず行う。
- データはいくらでも取れるが、目的から導かれるデータは3個ぐらいになる
失敗例
- 開発が遅れている→テスト期間を短縮→テスト自動化しよう
- 「QEだろ、なんとかしてくれよ」と言われた
- 前回はテスト期間が短かった→最初からテスト自動化しよう！→何をやりたいのか深く考えずにコンサルに頼ってしまったから失敗した
- テスト自動化だけでなく、テスト全体や製品全体のことを考えていなかった
成功させるために
- 本当に今自動化が最適な解決策であるか議論しよう
- 調整が必要な人を握っておく
- 決済権者やCS担当者を味方にする
- CSは本番と最前線で戦っている
- 決済権者やCS担当者を味方にする
- 利害関係者と自動化による改善のKPIを合意する
- 最小限の領域で提案する
- みんながハッピーになるようにすることが大切
テスト実行以外の自動化
- テスト進捗とか合格率とか
- 開発期間が伸びてテスト期間が短くなる状態でテストを回すには、集計とかは自動化しておくべき
テスト自動化しやすい活動は？
- ビルド自動化やデプロイ自動化
- ビルドは一人でもできる
- スモークテストスイート
- ゲームのようにランダム実行が多いものでも、全実行でヌルポが起きないかどうかだけでも効果が高い
- マネーパススイート
- 決済関係
- お金が関わる部分は重要
- 決済関係
不具合駆動
- 欠陥の偏在
- 『ソフトウェアテストの7原則』より
- 欠陥の偏在
「全部大事」とか開発者は考えがち
リスク駆動型で考える
スキルによって左右されるテストケースは自動化しづらい
いつ自動化を始めるべきか
- アップアップの中でやっていくのではなく、できることなら最初から
- 自動化の仕方を考える前に見える化する仕組みを考えた方が良い
自動化すると不具合がいっぱい見つかる→開発者が不具合の修正にかなり多くの時間をとられる→不具合をスクリーニングする仕組みを考える
ISOやJISも読むと良い
ソースコードを読むことも自動化する人にとっては重要
お客さんの制約の中でも達成できることを探す
質問
テストの進捗と合格率はわかるが、スクリーニングの仕組みとテスト分析とテスト設計の仕組みを教えてほしい
- テストのスクリーニングについて
- テストの結果、テスト実行者が間違っているとか手順書が間違っているかもしれないという状態で、それを開発者に投げると、「自動テストの品質が悪い」と言われる。
- インシデントの中から故障だけを開発者に伝える作業を行う。
テスト自動化した後でやったほうが良いことは？
期待値のコントロールの仕方について
- 初期は過剰の期待を持たれがち
- 最小限が小さすぎると効果ないと言われたり
- テスト自動化しやすい箇所をやる
- SeleniumIDEでやってみて短期的な目的を達成したり
- その後、テスト自動化の成功の定義を見直す
