Waterfall project management separates development and testing into two different steps: developers build a feature and then "throw it over the wall" to the quality assurance team (QA) for testing. The QA team writes and executes detailed test plans. They also file defects when painstakingly checking for regressions in existing features that may have been caused by new work.
多くのチームはこのようなウォーターフォール型または他の古典的なテスト・モデルを使用しているため、製品が大きくなるにつれテスト量は飛躍的に増加し、QA チームは常に付いていくのに必死です。プロジェクト所有者は、リリースを遅らせるか、テストをスキップするかという望ましくない選択に直面します。(99% どちらが勝つか、おわかりでしょう?)一方、開発チームはすでに他の作業に着手しています。つまり、技術的負債が積もるだけではなく、それぞれの不具合に取り組むことにより、コード・ベースの 2 か所の間でコンテキスト切り替えが必要となり、大きな犠牲がともないます。何ともばかげた損害です。
さらに悪いことに、QA チームは昔から、どれだけバグを見つけるかにやりがいを感じており、これでは開発者が守りに入るだけです。開発者と QA 双方にとって、コードのバグを減らしつつ、プロジェクト所有者が強いられる過酷なトレードオフを排除できる、今よりも良い方法があったとしたらどうでしょう? より良い万能のソフトウェアを作れると思いませんか？
アジャイルと DevOps テストに入りましょう。
従来の方法からアジャイルテスト方法への移行
アジャイルと DevOps チームの目標は、持続的に品質を伴う新しいフィーチャーを納品することです。しかし、従来のテスト方法論はアジャイルまたは DevOps フレームワークの内容に合いません。開発ペースに合った、各ビルドで品質を保証するための新しい方法が必要になります。アトラシアンでは、アジャイルなテスト方法を採用しています。Jira Software のシニア QA チーム・リードの Penny Wyatt とともに、テスト方法を詳しく見ていきましょう。
クレジットカードの負債が少しずつ膨らむように、最初は小さな問題だったものが雪だるま式に大きくなり、あっという間にチームの重要なアジリティを脅かします。雪だるま式に大きくなる技術的負債に立ち向かうために、アトラシアンでは、開発者が偉大なチャンピオンになれる力を与えます (というよりも、期待します)。開発者は品質をコントロールする主要なスキルを製品に活かしてくれるものと確信しています。
- 開発者はコードに関する問題を解決することが得意である。
- 開発者は作成したテストが失敗した時に、他の誰よりもそれを修正する能力がある。
- 開発者はフィーチャー要件とテストの意義を理解して、より良いコードを作成するものである。
わたしたちは、バックログの各ユーザーストーリーには、フィーチャーコードと自動化テストコードが必要であると考えています。テストチームが自動化テストを行っている間に開発者をフィーチャーコードにアサインするチームもありますが、ひとりのエンジニアが製品一式のデリバリーを担当した方がより効果的だと思っています。
新しいフィーチャーのバグと既存のフィーチャーのリグレッションは別々に扱いましょう。開発中にバグが見つかったら、時間を割いて間違いを理解し、修正してから先に進んでください。リグレッションが見つかったら (以前は機能していたものが機能しなくなった、など)、再発する可能性があります。将来リグレッションが再発しないよう、自動化テストを作成します。
This model doesn't mean developers work alone. It's important to have QA engineers on the team as well. QA brings an important perspective to the development of a feature, and good QA engineers know where bugs usually hide and can advise developers on probable "gotchas."
探索的テストを通して人の手によるチェック
On our development teams, QA team members pair with developers in exploratory testing, a valuable practice during development for fending off more serious bugs. Much like code review, we’ve seen testing knowledge transfer across the development team because of this. When developers become better testers, better code is delivered the first time.
But isn't exploratory testing manual testing? Nope. At least not in the same sense as manual regression testing. Exploratory testing is a risk-based, critical thinking approach to testing that enables the person testing to use their knowledge of risks, implementation details, and the customers' needs. Knowing these things earlier in the testing process allows the developer or QA engineer to find issues rapidly and comprehensively, without the need for scripted test cases, detailed test plans, or requirements. We find it's much more effective than traditional manual testing, because we can take insights from exploratory testing sessions back to the original code and automated tests. Exploratory testing also teaches us about the experience of using the feature in a way that scripted testing doesn't.
品質を維持するには探索的テストと自動化テストが必要です。新しいフィーチャーが開発されたら、自動化テストのみを実施するのではなく、新しいコードが品質基準を満たしているか、探索的テストを実施してもっと広範な意味で確認します。自動化テストにより発生するリグレッションからしっかりとコードを保護することに加え、使いやすさ、視覚的なデザイン、フィーチャーの無駄全般、などを確認します。
変更は本当に難しい
I'll leave you with a personal anecdote that nicely summarizes my journey with agile testing. I remember managing an engineering team early in my career that had strong resistance to writing automated tests, because "that work was for QA". After several iterations of buggy code and hearing all the reasons why automated testing would slow the team, I put my foot down: all new code had to be proven by automated tests.
After a single iteration, code started to improve. And the developer who was most adamantly against writing tests turned out to be the one who sprung into action when a test failed! Over the next few iterations the automated tests grew, scaled across browsers, and made our development culture better. Sure, getting a feature out the door took longer. But bugs and rework dropped significantly, saving us huge amounts of time in the end.
Change is rarely easy. But like most things worthwhile, if you can buckle down and create new patterns for yourself, the only question you'll be left with is "Why didn't we do this sooner?!"
