品質保証を短期間に実現する方法

品質保証 (Quality Assuarance) ではなく、品質支援 (Quality Asssistance) を行う

Laura Daly Laura Daly
トピック一覧

従来のテスト方法をアジャイル文化に持ち込むのは難しいです。チームは開発速度向上のために、製品の品質を犠牲にさせられていると感じてしまいます。

この問題に対処するために、Atlassian のチームはこれまでとは異なるアプローチを開発してきました。アジャイルテストにおける「品質支援 (Quality Assistance)」として知られています。品質に対する責任を負うチームを別に作る代わりに、品質支援エンジニアの小さなチームが、持続可能なテスト方法を開発チーム全体に対して説明し、指導しています。これらの方法についてご覧ください。

  • 品質の文化を作り出す
  • テストの責任を開発者に戻す
  • バグを見つけるのではなく予防する

Q & A

65 人のエンジニアが、たった 6 人の QA エンジニアとともに、高品質の製品を開発して迅速に出荷した詳細について、このプレゼンテーションの Q&A をご覧ください。

Q1: 開発者がこのような考え方に基いてスピードアップするようになるまでにどのくらいの期間がかかりますか?

A1: 個人を変えるよりも、チーム全体の文化を変える方が困難です。Jira Software チームが現在の品質マインドセットのレベルに到達するには 5 年かかりました。しかし、新人の開発者はそれほど長い時間をかけなくても追いつくことができます。彼らは既存の開発部門の仲間からマインドセットをすばやく吸収し、ペアリングやワークショップなどを通してテストスキルをすぐに獲得します。最も困難なのは、リスクと製品に関するすべてのナレッジを得ることです。何年もかかる場合がありますが、当社では QA キックオフや QA デモにおいてナレッジを共有し、それを軽減しています。

Q2: テストケースはまだ必要ですか? 回帰/自動テスト専用ですか?

A2: スクリプト化された手動テストケースは、当社の戦略にはまったく入っていません。テストが単なる「チェック」、つまり事前定義されたステップと定義された判定のセットであれば、人間ではなくコンピューターが実施した方が、より効率的でエラーも少なくなります。テストが本当にテスト、つまり批判的思考、調査、リスク評価などを必要とする場合であれば、探索的テストの実施の一環として行う方が良いでしょう。テストにおける自由度を高め、知識の獲得を期待するためです。

Q3: 開発者の人件費は一般的にテスターよりも高額です。開発者にテスターを兼任させた場合、人的リソースに対するコストの面で非効率になりませんか?

A3: 開発者を別のテストステップを実行するテスターとして使用すると、高額で、開発者の時間の無駄です。ですが、テストを完全に別の手順にした場合、テスターが 1 人であっても高額で、開発者の時間の無駄にもなります。テスターから開発者にストーリーやバグが報告されるたびに、テスト費用だけではなく、開発費用も発生します。当社では、不合格率を 100% から 4% に下げることで、開発時間を大幅に削減してきました。リリース前に行っていたストーリーの手直しや、些細なバグの修正に費やしてきた無駄な時間を、です。社内で発見されたバグの調査、報告、トリアージ、評価、再現、修正に費やす時間も削減しました。開発者は自分たちがテストを実施しなければならないと分かっているため、よりテストしやすい方向でコードを最初から設計します。当社の DoTing (developer-on-testing) は、品質を押し上げるために必要な中間ステップでした。テストステップを別途設ける必要はなくなりました。それは、より大きな利益をもたらす一時的な投資でした。

Q4: 開発者と QA テスターのタイムゾーンが異なっています。このモデルは同じタイムゾーン内でのみうまくいきますか? リモートチームとはどのように連携しますか?

A4: 当社ではオーストラリアを拠点とする QA エンジニアとともに、ポーランドとベトナムのチームにおいてリモートで品質支援を行ってきました。優れた品質支援エンジニアであるために必要なことの大部分は、開発部門との人間関係の構築です。したがって、有能な QA がオンサイトにいる方が効果的です。リモート QA エンジニアには連絡が行き渡らないことが多く、チームの全体的な文化を測定するのはより困難です。ただし、当社ではビデオ会議を利用して、リモートでの QA デモ、QA キックオフやペアリングセッションを問題なく実施しています。開発者が QA に連絡してビデオ会議を始め、マシン上で画面を共有するだけです。

Q5: QA ノートはストーリー単位ですか、または QA ノートのナレッジベースを構築していますか? 繰り返し発生するリスクにはどのように対処していますか?

A5: QA ノートはストーリーごとに作られます。そのため、通常繰り返し発生するリスクのパターンを見つけ出すのは QA エンジニアです。各 QA エンジニアが必ずしも、他のメンバーの知っていることを把握しているわけではありません。そのため、時が経過して Jira Software の QA チームが大きくなるにつれ、困難が生じてきました。現在まで、毎週の知識共有ミーティングや、共通のリスクや予期しないリスクを記録する Wiki ページでこれを軽減してきました。しかし、これ以上拡張できないというところまできています。現在、当社ではより構造化され、各コミットで実行するルールのデータベースが入ったナレッジベースに取り組んでいます。例えば、Jira Software のコード内で User オブジェクトを使用している場合、「現在のユーザーが匿名の場合、User オブジェクトは NULL になる場合があります。必ず正しく処理するようにしてください」と課題に対するコメントを追加することになります。これにより、QA 見出しから知識を取得することが出来、最善のケースシナリオでは、QA デモやキックオフの必要性がなくなる可能性もあります。これは非常に便利です。

次の記事
Technical debt