普段「イネイブリングQAやってます！」的なことを言ったり書いたりしているからか、QAエンジニアの方から「開発者に対してテスト設計などを広めるのにどんなアプローチをしているのですか？」と質問をいただくことがあります。
これに関して、最良かはわかりませんが比較的納得してもらいやすいと思っている訴求方法があります。それが「レビュー大変じゃないすか？レビューしやすくしましょうよ」です。
この話の前提として、私が普段開発者に対するQA活動のイネイブリングを行っている状況ですが、
- もともとQAが居ない開発組織で、開発者自身でテストも行っている
- 開発者の人数に対してQAが少なく、システムテストをQAエンジニアが行ってからリリース、といった開発プロセスにはできない
- そのため、開発者自身でテストするのは変えず、QAエンジニアは「うまくテスト（等の品質保証関連の活動）できるように支援する」のが主
です。
なので、「普段テストちゃんとしていない開発者にどうテストしてもらうか」ではなく、「普段テストもやっている開発者が、どう効果的・効率的にテストをできるようにするか」を考え、取り組んでいる状態です。
そして、開発者の話を聞く中で見えてきた課題のひとつにレビューのしづらさがありました。QA・テストエンジニアが普段行うようなテストプロセスとは異なり、テストベース（という呼び方もしていませんが）をもとにいきなりテストケースを書き出している、という場合もあり、そうなると開発チームのリーダーや他のメンバーなどレビューする側がやりづらいですよね。やりづらいんですけど、明確な課題意識とまでは発展しづらく、「なんかモヤるな」「上手にやっているとは言い難いな」となる。モヤりつつもレビューで一通り「見る」ことはできるので、なかなか改善の温度感は高まりにくいのかもしれません。
これをなんとかするために、テスト設計やテスト設計技法の考え方を広めています。
開発者に対して説明する際の理屈はこうです。
- いきなり詳細なテストケースの一覧が出てきても、網羅できているかなどレビューしづらいですよね？
- 上記を解決するには、段階的に具体化するのがおすすめ。テストのプロはそうしています。
- まず「何についてテストすべきか」を挙げたうえでチーム内レビューで合意し、その後テストすべき事項について「具体的に何を確かめるか」をテストケースとして考えましょう。
- 一見やることが増えるように見えるのですが、結果手戻りやレビューの手間、テストのヌケモレ防止につながるのでこちらのほうがよいです。
- 何についてテストすべきかを考える際や、具体的に何を確かめるかを考えるにあたって、テスト技法というものが活用できます。
- いたずらにケースを増やすのではなく、ある程度の根拠を持って「このケースで充分だ」という説明がつきます。
開発チームにおいてテストのやり方を見直す場合、その意思決定を行うのはリーダーやマネージャーだと思います。意思決定をする人たちの課題意識や困りごとに訴求することで、自然とテスト設計やテスト設計技法を浸透させようという狙いです。
この流れは良し悪しあるかなと思っています。ストレートに「テスト設計（と技法）を使いましょう！」と言ってアプローチしていく方法もありますが、個人的にはそうした用語なしに「このような理由でこのようなことをしましょう」と説明したうえで、あとから「こういう名前で呼ばれています」のほうがスムーズに進むと考えています。
テストのレビューってなかなか厄介ですよね。段階踏んで詳細化しましょう！ という話をするとわりと納得してもらえます。
・・・と、こんな話を書いたものの、20年前から同じようなことが言われていますね。
ですよね！