Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

開発エンジニアとQAの心理の違いとは何か？

この記事は Akatsuki Advent Calendar 2020 3日目の記事です。
前回は bluexxsun さんの スプレッドシートの関数では "" を使うな！ でした。

はじめに

アカツキでエンジニアをやっている tomotaka-yamasaki です。
この記事では、エンジニアとQAがどのように協力しあってソフトウェアを開発していけば良さそうか、をJSTQBの内容を取り上げつつ書いています。去年のアドベントカレンダーではゲームプログラミングのHP計算システムアンチパターンという記事を書いていました。
hackerslab.aktsk.jp


現在、私はアカツキの子会社であるアカツキ福岡に在籍しており、QA業務の効率化やテスト自動化などを行うチームを立ち上げて、活動しています。私自身、エンジニアとして手は動かしたいので、効率化、自動化を行いながら、QA組織がより良い方向に向かうための手助けも行っています。

この記事を書こうと思った理由

QA組織に直接関わるようになってからテスト関連の知識をメインに取り入れていました。その中で特に印象深かったのは JSTQB*1 です。JSTQBはテスト技術者資格の名称ですが、公開されているシラバスや公認書籍である ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 に書かれている内容はソフトウェアテストの原理原則です。
www.shoeisha.co.jp


ゲーム開発を経験していた私はその中身を読んで、分かる分かる！と頷きまくっていました。資格試験のシラバスや書籍なので内容はお堅めなのですが、人に紹介するときは、あるある本、と言っています。

f:id:t-yamasaki11:20201203172525p:plain

この記事は ｢QAが普段考えていること、思っていること、大切にしていることを開発エンジニアにも知ってもらいたい｣ という想いで書きました。
弊社の話ではなく一例ですが、
｢QAチームのAさん、いつも細かい不具合ばかりを指摘してきて辛いんだよなぁ…｣
や、
｢開発エンジニアのBさんに不具合報告すると機嫌悪くなるから言いたくないなぁ…｣
など、開発エンジニアとQAメンバーですれ違いが起きているケースは少なからずあると思います。なぜすれ違いは起きるのか、理由は様々なのでこれだ！という解決策を提示することはできませんが、JSTQBを勉強してみて、開発チームが目指した方が良い方向は見えてきた気がしました。

まとめのような話を最初に書きますが、開発エンジニアとQAメンバーはお互いを理解し、尊重することが開発プロセスを円滑に進めるための第一歩だと思います。不具合を出さないためのテスト計画、テスト技法などの具体的な話も重要ですが、それらは良いスタンスの上に積み上がるものだと私は考えています。

前置きが長くなってきたので、そろそろ本題に入ります。｢何｣を理解すればいいのか、読んでいただける皆様に新しい気付きがあれば幸いです。

この記事のターゲット

  • ソフトウェア開発を行っているエンジニア
  • 開発エンジニアとQAメンバーがなぜかよくぶつかるなぁと思っている方
  • エンジニアは何考えているかよく分からないなと思っているQA関係の方

QAチームを｢テストの7原則｣から理解してみる

ソフトウェア業界では様々な原理原則が存在しますが、JSTQBの元となっている ISTQB*2 では テストの7原則 として定義されています。普段開発に関わっているエンジニアやQAメンバーは、感覚や経験により理解しているかもしれません。とはいえ、言語化されていることは大変ありがたいことです。この7原則で語られている内容はテスト計画の基盤であり、QAメンバーがテストをする上で大切にしていることです。テストを語る際の共通言語にもなり得ると思っています。

テストの7原則

  1. テストは欠陥があることは示せるが、欠陥がないことは示せない
  2. 全数テストは不可能
  3. 早期テストで時間とコストを節約
  4. 欠陥の偏在
  5. 殺虫剤のパラドックスにご用心
  6. テストは状況次第
  7. ｢バグゼロ｣の落とし穴

私の意見も交えながら順番に説明していきます。

1. テストは欠陥があることは示せるが、欠陥がないことは示せない

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。*3

