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

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

Laura Daly Laura Daly

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

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

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

Q & A

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

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

A1: It’s harder to change the culture of a whole team than it is to transform individuals. It’s taken us five years to get the Jira Software team to the level of quality mindset it has today, but it doesn’t take each new developer very long to get up to speed. They quickly pick up the mindset from their fellow existing devs, and they soon pick up the testing skills via pairing and workshops. The hardest part is picking up all the knowledge of risks and the product. This can take years, but we mitigate this through knowledge-sharing in QA kickoffs and QA demos.

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

A2: Scripted manual test cases don’t come into our strategy at all. If a test is just a ‘check’ – that is, a set of predefined steps and a defined assertion – we find it is more efficient and less error-prone to have it executed by a computer instead of a human. If a test is genuinely a test – requiring critical thinking, freedom to investigate and risk assessment – we find it is better to execute it as part of exploratory testing in order to include that freedom and intelligence in the testing.

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

A3: Absolutely, using developers as testers to execute a separate testing step is expensive and wasteful of developer time. But having a separate testing step at all – even one executed by testers – is expensive and wasteful of developer time. Every time a story or bug is pushed back from testers to developers, it’s not just a testing cost, it’s a developer cost. By dropping the rejection rate from 100% to 4%, we’ve saved a lot of development time that was being wasted on reworking stories and fixing stupid bugs before release. We’ve saved the time spent on investigating, reporting, triaging, assessing, reproducing, and fixing internally-found bugs. And the code is designed from the ground up in a more testable way because the developers know they’re the ones who will have to do the testing. Our DoTing (developer-on-testing) stage was an intermediate step along the path of pushing quality upstream, so that we could remove the separate testing step entirely. It was a temporary investment that has more than paid off.

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

A4: We’ve done remote quality assistance with teams in Poland and Vietnam, with the QA engineer based in Australia. It’s not as effective as having skilled QA onsite, as a big part of being a good Quality Assistance engineer is building a personal relationship with your devs. A remote QA engineer is easily cut out of the loop, and it’s much harder to gauge the overall culture of the team. However, we were able to successfully run remote QA demos, QA kickoffs, and pairing sessions via video calls – just calling directly from the dev’s machine to the QA’s and sharing the screen.

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

A5: QA notes are on a story-per-story basis, so it’s usually the QA engineers that spot the patterns of recurring risks. This has become harder over the years as our Jira Software QA team has grown, as each QA engineer doesn’t necessarily know what the others know. Until now, we’ve mitigated this with weekly knowledge-sharing meetings, and wiki pages where we keep track of common or surprising risks. We’re getting to the point where this no longer scales. Right now we’re working on a more structured knowledge base with a database of rules that are run over each commit. So, for example, if it sees you’re using the User object in your Jira Software code, it would add a comment to the issue saying, “The User object can be null if the current user is anonymous, please make sure you’re handling that correctly”. This will help us get the knowledge out of QA heads and, in the best case scenario, may even replace the need for QA demos and kickoffs. That would be helpful!

次の記事
技術的負債