テスト設計コンテストとは
NPO法人ASTERが主催するテスト設計を決めるコンテスト。 http://aster.or.jp/business/contest
テストベースと呼ばれる要件定義書(ASTER作成)を基に、どんなテストをするかというものを設計して設計成果物(ドキュメント)とプレゼンで優劣を決定する。
テスト設計てなんぞや?
特に大規模なシステムなどの場合、いきなりテストフェーズで気ままにテストしてしまうと重複や漏れ、バグの見落としがあります。
また無駄な工数がかかってしまう為、その戦略としてテスト設計を行うと(勝手に)思っています。
ちなみに、わたし自身は独り身テスターで、上に書いている「大規模システム」でないこともあって、「テスト設計」としてきちんとアウトプットを出しているまではありません。テストのスタイルとして(なんとなく脳内で)設計している状態のようです。 実際よくわかっていません。(模索中です)
行った目的
- テスト自動化カンファレンスの前日に開催されている(予選の観戦だけに東京行くわけにもいかず、連日であってラッキーだった)
- 九州では今のところ予選はなく、書類選考のみ(参加チームが増えたら予選もあるはず)
- 私自身、過去2回出たことがあるが、いずれも予選敗退
- 予選に出て、モチベーションをあげたいなぁ(次回)
出たチームとか
東京は11チーム *2グループに分かれてプレゼン
出ているチームの出たキッカケ
- 2~3年でチャレンジしてみよう
- 設計コンテストの決勝を観に行って、観るだけと参加しているのと全く違うと気付いた。一人でやってみたいと思った。
どんな会社が出てるの?
- 企業枠として、某大手メーカーのテストチームや、第三者検証の会社
- 個人枠で、各メーカーや第三者検証の複合チーム
- 一人で参加(某メーカー)
所感
まずは、 参加できてよかった!
参加できてよかったところ
- 決勝だけでは上級レベルすぎてついていっていない分、予選で自分と同じようなレベルの人などのプレゼンを聞いたことで、自分のわかっているところ、ダメだと思ったところ、良かったと思うところが理解しやすかった
- 最近のテストだと「やってみてなんぼ」「バグは出た時になおせばいいやん」という傾向があるなかで自分に対する気付きを得るにも、俯瞰してみるにもやはりテスト設計は必要だなーと思った
- 経験や主観でテストしていたものを設計することで全体を俯瞰することができ、自身の抜け漏れの早期発見につながる(はず)
自分が分かってないなぁと思うところ
テストアーキテクチャ― is 何 どのチームもテストアーキテクチャ―という項目でマトリックスやモデル図や機能関連図を使っていることは理解できたが、結局テストアーキテクチャって何よ?という目的や意図がわかっていない。
他にはテスト要求分析やテスト詳細設計などがありますが、そこは何となく理解できているレベル。というより、テストアーキテクチャ―is何が決まらないとその前後に発生する要求分析やテスト詳細設計がどこまで?どこからすればいいか分からなくなる。
おわりに
重複になりますが、参加できてよかったです。本来なら、テスコンに参加した上で観ることが出来れば一番良かったのかもしれません。 来年出る・・・かどうかは自分の身体と要相談ですが、やはり手と頭は動かさないとだめだなーと思いました。(聞いてるだけじゃだめだー)
追記
このエントリーで、テスト界の偉い人@akiyama924がテストアーキテクチャ― is 何? を教えてくれた
@____rina____ テストアーキテクチャーという言葉は使っていないかもしれないけれどやっていると思います。
ウェブサイトのテストなら各ウェブページのテストをしてから業務が流れるかシナリオテストをしてみようとか計画しますよね?
— akiyama924 (@akiyama924) 2015, 12月 12
@____rina____ このように、「どんなテストの固まりををどういう順番でやろうかな?と考える」のがテストアーキテクチャーを作ると言うことです。
— akiyama924 (@akiyama924) 2015, 12月 12
@____rina____ SQL インジェクションのテストはいつやるのが効果的だろう?とか、本番システムに乗っていないのに負荷テストをしても無駄だよなーとか考えますよね?
それは個々のテストを作ることではなくテスト全体をどう構築するかです。それがテストアーキテクチャー。
— akiyama924 (@akiyama924) 2015, 12月 12
@____rina____ 「出来上がったもの(is 当たり前に普段見て・やっているもの)」と、「テストアーキテクチャー」という名前から感じる高尚さとのギャップがありますよね。
でも、そのギャップ感を埋めるために“考える”ことが重要です。
— akiyama924 (@akiyama924) 2015, 12月 12
なるほど。
テスト要求で、どんな要求があるか考えて テストアーキテクチャ―で、それらの要求ややらなければいけないことを「こうやるとスムーズにいけてるように出来るんじゃね?」を考える ・・・のかな。
それから、
@____rina____ 単語に振り回されてる人が多くて。大事なのは中身の話なのに、その言葉の定義にマッチしてるかどうかを考え始めてしまうとか、既にどこかに正解があってそのとおり解けてることを主張しようとするのとか。自分の解き方を説明すればいいのに変な方向に向くのもったいない。
— ゆにまる (@Unity1004) 2015, 12月 12
@____rina____ 目的を間違わなければ前には進めると思います。出だしというより向く方向が間違っちゃってる例がいっぱい。
— ゆにまる (@Unity1004) 2015, 12月 12
テストアーキテクチャ―という言葉に振り回されて、大事なことを見失わないようにしたいな。 というか、多分「テストアーキテクチャ―is何?!」で、見よう見まねで手先だけ動かしちゃうとそうなっちゃうんだろーなー って過去の自分がそれだったんだね。とわかった次第。