Outline
6/13 に ”自動テスト喋り足りNight #1”というイベントがありました
https://connpass.com/event/131878/
そこでは、様々な企業で活躍されている自動化エンジニアがあつまり、自動化に関するナレッジを共有しました
今回、たまたま発表する機会をいただいたので、Jasst東北で仙台から帰宅する新幹線の中でもんもんとコンテンツをつくり、発表しました
twitter hashtag
https://twitter.com/search?f=tweets&vertical=default&q=%23shaberitarinight
Presentation
1. why automation
なぜ自動化をするか、目的を明確にしたほうが良い
・自動化によって、品質活動の効率を上げ、全体的な品質をあげること
・自動化といっても、テスト実行だけではない。 レポーティングやテストデータ作成、ストレステストなど作業改善できるところはいっぱいある
・これらによって、開発サイクルを向上し、コスト削減も図れる
尚、ISTQBの Test Automation Engineer syllabusには、直接的にバグをみつけることとは書かれていません。
誤解をたまに生むのは、自動化によってたくさん新規バグを探してくれるということ。
2. How to automate
どのように自動化を実現するかを考える
・将来まで考えて、どのメンバーが自動化を運用していくかを考える必要がある
つくっただけで終了ではない
・外注にするというのも一つだが、運用がセットになるので、ツールによるベンダーロック以上にロックがされかねない
・運用として、
スクリプトを最新のプロダクトに追従する必要
実行環境のバージョンアップ等
3. What area is automated
自動化にあたって、どの部分を自動化するかを最初に基準を作ったほうが良い
・アジャイルテスト４象限がざっくりとした切り口として参考
・なんでも自動化にならないように
4. How to operate
つくった自動化をどのように利用していくかを考える
・プロジェクト単位で使い捨てにするという考え方もあり。
例えば、フォームへの入力の網羅テストを実施したい場合
競馬で三連単全パターンの購入テストをする場合、3360通り( 16 * 15 * 14 )になるので、それを実施。ただし、毎日実行する必要はない。なぜなら、実行時間もかかるので、そこまでの必要性がない場合
・レポーティングも重要。誰に見せて、どのように使うのか？ 失敗したときに、分析しやすいものになっているか
・よく使われる、CIのなかで利用する場合。それを見越した設計を考える必要がある
5. How to collaborate with others
自動化は個人で完結させるものではない。
stakeholderに共有することで、もっと生きてくる
・QAの組織の中でマニュアル部隊と別れている場合、マニュアル部隊にとって何を自動化し、品質担保しているかを可視化させないと、マニュアルと含めての効率の良いテストにならない
・QA外への情報展開も場合によって必要。例えば、ProDuct Managerに対しては自動化の運用があってもROIが成り立つような説明が必要なときもある
・自分の評価にもかかわってくるかもしれないが、自動化が上司から見てどういったものであるかを説明できるようにしておかないと苦労する場合もある。（システム運用と同じで、なにも問題ないように運用することが評価されにくい？）
6. How to install in project
・マニュアルの実行に比べて、自動化の主にスクリプティング工程には時間がかかる
・テスト対象が特に新規の場合、安定するまで時間がかかるのが多い（マニュアルのテスト実行中に、バグ大量に発生、テンプレートエンジンの見直しでデザイン作り直しとか）
・自動化が正しいという検証を考えないといけない
そういったことから、自動化をどのタイミングで適用させるのかをプロセスに取り込まないといけない
7. Let's try it first
なんだかんだ言ってきましたが、結局はまず何でもいいから自動化をやってみることが重要
Note
※パンダと発表はあんまり関係ありません