違和感について考えてみた①「このフェーズで見つけるべきバグと言う分類方法」

こんにちは、アジャイル開発推進グループに所属するQAリードの佐藤です。外の活動では、「なそ」と呼ばれています。
今日は、普段感じる違和感について考えてみたいと思います。

「これ、XXテストで見つける障害だよね」に違和感を感じる

障害を発見したときに、会話でよく聞くフレーズがあります。 

「これ、単体テストで見つける障害だよね」と。

例えば「単体テストで見つける障害がXX件ありました」という報告をしたときに、「いやいや、これはこう言う理由で単体テストでは見つけることが難しい」という議論になった方もいるのではないでしょうか？
なぜ、こんなことになるんでしょうか？

単体テストはフェーズ？ なんだろう？

テストの用語は、なかなかに複雑です。特にフェーズを表す『テストフェーズ』と『テストレベル』は企業、チーム、人によって解釈が違います。
さらに複雑にするのは、何をテストするかという『テストタイプ』があります。

「いつ」「どのように」「何を」が混ざっているので複雑になります。
JSTQB 用語集の記載を見てみましょう。

テストフェーズ
テスト活動をプロジェクト中で管理（マネジメント）しやすいフェーズにまとめたセット。たとえば、あるテストレベルの実行活動。

テストレベル
具体的にインスタンス化したテストプロセス。

テストタイプ
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。

なるほど、わからん。

自分なりの整理ですが、 『テストフェーズ』は、テスト活動をまとめたセットなので、「いつ」ですね。内容は『テストレベル』と『テストタイプ』を内包していますね。

『テストレベル』は、具体化されたテストプロセスなので「どのように」ですね。ここは『テストタイプ』を内包してますね。

『テストタイプ』は、特性に対するテストの活動ですね。「何を」にフォーカスしています。

ひとくちに「単体テスト」と言っても、「いつ」「どのように」「何を」が複雑に入り混じっているので、ここでいう「単体テストで見つける障害だよね」が人によって解釈の違いが起こります。

テストの専門家でも混乱する

私も現場に行ったら、複数の解釈で使われる言葉に遭遇しますし、解釈違いを起こしてしまう語りかけをしていることに気づくことがあります。
特に、テストエンジニアと開発者で線を引くことが多い部分に対して、盲目的な信頼を置くことがあります。すべての言葉を定義できないがゆえに発生してしまいます。すべてを取り除くことはできないことはできないですが、軽減は可能です。

解釈違いが発生しやすいのは、テストレベルとテストタイプが入り混じっていることに気がついていないときですので、知らないうちに意図がズレてしまうことがあります。そうして進んだプロジェクトは、いざテストするときに混乱が発生します。「あれ、ここテストしていない？？」と、そこで気がつくこともあります。

いつもどうしている？

まずは、『テストフェーズ』『テストレベル』と『テストタイプ』を明確にします。その上で、「いつ」「どのように」「なにを」をホワイトボードとかで整理していきます。

スケジュールを見ながら「いつ」を決め、「どのように」「なにを」を誰（開発者、テストエンジニア他）が対応するかを協議します。そうすることで、テストの全体像を把握することができます。全体像の把握ができることでテストが整理できます。

それでも、漏れたりします。その時は、テストタイプの定義に認識不足、漏れや不備があったとふりかえりを実施します。ここをきちんと説明しようとすると、文章量が多くなりそうなので別途まとめていきます。

混乱と衝突を起こさないために

最初の議題に戻りますが、「これ、単体テストで見つける障害だよね」は何にフォーカスすべきでしょうか？

私は、テストタイプにフォーカスすべきだと思っています。 障害を分類していく中で共通項が見つかります。それをテストタイプに置き換えることで、テスト活動の中での穴を見つけたということになります。 建設的に開発と一緒にその穴を埋める活動ができます。

「テストエンジニア V.S. 開発者」から、「障害、システム V.S. テストエンジニア＆開発者」の構造にしましょう。

違和感と付き合うために

ん？と思ったことは、書き留めるようにしていますが、今回は定期的に思い出す違和感だったので、自分自身の整理のために書き出して見ました。

また、違和感を感じたら書き出していこうと思います。普段気になる違和感がある方いらっしゃったら、ぜひ共有してください！

それでは、アジャイル開発推進グループの なそ こと佐藤がお送りしました。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

執筆者プロフィール：佐藤 博之
SIerで要件定義から保守までを経験。テスト工程で炎上するプロジェクトで品質について考えた結果、品質保証を業務とするSHIFTに転職。SHIFTでは、アジャイル開発の品質保証を担当し、短いサイクルの中でのテストエンジニアの活動や品質について考えている日々。
発散は得意だけど、収束は苦手なファンタジスタタイプ。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/