回帰テストを自動化することは必ずしも最適解ではない。2018 fall Online Testing Conferenceで、Brendan Connolly氏はこう主張した。彼は「手動回帰テストマニフェスト」を発表し、それを使うことで、機能テストと回帰テストを区別し、テストを自動化するかどうか決める方法を紹介した。
手動回帰テストマニフェストは、アジャイルマニフェストに示された価値をモデルにしている。これはオープンな目的の宣言であり、品質について話し合い、テスターがそれにどのように貢献するかを探るためのフレームワークだ。
Connolly氏は「テスト」の問題、特に回帰テストを解決する銀の弾丸がほしいという要望があるようだ、と述べた。適切なツールを購入し、すべてのテストを自動化し、それをAIにやらせたいわけだ。これらに価値がないわけではない。ただ、ウォーターフォール・ソフトウェア開発の時代に集めてきたような規範的なアプローチを当てはめようとしているように見える、Connolly氏は語る。
手動回帰テストマニフェストには5つの価値がある。
- バグよりも動作を
- 正しさよりも一貫性を
- 実装よりも意図を
- 複雑よりも調和を
- 完全よりも普通を
アジャイルマニフェストとまったく同じように、前者に価値がないわけではなく、後者をより重視するだけだ、Connolly氏は語る。
アジャイル革命は、プロセスやツールよりも、コミュニケーションとコラボレーションに価値があることを示した。テストとQAの分野にも同じフォーカスが必要だ。テストは個人的なプロセスであり、適切な言葉を見つけるのに苦労するので、難しいだけだ、彼は語る。
2018 fall Online Testing Conferenceで、Procore Technologiesで上級品質エンジニアを務めるBrendan Connolly氏は、手動回帰テストについて語った。講演後、InfoQは彼にインタビューした。
InfoQ: どうして手動回帰テストにマニフェストが必要なのですか？
Brendan Connolly: テスターとしてのモチベーションを駆り立てているスキルと意図を伝えることは、価値を示すための入り口です。難しいのは、ソフトウェア開発ライフサイクルを通じて、テストとその望ましい結果がなぜどのように変わるかを、うまく表現することです。
回帰テストは、テスターとマネジメントの双方によく誤解されているものの1つです。よくあるアドバイスは、その痛みを取り除くために自動化しよう、というものです。しかし、あらゆる場合にそうできるわけではありませんし、そこには費用対効果がないかもしれません。回帰テストだからといって、すぐに自動化すべきだと考えてはいけません。そこで、物事を明確にして話し合えるようにするために、オープンな目的の宣言があると役立つと思っています。
InfoQ: バグよりも動作を、はどんな考えですか？
Connolly: 特に新米テスターの場合、バグを見つないと、貢献していないように感じてしまいがちです。
問題やバグを探すべきタイミングは、機能テストです。回帰テストの目的は、崩壊を最小限に抑えることです。意図せず、新しい機能が既存の機能を邪魔してほしくないのです。バグを探すために回帰テストをやり始めると、結局、かなりの時間をかけて機能を再テストすることになります。私の経験だと、最近の変更とは無関係なマイナーな問題を見つけたり、チームが無視することにした昔からあるバグを再発見したりすることが多いです。
ええ、あなたはバグを見つけるでしょう。でも、それが重要かつ最近の変更に関係しているのでない限り、あなたが実際にやったことはチームの注意をそらすことです。回帰テストで見つかったバグはいずれも、リリースの圧力と天秤にかけられます。これはチームとの信頼を傷つける恐れがあります。あなたは新機能を顧客に届けるよりも、バグを見つけることを重視しているように見えてしまうためです。
変更があっても、顧客が期待し頼りにしている動作を確実に提供し続けることの方が、重要なのです。
InfoQ: 完全よりも普通を、という価値は何を意味しますか？
Connolly: ほとんどのテスターは、そのキャリアの中でいつか、すべてをテストしたのか質問されます。現実には、テスターがトレードオフをしないプロジェクトというのは意味がありません。テスターは使える時間の中で、リスクを最大限に低減するために努力しているのです。
回帰テストの目的は、境界条件をすべて検証することではありません。ユーザビリティ、パフォーマンス、セキュリティのいずれでもありません。どれもみな重要ですが、これらをテストすべきタイミングは、リリースの直前ではありません。
テスターが完全なテストに責任を持つと、責めを負う可能性があります。テスターとして、あなたは完全な戦略を持つことに議論をシフトする必要があります。すなわち、回帰テストによって、顧客のコア体験が設計どおりに確実に機能するようにするのです。
InfoQ: このマニフェストを使うことで、手動回帰テストをどのように改善できるのですか？
Connolly: 手動回帰テストマニフェストは2つのことを提供します。1つは、機能テストと回帰テストの違いを明確に線引きするのを助けることです。両者の違いは、テスターとマネジメントの双方にとって難しいことがよくあります。マニフェストのコア原則はそれぞれ、テストにおいて価値がある2つの要素にフォーカスしています。それらの相対的な価値を比べることで、リリースサイクルにおけるテストへの期待を定義します。一方は望ましくなく、もう一方は望ましいということではありません。それぞれにふさわしい時間と場所があるのです。テスターはその違いについて話せる必要があります。
もう1つは、品質について、またテスターが品質にどのように貢献するかを話し始めるためのフレームワークを提供することです。実は、ソフトウェアを書いている開発者と同程度かそれ以上に、テスターがテストしているソフトウェアに愛情を注いでいる時、テスターはソフトウェアを破壊する悪役になりやすいのです。私たちにはクリエーターとのつながりはありませんが、ただ確実に成功しようと、膨大な時間をかけて取り組んでいます。チームはコーディング標準やプラクティスの議論にかなりの時間をかけますが、コードはテストや品質よりもずっと具体的で測定しやすいものです。ところが、テスターには共通言語がありません。そのため、それぞれのテスターはモチベーションを言葉で表すために、自らの表明手段を見つける必要があります。
私が本当に願っているのは、このマニフェストが、テスターが現在やっていることについて深く考えるきっかけになり、ソフトウェア開発ライフサイクルの各ステージにおいて、彼らとチームにとって品質が何を意味するかを定義することです。そうすれば、自分たちが何を達成しようとしているかを伝えやすくなり、チームに対して問題をより明確に表現し、明らかにすることができます。