Engineering higher quality through agile testing practices

それでも手動テストは必要です。でも思っている方法とは違うかも!

Dan Radigan Dan Radigan

ウォータフォールプロジェクト管理は開発とテストを異なる二つのステップに分割します:開発者はフィーチャーを構築し「壁に投げつけ」、QA チームがテストを行います。QA チームは詳細なテストプランを作成して実施します。また、彼らはリグレッション(新しい作業によって生じたバグや再発したバグ)が既存のフィーチャーに見られないか、丹念にチェックしながら不具合を整理します。

Many teams using these waterfall or other traditional testing models find that as the product grows, the amount of testing grows exponentially–and QA invariably struggles to keep up. Project owners face an unwelcome choice: delay the release, or skimp on testing. (I'll give you one guess as to which option wins 99% of the time.) In the mean time, development has moved onto something else. So not only is technical debt mounting, but addressing each defect requires an expensive context switch between two parts of the code base. Insult, meet injury.

To make matters worse, QA teams are traditionally rewarded according to how many bugs they find, which puts developers on the defensive. What if there was a better way for both developers and QA to reduce the number of bugs in the code while also eliminating those painful trade-offs project owners have to make? Wouldn't it create better all-around software?

アジャイルテストに入りましょう。

従来の方法からアジャイルテスト方法への移行

The goal of an agile development team is to sustainably deliver new features with quality. Teams that move to agile often wrestle with how to incorporate testing time at the speed of agile. This is a legitimate challenge, because traditional testing methodologies simply don't fit into an agile context. The pace of development requires a new approach to ensuring quality in each build. At Atlassian, the way we test is agile.  Take a detailed look at our testing approach with Penny Wyatt, Jira Software's Senior QA Team Lead.

Much like compounding credit card debt, it starts with a small amount of pain, but snowballs quickly–and saps the team of critical agility. To combat snowballing technical debt, at Atlassian we empower (nay: expect) our developers to be great champions for quality. We believe that developers bring key skills that help drive quality into the product:

  • 開発者はコードに関する問題を解決することが得意である。
  • 開発者は作成したテストが失敗した時に、他の誰よりもそれを修正する能力がある。
  • 開発者はフィーチャー要件とテストの意義を理解して、より良いコードを作成するものである。

わたしたちは、バックログの各ユーザーストーリーには、フィーチャーコードと自動化テストコードが必要であると考えています。テストチームが自動化テストを行っている間に開発者をフィーチャーコードにアサインするチームもありますが、ひとりのエンジニアが製品一式のデリバリーを担当した方がより効果的だと思っています。

Pro Tip:

Treat bugs in new features and regressions in existing features differently. If a bug surfaces during development, take the time to understand the mistake, fix it, and move on. If a regression appears (i.e., something worked before but doesn't anymore), then it's likely to reappear. Create an automated test to protect against that regression in the future.

これは、開発者が単独で作業するという意味ではありません。チームに QA エンジニアがいるということも重要です。フィーチャーの開発にとって QA エンジニアは重要な視点をもたらすうえ、優れた QA エンジニアはバグが隠れていそうな場所を認識しているため、予測して開発者にアドバイスできます。

探索的テストを通して人の手によるチェック

わたしたちの開発チームは QA チームのメンバーと探索的テストでペアを組み、有益に実践することで深刻なバグを開発中に回避しています。コードレビュー同様、このおかげでテストに関するナレッジを開発チームに伝えることができています。開発者が今より優れたテスターになれば、最初から今より優れたコードに仕上がります。

しかし、探索的テストは手動テストなのでは?いいえ。少なくとも、手動のリグレッションテストとは違います。探索的テストはリスクベースで、批判的思考によるアプローチです。リスクに関するナレッジ、実装の詳細、カスタマーニーズを用いてテストを実施できます。このことをテストプロセスの早い段階で知っていれば、開発者や QA エンジニアはテストケースのスクリプト、詳細なテストプラン、要件などを必要とせず、問題を早急に包括的に発見できます。探索的テストセッションから得た洞察を元のコードや自動化テストにフィードバックすることができるため、従来の手動テストよりもずっと効率的だといえます。また、探索的テストではある意味フィーチャーを使用する体験ができ、それはテストスクリプトで得られるものではありません。

品質を維持するには探索的テストと自動化テストが必要です。新しいフィーチャーが開発されたら、自動化テストのみを実施するのではなく、新しいコードが品質基準を満たしているか、探索的テストを実施してもっと広範な意味で確認します。自動化テストにより発生するリグレッションからしっかりとコードを保護することにくわえ、使いやすさ、視覚的なデザイン、フィーチャーの無駄全般、などを確認します。 

Change can be hard–really hard

アジャイルテストの経験がうまくまとまった個人的なストーリーをお話しましょう。仕事を始めたころに管理していたエンジニアチームのことをわたしは今でも覚えています。そのチームは、自動化テストの作成に強い抵抗を持っていました。何故なら「それは QA の仕事」と思われていたからです。バグとなるコードが何度となく繰り返し作成され、自動化テストがチームの仕事を遅らせると彼らが考えるすべての理由を聞きました。それからは、わたしは断固として譲りませんでした:新しいコードは自動化テストで実証する必要がある。

一度のイテレーションのあと、コードは良い方向に向かい始めました。テストを作成することにもっとも反対していた開発者が、テストが失敗すると一番早く行動を起こすようになったのです。何度かイテレーションを繰り返すうち、自動化テストも改良され、複数のブラウザをカバーする規模になり、わたしたちの開発カルチャーも良い方向に向かいました。フィーチャーの完成までには、今までより長くかかりました。しかし、バグとやり直し作業が激減し、結果的には莫大な時間を節約できました。

変更が簡単であることは滅多にありません。ですが、多くのことに価値があるように、新しい方法に取り組めば、「なんでもっと早くやらなかったのだろう?」という疑問しか残らないはずです。

次の記事
Incident response