2023.03.27
本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。
湯本氏のnote「テストマネジメント虎の巻」はこちら
第1回：いまどきのソフトウェア開発に求められるもの 第2回：新しい開発スタイルの概要 第3回：新しい開発スタイルに合わせたテストの概要 第4回：開発チームとテストチームの関係～成功のための大事な役割～ 第5回：品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い 第6回：テストレベル間のテスト量の関係は？テストピラミッドとの関係も
本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。
湯本氏のnote「テストマネジメント虎の巻」はこちら
前回、開発スタイルの変化に対してテストはどうあるべきかを、紹介した開発スタイルに対して個別に具体例を考えていくよりも、ビジネスの成功に貢献するという本来の目的を意識しながら、これからの開発に役立つソフトウェアテストはどう変わるべきかを考えていくことのほうが重要になると言及し、それは以下の４つに分類できると述べました。
- 開発チームとテストチームの関係
- 品質リスクの許容度合い
- テストレベル間のテスト量の関係
- QA（Quality Assurance）の考え方
ここからは、上記した４つについて深掘りしていきたいと思います。今回は「開発チームとテストチームの関係」についてです。QAが行うようなテストは、開発とは別チームにやってもらうというアプローチから、開発チームにQAが内在するアプローチ（QAが行うテストは開発チームにて行う）にすることがなぜ大事なのかを書いていきたいと思います。
- もくじ
1．QAが行うテスト
ソフトウェア開発の現場では、QAと呼ばれる開発チームと別のチームがテストをすることがあります。QAとは、Quality Assuranceの略称で、「品質（Quality）」に「確信を持つ（Assurance）」という意味です。多くの場合、QAチームが行うテストは、開発者自身でテストした後に行われます。テストレベルで言えば、統合テストの一部、システムテスト、および受け入れテストが該当するでしょう。開発しているソフトウェアを使うユーザーと同じようにUIからデータを入力してテスト対象の機能を動作させ、期待結果と合致することを確認することが多く、そこで問題なければユーザーに使ってもらっても問題ないと判断して本番リリースを行います。
2．テストにおける独立性の度合い
前回の連載にて紹介したJSTQBのFLシラバスには、テストに「ある程度の独立性を確立すると、開発者とテスト担当者の間の認知バイアス(※1)の違いによって、テスト担当者はより効果的に欠陥を発見できる」と書かれています。そのため、テスト担当者は開発担当者とは独立した別のチームとしたほうが良いという考え方があります。QAチームが開発と別の組織となるケースは、これに該当します。
テストの独立性の高さは、大規模開発になるほど効果を発揮します。大規模な開発では、組織ごと役割分担をすることが多くなります。合意事項は、たくさんいる関係者間で誤解がないようにドキュメントに明記します。開発担当者は各自に割り振られた機能を確実に開発するよう全力で取り組みます。
テスト担当者は、それぞれで開発したコンポーネントを統合してユーザーが使うときと同じ状態になったところでテストを行うため、割り振られた機能の開発だけでは見つけられなかった問題に気づくことができ、開発担当者はその問題に関係する欠陥をリリース前に取り除くことができます。一方で、デメリットもあると言われています。以下に前述したJSTQBのFLシラバスに書かれているデメリットを列挙します。
- 開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
- 開発担当者の品質に対する責任感が薄れることがある。
- 独立したテスト担当者は、ボトルネックとして見られたり、リリース遅延で責任を問われたりすることがある。
- 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。
これらについてもう少し詳しく説明をしていきます。
(※1)バイアスとは簡単に言うと、「思い込み」のことです。自分では問題がないと思い込むと自分が作ったものの問題を見つけられなくなるといった心理を指します。
協力関係の欠落、フィードバック提供の遅延、対立
独立性が高すぎると、開発担当者とテスト担当者は、作業場所が異なることが増え、やりとりがドキュメントを通して行われることがほとんどになり、会話をする機会が少なくなります。そのような状況でテストを行い、欠陥があることがわかると、開発担当者の仕事に問題があるのではないかと不信をもってしまい、報告内容にもそのような心情が現れてしまうことがあります。開発担当者は、テスト担当者からの報告をあまり心地よいものとして受け止められなくなります。
さらにテスト担当者は、欠陥を取り除けなければ自分たちのせいだと思うあまりに過剰にテストケースを増やしてしまったり、開発担当者にとってはあまり重要ではないと思うことを欠陥として報告してしまったりします。こうなると協力し合うといった仕事の仕方ができなくなります。テスト担当者は、欠陥を報告する自分の報告内容に欠陥があることを恐れ、開発担当者へ完璧な情報を伝えなければならないと思い、ソフトウェアの不自然な動きに対して時間をかけて調べるようになり、フィードバック提供が遅延してきます。このような関係で仕事を続けると対立が深まってしまいます。
品質に対する責任感
独立したテストチームが最後にテストしてくれるなら、そこで欠陥が見つかった後に直せばよいとも言えます。ただし、その考えが強くなってしまうと、本来、開発者自身がやるべきテストも不十分になり、あまり細かいことを気にせずに開発したものをテストチームへ回して欠陥を見つけてもらえれば大丈夫だと考えてしまう可能性が高まります。
テストがボトルネックとなる
独立したテストを最後に行えばよいとなった場合、テスト担当者が関与する時期が遅れてしまい、人員のアサインや準備が遅れて、開発後すぐにテストを開始できないといった問題が起きることがあります。
また、欠陥がリリースの直前になって多く見つかる可能性が高くなり、テストにかける工数が見積もりよりも増えてしまう場合もあります。前述した協力関係の欠如から、開発者の期待以上に多くのテストを行うように計画をしてしまうことも考えられます。独立性が高くなりすぎると、これらの原因からテストに時間がかかり、ボトルネックとなってしまいます。
重要な情報が伝わらない
テストの独立性が高くなると、開発担当者とテスト担当者のやりとりがドキュメントを通して行われることがほとんどになり、あまり会話をする機会がないといったことが起きることを前述しましたが、これはテスト対象の仕様に関する重要な情報の伝達漏れを起こす可能性も秘めています。
悪意を持ってこのようなことをするわけではなくとも、全てをドキュメントに書いて伝えると言う行為に漏れが起きる可能性があります。だからといって、漏れがないかをチェックする係を設けるといったことをすると、ドキュメントを作る時間が開発本来の時間の大部分を占めるようになってしまいます。
3．開発チームにQAが内在するアプローチ
本連載では、これからの開発はトライアルアンドエラーとチームの垣根を超えて開発をすることが大事だと伝えてきました。そのために開発スタイルが変化していることも連載の中で述べたとおりです。テストの独立性が高くなりすぎるデメリットは、本連載の1回目で言及したサイロ現象そのものです。
そのためには、QAチームが開発の終盤だけテストを行うのではなく、開発のなるべく早い段階からQA チームが行うようなテストを始めることが解決策となります。そのための方法として、QAチームにいるテスト担当者が開発チームの一員となることが考えられます。開発チームの一員となることで、開発の序盤から何が起きているかを理解できます。ドキュメントが全て揃ってからテストの準備をするのではなく、開発の進み具合に合わせてテストを計画し、実行していくことができます。
誰がどこまでテストを行うかを合意しながらテストをする
開発担当者はどこまでテストをし、テスト担当者はどこまでテストをするかを開発チーム内で合意することは、最も大事なことになります。微調整をしながらスピードを速くして開発を進めることでトライアルアンドエラーができるので、微調整をする度に合意が必要です。
合意するためには、目的に対して開発担当者とテスト担当者がどのように考えているかがわからないといけません。ズレがある場合は、早期に調整をすれば問題になりません。アジャイルのプラクティスは、各自がどのように考えているかを常に共有するための仕組みとして活用できます。
チーム全員が品質に確信をもつ
QAがチームに内在すると言うことは、端的に言うとチーム自身が品質に責任を持つということです。そして、連載の第一回目で述べたように、品質は欠陥の数だけで判断できるものではありません。適切なタイミングでリリースすることや、顧客からのフィードバックをいち早く反映していくことも品質になります。
連載の第二回にて、アジャイル開発の特徴としてビジネスと開発の垣根を超えたチームを形成することがあると述べましたが、その中にテスト担当者もチームの垣根を超えて入り、それぞれの専門知識を活かして最適な品質を目指すこと、また開発の中で得た品質の課題を次のイテレーションに活かすことで、チーム全員で品質に確信を持てるようになっていきます。
テスト担当者の専門性をチームに活かす
テスト担当者は、開発の最後にテストをしてきた経験から、テスト対象を部分で捉えるのではなく、ユーザーに近い立場で全体的に捉えることと、これまでに遭遇した欠陥に関する経験が豊富なことが専門性になります。このテストの専門性をチームに活かすことがテストの独立性が低くなった時のデメリットを補います。短いイテレーションで開発を続けていく中でも、全体をつなげてユーザーが使うシーンを想定したテストは必要になります。
テスト担当者は各イテレーションでできるテスト、複数のイテレーションでできるテストを開発チームの計画の中に追加していきます。それぞれのテストではどのような欠陥が見つかる可能性が高いかを考えて、本当に重大な欠陥だけは取り除けていることを確認できると、品質に確信を持てるようになります。
おわりに
今回は、「開発チームとテストチームの関係」について深掘りをしていきました。
これからの開発はトライアルアンドエラーとチームの垣根を超えて開発をすることが大事であり、そのためには、QAが行うようなテストは、開発とは別チームにやってもらうというアプローチから、開発チームにQAが内在するアプローチに変えていくことの意義が理解できたかと思います。その中でもテスト担当者がチーム内では専門性を活かすことが大事であることも理解してもらえたかと思います。
次回は「品質リスクの許容度合い」について深掘りしていきます。
