テスト開発の第一歩としてのASTERテスト設計コンテスト参加
はじめに
こちらは、ソフトウェアテスト Advent Calendar 2020 - Qiita22日目（2020年12月）の記事です。
21日目の記事はこちらの松谷さんです。
※注意点：このブログは一個人としての私見です。
ＡＳＴＥＲテスト設計コンテストの実行委員、Ｕ－３０審査委員の意見ではないことをご了承ください。
今回の目的
今回も例年通り、ASTERテスト設計コンテストの宣伝です。
ASTERテスト設計コンテストとはなにか
ASTERテスト設計コンテストはテスト設計の良さを競うコンテストです。新人や若手にはテスト設計を学ぶ場として、シニアには自分ちのテスト設計を試す場として参加されています。
今年のコンテストはどんなだったか
今年は初のオンライン予選＆決勝でした。
また、私としても、実行委員兼U-30審査委員として初の参加でした。
いろいろと議論はありますが、今年はコロナの影響もあり比較的小規模なコンテストになったかなという印象でした。
ただし、その分、参加しきったチームは、個人活動もしくは、オンラインでうまく活動したチームも多かった印象です。
さて、話は元に戻りますが、テスト設計コンテストは技術の高さを競うものです。
コンテストに参加するにあたり、参加チームの方々は結構悩んだりされた方が多かったのではないでしょうか？
また、参加してみたいという方では、「ちょっと難しそうかな…」と思われている方もいると思います。
ということで、今回は、「どんなスキルが必要か」、「何に重点を置いて活動すべきか」を少し書き綴りたいと思います。
テスト開発をやりきるための必要なスキル
コンテストに限らずですが、テスト開発をやりきるには下記のスキルが必要だと考えています。
- テスト成果物を定義するスキル
- テストプロセスを作るスキル
- テストベース分析を行う（テスト要件を抽出）スキル
- テスト要件からテストケースを設計・実装するスキル
次では、具体的にどんな技術でどんなことができたらよいかを少しだけ紹介していきます
テスト成果物を定義するスキル
これはまず初めにどんなテスト成果物を作ればよいかを定義できるスキルです。
何某かテストを作るとしてもイメージしやすくなるようにどんな形式でどんなデータがあれば最終的なテスト成果物になるかを定義できるようになるとよいです。これがスキルとして不足している場合、「じゃぁ具体的にどう作ったらいいんだ？」と悩んでしまいます。この場合の対策としては、自分が扱いやすい細かい単位でまずは成果物を作成して、情報を整理して再定義すると良いでしょう。
参考になる技術、規格など：TPI Next,TMMi,ISO29119
テストプロセスを作るスキル
これも、テスト成果物を作るスキルと併用して語られるスキルです。最終的なテスト成果物を作るには上記と同じように、どこでどんなデータを得れば作れるかを明確にしていきます。スキルとして不足している場合はテスト成果物を作るスキルと同様のケースに陥ってしまいます。そのため、自分が扱いやすい単位まで成果物のデータの流れを整理して定義すると良いでしょう。
参考になる技術、規格など：TPI Next,TMMi,ISO29119,PFD
テストベース分析を行う（テスト要件を抽出）スキル
テストすべきことが何かを洗い出すスキルです。しかし、このスキルを十分に発揮するためにはテスト目的とテスト要件(テストすべきこと)の関係性を明確にしておく必要があります。もし、その関係性があいまいなままだったりすると、分析の粒度がぼんやりとしすぎていたり、細かすぎてしまったりしてテスト要件の抽出が十分に行えないという状況に陥ってしまいます。この場合、日本人なので言葉の主語述語などの文法や分析モデルの文法を定めて、同じ単位で分析すると良いです。
参考になる技術、規格など：リスクベースドテスト、VSTeP、ゆもつよメソッド
テスト要件からテストケースを設計・実装するスキル
仕様書などのテストベースから、テスト要件を抽出できれば、今度はそれをテストケースに落としていくのですが、その上ではテスト設計技法が使えるとより良いです。このスキルが不足していると、テストケースが体系的に作れず、作ったテストケースがどのような目的でテストすべきなのかを説明しきれなかったり、テストケースの重複や漏れが発生してしまいます。そのため、適切に設計、実装できているか確認したい場合は、作られたテストケースがテストの目的が合うかを確認してみましょう。
参考になる技術、規格など：テスト設計技法全般(ISTQBなどの参考書)
テスト開発で何よりも大切なこと
また、スキルも大切ですが、もっと大切なことがあります。
それは、テスト開発の一貫したコンセプト(テストで何を実現したいか)を提示することです。
別の言い方をすると、「テストで実現したいこと」をテスト開発に必ず込めることです。
例えば…
- 現状直面しているテスト開発における課題解決につながること
- 普段テスト設計していて、実現しているんだけどもっと効率よくできないかということ
「とにかくあらゆるバグを見つけたい！」、「 やばいバグをしっかり見つけたい！」,etc,..,
などをコンセプトに含めてみると良いです。
このコンセプトが明確だと、
現状の自分たちのテストプロダクトが目的を達成しているかをきちんと見直して、
その代替策や改善策を思いつくことができます。
むしろ、これがないとチーム内や、第三者目線でよくわからないものができることが多いです。
あなたが実現したいことが本当に実現できているか是非問いかけてみましょう。
おわりに
テスト設計コンテストは結構「タフ」なコンテストです。
ですが、一年を通してやり切れたとき、反省点はあるかもしれませんがかなり学びがあるコンテストであると私は感じています。
テスト/QAエンジニア・コンサルタントを目指される方には、とても有用なコンテストですので是非ご参加いただければと思います。(宣伝)
そして、先ほども含めて、2019年のＵ－３０のチュートリアルでもお伝えしているのですが、
テスト開発は、一つのプロダクト開発と何ら変わるものではありません。
なので、「テストプロダクト(=テストスイートおよびテストシステム)」が何を提供する/したいのかを自分自身でしっかり掲げてみましょう。
その上で、自分自身の「テストプロダクト」を育てていきましょう！
チームや視聴参加の方へのお願い
これからも、参加者が参加しやすい環境を整えたいと思っているので、
何か要望があれば実行委員会にご意見ご感想をジャンジャン送っていただければ！
