読者です 読者をやめる 読者になる 読者になる

テスト設計コンテストを見てきた #tdcmakeinu

test

こくちーず
3月24日 テスト設計コンテスト負け犬の会~別に勝ちたい訳じゃないからね(愛知県)


JaSST'12 Tokyo テスト設計コンテスト
JaSSTソフトウェアテストシンポジウム-JaSST'12 Tokyo レポート



テスト設計を競うイベントに参加した全チームが50分かけて再演してくれるというイベントに行ってきました。
非常に濃密な時間を過ごせました。



僕が参加した正直な感想を書きます。

ソフトウェア開発プロセスの意識が足りない

まず、全体的に言えるのが、テスト設計コンテストに参加しているチームは「ソフトウェア開発プロセス」に対する意識が足りないということ。
僕としては「いいテスト設計」はソフトウェア開発プロセスでいかにうまく立ち回れるかにあると思っています。
だから、テスト戦略が重要だし、テスト設計した結果というものがアプリケーションライフサイクルのなかでどう活用されていくかを気にしなくてはいけない。

商品の開発背景やビジネスコンテキストを設定していない

あと、テスト設計コンテストのお題である商品がどのような背景、意図で開発されているかを定義していかないと、テスト工数の見積もりも出来ないし、ほとんどのチームは工数の見積もりをしていなかった。
ペルソナの設定はあくまで分析や優先順位なんかで役に立つ訳で、テスト自体をどこまで実施するかとか、設計時点でバッサリと切るかは商品が研究開発なのか、量産直前なのか、バグの対応方法、販売経路、在庫、などによって随分とかわります。

いいテスト設計にはテスト手法も重要だけど

テスト自体の「保守性・再利用性」や「仕様から外れていないことの妥当性」や「テスト目的から外れていないことの妥当性」や「工数」を気にしないといいテスト設計ではないと僕は思っています。


仮にそれらを気にしないのであれば、あれはCode Jam的なテスト設計コンテストの色味が強くなりそうですし、そうであるならばいまの参加チームの様相というのはわかります。


まとめ

僕が期待していたテスト設計コンテストとはだいぶ違ったというのが大まかな感想です。


ですが、参加チームが出してきたテスト設計やプロセスから学ぶ点がたくさんあったのも事実です。おそらく僕がやっても彼ら彼女らと同じレベルは出せないでしょう。


期待していたものと違ったけど、非常に有意義なイベントでした。


先にあげたようなイベント自体に不足している部分については懇親会で様々な人と意見交換できたので、僕としては昨日は非常に濃密な時間を過ごせました。
またいろいろ話してみたいなって思います。



参考文献

テストプロセス全体の入門として

マインドマップから始めるソフトウェアテスト

マインドマップから始めるソフトウェアテスト

ソフトウェアテストのテスト戦略からテスト設計までの特集があります

ソフトウェア・テスト PRESS Vol.10

ソフトウェア・テスト PRESS Vol.10

ソフトウェアテストPRESSの総集編。上のvol.10も入ったPDFになっています。もし他にも興味があるのであれば。

ソフトウェア・テスト PRESS 総集編

ソフトウェア・テスト PRESS 総集編

広告を非表示にする