テスト設計コンテスト2023 OPENクラスにソロで出場した筆者が、
次回もし複数人のチームで出るならどんなことを考慮するかを妄想する記事です。
はじめに
バグ出しのコンテストではなく、テスト設計成果物の良さを競うコンテストであるため、
成果物のドキュメントを作る時間に非常に多くの時間を費やすことになります。
私は前回ソロで出場したので、数多くの手戻り工数を重ねながら、なんとか成果物の提出にこぎつけました。
一方で、チームで出場した場合に手戻りが発生すると…。想像に難くない結果になるでしょう。
そこで、過去の苦い経験も踏まえて、最初からやっておけばよかったと思うことをマネジメントの要素を中心に書いていきます。
前提
異なる会社に所属していて、尚且つ、テスト設計のやり方も異なるメンバーで、OPENクラスに出場することを仮定します。
U-30クラスは出場したことがないのでわからないですが、もしかしたら参考になるかもしれません。
メンバーが一同に集まる場までにやること
チュートリアル各種(https://www.aster.or.jp/testcontest/tutorial.html)を読みましょう。
特に、『テスト設計コンテスト ’23 テスト設計チュートリアル テスコン編』については、コンテストの出場有無によらず、テスト設計に大切なことが詰まっています。
私は、まさに穴が開くほど読みました。
もし、成果物のイメージが全く湧かない場合は、出場特典として提供される過去の成果物を見てみましょう。
メンバーが一同に集まる場で決めること
コンセプトを話し合う
あくまで、強い想いを持って「このコンセプトで進めたい」という意見を持っている人がいる場合のみです。
その人の想いを受け止めて心中する覚悟で突き進むのか、敢えて別のコンセプトを選ぶのか、納得するまで話し合います。
一度コンセプトを決めて成果物作成に着手してからやり直すのは、相当の時間がかかります。
もちろん、そのやり直す工数も含めて楽しめるのならば、スクラップ＆ビルドするのも良いかもしれません。
と、ここまで書いておきながら、私はエントリー直後にコンセプトが全く浮かんでいませんでした。
何となくぼんやりと、「テスト対象や要求をしっかり捉えたテスト設計をしたい」「生成AIなんかすごいし使ってみたい」と考えていた程度です。
コンセプトが思い浮かばない場合は、実際の業務における課題を想像してみても良さそうです。
例えば、テスト計画から実装まで一連のプロセスを経験してみたい、テスト設計成果物のレビューでもらったコメントを反映させた成果物を作りたいなどです。
ここで決めるコンセプトは、手法などの手段に寄りすぎない方が良いと思います。
例えば、VSTePを使おうとか、ゆもつよメソッドを使おうとか、HAYST法を使おうとか、それらは全て手段です。
それらの手法を使う理由は何だっけ？ということを見失わないようディスカッションしたいです。
なぜ？を深掘りしていくことで、自分たちが本来やりたかったこと、解決したいことが見えてくるような気がします。
すると、既存の手法で満足できないところが見えてくるはずです。万能な手段は存在しないからです。
これは私見ですが、U-30とOPENクラスで大きく異なるのは、 「既存の手法でも良いからとりあえずやってみる」のか「既存の手法の問題を解決する方法を生み出す」のかという点であると考えています。
OPENクラスは
自社の最先端の技術開発のオープンイノベーションの場である テスト設計チュートリアル テスコン編資料(講義編) https://aster.or.jp/testcontest/doc/2023_tescon_V1.0.0.pdf
ということなのです。
コミュニケーションの計画を立てる
- チャットなどの"非同期なコミュニケーション"について
- どんなツールを使うか
- 悩みごと以外に、隔日、週次、隔週など定期的に進捗報告をするか
- 会議などの"同期的なコミュニケーション"について
- どんなツールを使うか
- どれくらいの頻度で開催するか
- 非同期なコミュニケーションでメンバーとやりとりできない場合のバックアップ策
同じ会社で仕事をしている場合は、共通のツールがあったり、メンバーのコミュニケーションのスタンスを把握できている場合もありますが、
他の会社でやり方も、考え方も異なるメンバーとコミュニケーションをとるのは大変です。
「最低でも週次で連絡が欲しいのに○○さんから連絡来ないな」といった悩みを少なくするためにも、非同期のコミュニケーションルールを確認しておくと良さそうです。
また、"業務ではない"という特性上、やむを得ずコミュニケーションが取れなくなってしまう場合もあると思います。
その場合に備えて、(継続意思の確認も含め)複数の手段を準備しておく必要があるかもしれません。
作成する成果物とテスト設計プロセスについて決める
1回では決められないと思いますが、次のような視点で考えます。
成果物作成に使用するツールを決める
法人チームとして参加する場合は、ツールライセンスはある程度融通が聞きそうですが、
そうでない場合は、ツールの制約が出てくると思います。
特に、個人で支障なく利用できるツールでも、チームで共有したり、エクスポートしたりすることを考慮すると、不満が出てくる場合があります。
当然ではありますが、作った後に共有・提出することを考慮したツール選定が必要になります。
成果物にも、文章ベースで記述するもの、お絵描きをするものなど、チームの方針によって必要なツールが異なってくるので、作成したい成果物に応じてツールを選定していきましょう。
成果物の分担方針を決める
審査基準の中に「工程間一貫性点」というものがあります。
説明会でも繰り返し紹介されているため、耳にタコができているかもしれませんが、
どんなに良いテスト要求分析が行えたとしても、その分析結果がアーキテクチャ設計や、詳細設計に生かされていなければ、高得点を狙うことができません。
と、偉そうに言っておきながら、私はソロの経験しかありません。そのため、想像で書きます。
- テスト要求分析
人数が多いことでメリットを出せる工程であるように感じるので、私なら全員でやりたいと思います。
なぜなら、テストベースを読んでいる時に気になるポイントは人それぞれ違うので、それらの集合知(=多面的に抽出されたテスト要求)が強みになると考えているからです。
- テストアーキテクチャ設計〜詳細設計〜実装
この工程はどう分割するか悩みます。
全員で各工程を一つずつこなしていくのか、アーキテクチャの全体像を作ってから、担当を切り出して詳細設計〜実装と進めていくのか、
ぼんやりとアーキテクチャを作ってから、アーキテクチャの仕上げをAさん、詳細設計をBさんと進めていくのか、自分の中にも答えはありません。
スケジュールを決める
どんなに良いメソッドを思いついても、成果物に落とし込まれていなかったら評価されません。
業務ではないので、マイルストーンを決めて取り組むのはかなりの苦行かもしれませんが、
自らやると決めて参加したコンテストです。可能な限り短いタイムボックスに区切って、進捗を確認していけると良さそうです。
おわりに
ふとこのブログネタが頭をよぎり、勢いで書いてしまいました。
私はどちらかというと消化不良で終わってしまった側なので、
「やりきった」と言えるチームが1チームでも増えたら嬉しいです。
