僭越ながらアドベントカレンダーの2日目を担当いたします@mhlycです。
私は「テスト設計コンテストの東京予選に参加した感想など」と題して、徒然なるままに記事を執筆いたします。
テスト設計コンテストの話
この記事を読んでいる方はおそらくテスト設計コンテストの存在は知っていることと思います。書きたいことが山ほどあって、コンテスト自体の説明をしている暇がありません。詳細は以下を参照ください。
まずは順を追って、私がテスト設計コンテストの存在を知り、聴講し、チームで今年参加するまでに至った経緯を説明していこうと思います。長丁場となりますがご了承ください。
テスト設計コンテスト'14に行ってみた
私は2013年に某SIerに入社して、QA（品質保証部）という部署に突如配属されました。
意味もわからず仕様をただ丸写しにしたテストケースを作って「こんな仕事を一生やるなんて耐えられない」と思った私はWACATEというワークショップをネットで検索して発見して行くことになるのですが、その中でJaSSTというソフトウェアテストのシンポジウムがあることを知ります。
2014年に初めてJaSSTに参加したのですが、そこで行われていたのがテスト設計コンテスト'14です。
当時は「テストについて、よくわからないけど専門的なことを話している人たちがいるんだ。」とこんなまとめとかを読みながら思っていました。当然テストアーキテクチャという言葉も知りませんでした。智美塾の存在も知ってはいましたが、怖くて参加できないでいました。
しかしながら、「ＴＦＣ ＫＡ・ＲＩ・ＹＡ」（東海代表）という優勝チームのプレゼンでは、「テストアーキテクチャ」が説明されていました。
私の記憶では「テストアーキテクチャとは、テストの優先順位、順序をわかるように全体像を示したものがテストアーキテクチャである」という感じの説明をされていました。この説明を聞いてなんとなくそういうものか、と当時は理解したつもりになった覚えがあります。
テスト設計コンテスト'15に行ってみた
テスト設計コンテスト'15では「しなてす」（東京）が優勝するのですが、申し訳ありませんがこの年に印象に残ったのは、個人的には発表の内容ではありませんでした。
私はこの頃にはいくつか勉強会に出るようになっていて、いわゆる「勉強会マニア」になっていました。なんとなく浅い知識だけ身につけて、わかった風のことを喋ったり考えたりしていました。
相変わらずそんなスタンスでコンテストの発表を「よくわかんねーな。説明下手くそだな（超失礼）」などと思いながら聞いていたのですが、その中で私は引っかかりを覚えました。
「なんか、今の自分、外野からあーだこーだ言ってるだけじゃん。かっこわるいな」
そんなことを考え始めました。
というのも、当時優勝された「しなてす」のプレゼンターの佐藤さんとは勉強会などで交流があり、よくお話ししていました。そんな身近に感じていた佐藤さんが、大勢の人の前で、強烈な質問を審査員に問いかけられて必死になって回答をしているのです。まさに、矢面に立って戦っているわけです。
それにひきかえ、自分はなんだ。ただ話を聞いてるだけじゃないか。外からなんとなく見て文句言うんだったら誰にだってできるや。
そんなことを思いました。
テスト設計コンテスト'16に出場してみた
私も矢面に立って戦いたい。戦う立場になって、違う景色を見たい。そんなことを考えた私は、キャッチフレーズとして「自分、燃えてるんで。」というフレーズを掲げて様々な勉強会の主催などに手を出し始めます。その活動の一つとして、「テスト設計コンテスト'16にソロエントリーする」というものがありました。
しかし、結果は見るも無残な結果でした。
一人での活動では、当然尻を叩いてくれる人もいなければ、レビューだってお願いしなければやってくれる人なんていません。
結局、締め切り間際になって慌てて資料の作成に取り掛かり、大して練られてもいないテスト設計を普段の業務通りにやってみて、完全に玉砕しました。ショックのあまり当時の資料は抹消してしまったので今は残っていませんが、今思えば残しておいてもよかったかとも思います。
当時は「テストアーキテクチャってよくわかんないけど、テスト計画のことを言ってるんじゃないの。」と思っていたのですが、審査員の方には「そうじゃないよ。テストのアーキテクチャは単に文章で作られたテスト計画だけで構成されるとは限らなくて、テストの構造、優先順位、相互関係を示したりするために何かしらのモデルを作って説明をする場合もあるんだ」といった説明をされました。
あまりに恥ずかしい思いをして、その時は「次に参加するのはやめようかな」 と思っていました。
テスト設計コンテスト'17に出場してみた
2016年の夏、私はWACATE参加が５回目となりました。もう常連です。
その中で、「テスト設計コンテストに出るぞ！」という人がいました。
感化されました。（笑）
勢いで、やるぞ！と決め、面識があって、かつ自分が「この人とやってみたい」と思える人を誘いました。即日OKがもらえて、4人チーム「とある品質保証部」としての活動が始まりました。すぐにキックオフの日程を決め、自己紹介、認識合わせ、キックオフ飲み会を行いました。
オンラインで挫折、対面でのミーティングに変更
最初は、対面で集まってやるのは大変だろう。ということで毎週のこの時間、と決めてオンラインでミーティングをしていました。
しかし、実際の進捗はあまり良くありませんでした。
というのも、対面で成果物を見ながらやるのとは、やはり温度感が違いました。なんとなく「進んでる感じ」を持ってしまい、途中から危機感を覚えて対面でのミーティングに切り替えていきました。
対面でのミーティングは実際負荷も大きく、さらに成果物の作成まで入ってくると最後の方はほとんどプライベートの時間をテスト設計に割いている感じになりましたが、対面でじっくり議論しながら進められたのは良かったです。
辛い経験ではありましたが、実際に手を動かしてみることでわかることもたくさんあったのでやってよかったと思っています。
実際の進め方
実際の進め方ですが、まずは公式サイトの説明にもあるようにテストプロセスとしていくつかの工程に分かれています。テスト要求分析、テストアーキテクチャ設計などです。
順を追って、要求分析をどのように進めていこうかなど案出しをするのですが、大体の場合ここでは何か一つをベースとする選択をすると思います。誰かの案をベースに、他の人の案を取り込んでいく感じです。例えば、私のチームの場合大枠のベースは私以外のメンバーの案でしたが、リスク分析の要素が入ったのは自分の案があったためだと思います。
この手順を繰り返し、工程ごとの作業を定義したり、成果物を実際に作ったりしていきました。認識を合わせながらの作業だったので大変でしたが、ここまで専門的にテストについてプライベートでの友人と考える機会もなかなかないので貴重でした。
反省しているところ
反省しているのは、「外部の人にレビューしてもらえばよかった」という点です。
チームで作業をしていると、どうしても共通の認識ができてきて、ツーカーな感じになり、疑問を持たなくなってしまいがちです。
私も違和感を覚えることがあったのですが、うまく言語化できずに歯がゆい思いをしました。
外部のレビューアにチェックしてもらうことで、「そもそもここおかしいじゃん」といった根本的な問題を指摘してもらえる可能性があります。
出場してみた結果
結果は、予選敗退でした。
- 要求分析の出来が良くない。要素が出し切れてないし、分解も論理的・段階的になっていないところがある。要件定義書に引っ張られてるところもある
- 完全な要件定義書（テストベース）が存在することを前提として考えているようだが、実際にはそうないケースなのではないか
- ただ単にインプットを機械的に分解していくだけなら人がやる必要はない。人の暗黙知など、「属人化したノウハウ」の活用法にも着目すべき
- ツリーの分解を助けるためにISO25010の品質特性を使っているようだが、説明可能なテストアーキテクチャを作成するためには、そもそも品質特性が何かわかって使っている必要がある。また、なぜ品質特性を選んだのかの説明もしていない
- ゴール指向でテスト設計を行ったようだが、「どうしてそのゴールなのか。違うゴールを設定しない理由はなぜか」説明できるようにすると良い
- 保証すべき品質を、一覧化してリストにしたのはいいが、それをうまくグループ化できるともっとよかった
などなど、審査員の方や聴講者の方などから多くのフィードバックをいただきました。反省点は全くその通りだと思っています。勉強不足、力不足、マネジメント不足など多くの課題を感じました。
これからどうするか
まずは、今回の結果を踏まえ振り返り会をチームでやろうと思います。その中で、今後の活動についてもチームで話し合えたらと思います。もちろん、リベンジの機会があればそれも狙うつもりではいますが、チームの合意ありきですので焦って結論は出さないことにします。合意形成は大切です。我々が今回のコンテストで大事にしたことでもあります。
テスト設計コンテストの楽しいところ
なんだかテスト設計コンテストの恐ろしいところばかり紹介してしまった気がするので、楽しいところについてもご紹介します。
好きな人とチームを組める
仕事でテストを考える場合、なかなか自分の思い通りのメンバーで仕事をできる機会は少ないのではと思います。
その点、テスコンは好きな人とチームを組めるので、そもそも一緒に色々やってて楽しいと思えるメンバーであれば多少辛くても楽しいです。
自分の場合、文書作成や資料作成など、テストに直接関係のないようなところも学べてよかったです。
お金がからまないテストの話ができる
仕事となるとどうしてもお金や工数の関係でやりたいテストができないことがあります。
しかし、テスコンは違います。そういった制約はなく、自分たちでスコープを決めることができます。
そういった点で、「コストを度外視した時に、究極的なテスト設計をするとしたらどうなるか」という探究心のある方にとっては楽しい経験になると思います。
休みの日にみっちりテストの話ができる
ここまでくると変態の域に近づいてきますが、みっちりテストの話で４、５時間議論する機会は仕事でも早々多くはありません。
きっちりテスト計画やアーキテクチャを練るための議論ができるというのは、それだけで価値があるように僕は思っています。テストのこと考えるの楽しいですよね。
おまけ 〜個人的な東京予選チーム評論〜
負けたとは言っても私は「負け犬」だなんて全然全くこれっぽっちも思ってません。おい誰だ言ったやつ。
語弊を恐れずに言うなら「負けは負けだし、私のチームにも不備はたくさんあったよ。けどね、あなた方のチームだって完璧じゃないからね？その辺わかってるよね？」というのが私の本音です。負けは負けだけど、負け犬とかじゃねーから！
というわけで、以下、勝手に東京予選チームにコメントを書きます。
※以下の文章は、本当におまけです。感じたことをそのまま書いているメモなので、あまりまとまっていません。参考にしたい方がいたら参考にしてください。
午前の部
- えびなのめろんぱん
会場からの質問
@mhlycの私見
- テスト要求分析以降のアーキテクチャの設計が不十分だと思う。
- 「テストのポイント」の解説が不十分だと思う。
- 機能テストとユーザ利用テストだけなの？テストすることってそれだけじゃないと思う。
- わんだーズ（決勝進出）
@mhlycの私見
- サプライヤー機能のテストってシステムテストレベルだけで保証できるの？
- 観点の拡充：仕様ビュー、構造ビュー、経験ビュー、欠陥ビュー →これは良い。けど、４つのビューってこの４つで正しいか確認したほうがいい。情報元がどこかにもよるけど。
-
審査員にはテストアーキテクチャの良さを評価されたようだけど、発表聞いた限りではテストアーキテクチャ設計のアウトプットがなんなのかわからない。テストアーキテクチャの構造もよく分からない。
-
各成果物の品質があまりよくない。特に成果物１の中身。ここに情報をもっと入れた方が良いと思う。
- Average40
会場からの質問
@mhlycの私見
- HALTの適用。これを使おうと思った理由は？これを適用しようとして、こうなった理由は？→この質問にきちんと答えられてないと思う。
- テストカテゴリ表について、ブロックごとに分けるといっても、意味のある分け方をしないと見づらくなるし使いにくいと思う。
- 単純にオールペアとしている箇所があるように見えた。なぜオールペアで保証できるのかは説明できるようにすべき。
午後の部
- とある品質保証部
会場からの質問
- ガイドワードって何ですか？
- ガイドワードってよく使われているけど、なんで意味の重なるものを使ったの？
- なぜテストを行うのか／行わないのかを示すことはできるか？
審査員コメント
- 俯瞰性、トレーサビリティの確保はある程度できているが、不足しているテストを見つけ出せないという欠点がある
- 機能と品質特性について、ガイドワードとして品質特性を選択した理由が不明確。品質特性をガイドワードとして漏れたところをどう拾うか考えてほしい。
- 試験に出るカラオケ
会場からの質問
- テストコンテナとして分けなくてもいいんじゃないの？ 分けて何がうれしいの？
- 優先度高い順に３分割したら良いのでは？
- HAZOPのガイドワード：どう使うの？
審査員コメント
- 設計もプレゼンもまとまっていた。
- ガイドワードを使うなど工夫が見られた。
- テストコンテナ：テストアーキテクチャ作成の目的がまとまっているとよかった
@mhlycの私見
- 綺麗なプレゼンだったけど、熟慮はされてないアーキテクチャだと思った。
- もっと本気出せるでしょ
- 紙印テスト倶楽部（決勝進出）
会場からの質問
- テストアーキテクチャとは何ですか？ →段取り
- 段取りとは、次は何をすべきか、というものを指すのか？
- テストタイプとテストレベルは段取りに関係しているのか？
- 単体テストとシステムテストを同時にやる段取りが良いの？
- このアーキテクチャはどうやってできるの？
- 要するに、開発のスケジュールが四角に置き換わっただけ？
- テストのためのアーキテクチャを考えたわけではなく、開発のスケジュールを反映したの？
- テストについて特別に反映したことはないの？
審査員コメント
- 発散したテスト成果物がどう集約されるかが微妙だった。
@mhlycの私見
- マインドマップのブランチをある程度規定しておくのは良さそうだと思った。
- 色々工夫しているのはわかるけど、全体のつながりが全然わからない。