欠陥とはバグのことだと思ってください。欠陥が無いことの証明は、いわゆる悪魔の証明です。一定のテスト期間を経て欠陥が全て修正され、1週間欠陥が見つからなかったとしてもプロダクトの品質が高いことの証明にはなりません。なぜならテスト自体に不備があり、欠陥を発見できていないパターンを排除できないためです。
なので、QAチームはテストに不備がないかどうかを、発見した欠陥数を見て判断したりします。欠陥は必ず出るものだと認識し、テスト実行数と欠陥発見数を比較します。これまでの実績があることが前提になりますが、テスト実行数のわりに欠陥数が不足している場合はテストの不備を疑います。

また、この原則が存在するため、｢テストの終了基準は欠陥がなくなること｣にすることはできません。どうすればテスト終了なのかを定義することはQAチームの役割です。ISO/IEC 25010で規格されている品質特性を満たす、という定義も考えられます。いずれにしても、定義への合意は開発チーム全体で行うことだと思います。

2. 全数テストは不可能

すべてをテストすること(入力と事前条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。*4

おそらく原則2を満たすことができれば原則1の証明になるんですが、現実はそこまで優しくできてはいません。電卓のようなアプリケーションですら全ての入力と計算を網羅することはできません。ゲームアプリケーションはもっともっと複雑です。スキルの組み合わせ爆発が起きている、なんて話を色んな所で耳にします。
同値分割というテスト技法のように組み合わせを減らす考えも重要ですが、ここで私が一番重要だと思うことは、テストには実行優先度があるということです。優先度をつけると以下のようなケースで役に立ちます。

  • リリースタイミングが迫っていて、工数が足りない場合
  • リグレッションテストの工数がテストスケジュールを圧迫している場合

どのテストから行うべきかを予め決めておくことで、いざというときに即時対応できます。更に、テストケースを削減するタイミングで、どの程度品質が落ちるのかを明言できると素敵です。リスク分析は実行優先度を決めるための手段の一つであるとも言えます。

また、作り手である開発エンジニアの方が優先度を付けやすいケースもあると思います。ユニットテストである程度品質が担保されている箇所や、同じ関数を使用している箇所があれば優先度を下げることもできるはずです。開発エンジニアが協力して、テストにかける労力を減らせると良いなと思います。

3. 早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。*5

QAを｢最後の砦｣と呼ぶこともありますが、私はそう呼ばれないようになるのが本来のQAの在り方だと考えます。砦ではあるけど、最後ではなく、出来ているところから見ていくような、開発と同時並行で検証できるのが理想です。

テストはテスト対象が完成してから始まるものではありません。開発エンジニアが設計を行う前、ディレクターが仕様書を作り始めるところからテストは始まっています。QAメンバーが仕様書をレビューし、仕様の抜け漏れをチェックする、ゲームであれば面白いものなのかをチェックする、などの行為もテストに該当します。
最後の最後に検証すると、欠陥が見つかったときのコストが早期発見したときと比べ、2,3倍にも膨れ上がります。テスト工数にいくらバッファを積んでもスケジュールを圧迫してしまうのは、このような影響要素が多すぎるからです。従って、シフトレフトによってできる限り早期にテストし、テストプロセスに影響する不確定要素を排除することができます。

アカツキのQAメンバーは、仕様書ができた段階でテスト観点を洗い出し、その仕様を実装するメンバーで観点をレビューしています。そうすることで膨大なテストケースを作る前にテストの抜け漏れを発見することができ、欠陥の早期発見に繋がっています。

一方で、開発エンジニアはCIによってPull Requestごとに自動テストを回せるようにしています。ソースコードが本流にマージされる前に欠陥を見つけることは大変効果的です。
このように、開発エンジニアとQAの双方がシフトレフトの概念を理解し、実施していくことが大切だと思います。

4. 欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。(原則2で触れたことと同様)。*6

ゲームアプリケーションだと、インゲームのような複雑な処理を行うコードは欠陥が混入しやすい箇所だと思います。開発エンジニアはソースコードを読むことができるため、｢複雑な処理を行うことでコードが複雑になっていたり、場当たり的な対応を行っている箇所だったり、に欠陥の偏在があるだろう｣、と推測することができますが、QAメンバーは過去の欠陥の傾向などから偏在を推測するケースが多いと思います。欠陥の偏在箇所を特定することは、テストの優先度を決定することに繋がります。そこを優先的にテストすることで早期に欠陥を見つけることができます。

欠陥の偏在を見つけるためにはエンジニア的な視点が必要だと考えています。エンジニア的視点とは、システムの概要を理解する、データ構造を理解する、ソースコードを読み複雑度を理解する、などです。発生する欠陥を推測するテスト技法はエラー推測とも呼ばれますが、偏在箇所を合理的に推測することができれば効果的にテストを行うことができます。QAチーム側でエンジニア的視点があるメンバーがいれば良いですが、それは稀有なので開発エンジニアがQAチームにエラー推測の観点を伝えることが重要だと考えます。

また、Aさんは開発スピードは早いが欠陥は多い、などの開発エンジニアの特性を伝えることも一定効果はあると思います。ただし、そこでAさんを批判するべきではありません。欠陥が多い、という事実にフォーカスして非難にならないように伝えることが大切です。

5. 殺虫剤のパラドックスにご用心

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある(殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する)。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。*7

同じシステムに対して、同じテストを繰り返していても新しい欠陥を見つけることができないことは理解できます。ただ、ゲームアプリケーションは高い頻度でアップデートを行っているため、同じシステムで動き続ける期間は短めです。コードの変更によるデグレード(リグレッション)を防ぐために行うテストがリグレッションテストですが、この場合に限り、殺虫剤のパラドックスは有益なものとなります。リグレッションテストは繰り返すことで初めて効果を発揮します。これまでと同じ挙動をしているかどうか、認識しているコード修正の影響範囲以外の箇所で欠陥が残っていないかなどを網羅的にテストすることが可能です。

しかしながら、リグレッションテストは広範囲を網羅的にテストしがちなので、手動で、繰り返し行うと工数が膨れ上がります。そのため、アプリケーションのアップデートごとに1周だけテストするのみ、という場合も多いと思います。

リグレッションテストは繰り返し行うことで効果を発揮するため、最も自動化に向いていると言われています。このテストをうまく自動化し、CIに組み込むことができれば原則3の早期テストに大きく貢献することができ、QAの工数を削減することができるはずです。自動化はQAだけでは実現困難なので開発エンジニアの手が必要になります。SETと呼ばれるテスト自動化を専門とするエンジニアに依頼するのも一つの手段だと思います。

6. テストは状況次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる。*8

ここで得られる重要な示唆は、全てのテストには目的が存在する、ということです。状況が異なれば、テストの目的も変わり、それによってテストの方法も変わります。JSTQBにはテストプロセスの原理原則は書かれていますが、それは単なる武器に過ぎません。何を、どのように使用するかを計画することがQAの役割です。開発エンジニアがテストに関心を持ち、QAメンバーとテストの目的について議論することはとても有意義だと思います。自ら書いているユニットテストの目的について考えてみてもいいかもしれません。

7. ｢バグゼロ｣の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。*9

欠陥を全て見つけること、そして全てを修正することを目的に置いてはいけません。欠陥を修正した結果、システムにどういう影響が発生するのかを認識しないといけません。欠陥は修正できるが、操作性が失われる、ソースコードのメンテナンス性が失われるなどデメリットが大きければ第三の案を考える必要性も出てきます。

しかしながら、QAメンバー全員が欠陥の修正方針を考えられるわけではありません。システムの内部構造まで理解していないと修正方針は立てられないからです。修正することでどのような影響があるのかを考えることは開発エンジニアの役割です。欠陥に対して、開発エンジニアとQAメンバーは真剣に向き合わなければなりません。そのために、最高品質のプロダクトをリリースする、といった共通の目的を設定すると良いと思います。

開発エンジニアとテスターの心理の違い

開発エンジニアの確証バイアス

人には ｢確証バイアス｣ と呼ばれる心理的要素が存在します。

確証バイアスと呼ばれる人の心理の要素は、持っている信念に合わない情報を受け入れがたくする。例えば、開発担当者は、コードは正しいという思い込みがあるので、確証バイアスにより、コードが正しくないということを受け入れがたい。*10

開発エンジニアは確証バイアスによって自分のコードに自信を持っているケースがあります。ここでいう自信は、｢私の書くコードにバグなんてありえない！｣というものではありません。自分で作ったから内部構造も分かる、Pull Requestを出しコードレビューも行った、更に自分で入念に動作チェックもしたから問題ない、その過程で出たバグは潰したからもう他には存在しないだろう、という論理ありきの自信です。しかし、その努力、行動の結果、確証バイアスが生まれると思っています。

自分を客観視しないと確証バイアスは無くなりません。自分以外のエンジニアがコードレビューすることによって下がりますが、それでもエンジニアとしての確証バイアスがあるため、0にはならないと思います。確証バイアスがあると、欠陥報告が自分への非難と捉えてしまう場合があります。


確証バイアスがあることを前提に、QAメンバーはJSTQBで定義されている以下のスタンス*11 でテストに臨みます。

  • 対決ではなく、協調姿勢で開始する
    • 全員のゴールは、高品質のシステムであることを再認識するとよい。
  • テストの利点を強調する
    • 例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
  • テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする
    • 客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。
  • 他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する
  • 自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する

開発エンジニアとQAのマインドセットの違いを理解する

f:id:t-yamasaki11:20201203172529p:plain

開発エンジニアとQAの仲が悪い、という話を聞いたことはありませんか？

開発担当者とテスト担当者は、異なった考え方をすることが多い。開発担当者の主目的は、プロダクトを設計して構築することである。テストの目的は、これまでに説明しているように、プロダクトの検証と妥当性確認、リリース前の欠陥の検出などである。このように目的が異なっており、異なるマインドセットを必要とする。両者のマインドセットを組み合わせることで、より高いレベルのプロダクト品質を達成できる。*12

仲が悪くなってしまう原因として、開発エンジニアとQAでマインドセットが異なるから、ということが考えられます。お互いに興味関心ごとが違うため、意志決定と問題解決において前提とするものと優先する方法が異なり、それが両者の壁になります。

開発エンジニアのマインド

解決策の設計と構築に大きな関心があります。また、確証バイアスが自分自身の作業中に犯した誤りを見つけることを困難にしています。

QAのマインド

好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さない注意力、良好で建設的なコミュニケーションと関係を保つことに関心があります。また、テスト担当者のマインドセットは経験を積むに従って成長し成熟する傾向があります。


重要なことは、まず、開発エンジニアとQAがお互いに持っているマインドの専門性を理解し、不足している部分を補完し合うことだと思います。そしてプロダクト品質を向上させる、といった共通の目的を軸に議論することが大切だと考えています。この内容は、TeamGeekで紹介されている HRT(謙虚、尊敬、信頼)*13 と似たものを感じました。

まとめ

冒頭でもお話しましたが、この記事は、QAが普段考えていること、思っていること、大切にしていることを開発エンジニアにも知ってもらいたい、という想いで書きました。QAが大切にしていることは、テストの基盤となる考え方であるテストの7原則や、相手を非難せず協調姿勢でいる、といったヒトではなくコトに向かうスタンスです。そして、開発エンジニアとQAのマインドの違いについても紹介しました。互いに理解し、共通の目的を持つことでエンジニアとQAのシナジーが生まれ、健全な開発が行えると信じています。

補足: 所属チームの取り組みについて

現在は、A4というチームに所属し、今回書いた内容などを基にQA組織の在り方を再構築しています。他にも業務効率化やテスト自動化なども行っていますが、アカツキ福岡でA4チームが大切にしていることは以下にまとめています。
fukuoka.aktsk.jp

A4チームの取り組みについて、記事を書いてもらいました。せっかくなので紹介させてください。
www.wantedly.com

長々と書いてしまいましたが、ここまで読んでいただいた方、本当にありがとうございます。
この記事が新しい気づきになりましたら幸いです。

===

*1:JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB(International Software Testing Qualifications Board)の加盟組織として2005年4月に認定されています。 JSTQB認定テスト技術者資格-JSTQBについて-

*2:ISTQB® has created the world's most successful scheme for certifying software testers. As of October 2019, ISTQB® has administered over 920,000 exams and issued more than 673,000 certifications in over 120 countries world-wide. The scheme relies on a Body of Knowledge (Syllabi and Glossary) and exam rules that are applied consistently all over the world, with exams and supporting material being available in many languages. Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board

*3:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.17

*4:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.17

*5:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.17

*6:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). pp.17-18

*7:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.18

*8:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.18

*9:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.18

*10:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.25

*11:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.26

*12:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.26

*13:Brian W. Fitzpatrick, Ben Collins-Sussman, 角 征典 (2013). Team Geek ―Googleのギークたちはいかにしてチームを作るのか オライリージャパン pp.15-18.