より良いアジャイルテストへの道

公開: 2022-03-11

キャップジェミニが作成した年次世界品質レポートによると、調査回答者の42％が、アジャイル開発にテストを適用する際の課題として「専門的なテストの専門知識の欠如」を挙げています。アジャイルの出現により、ソフトウェア開発の反復速度が向上しましたが、場合によっては、品質が犠牲になります。

熾烈な競争により、チームは常に新製品のアップデートを提供するように圧力をかけられていますが、これには、テストへの関心の低下など、独自のコストが伴う場合があります。 Rob Masonのように、さらに進んで、アジャイルがソフトウェアテストを殺していると主張する人もいます。最近、Facebookは、品質を犠牲にする誘惑を解決するために、モットーを「速く動き、物事を壊す」から「安定したインフラストラクチャで速く動く」に変更しました。

では、どうすればテストをアジャイルソフトウェア開発の新しい世界にうまく統合できるでしょうか。アジャイルテスト。

従来のテストは非常に面倒で、多くのドキュメントに依存しています。アジャイルテストは、アジャイルソフトウェア開発の原則を模倣するテストプロセスへのアプローチです。

テストははるかに頻繁に行われますが、
テストは、ドキュメントに依存するのではなく、チームメンバーのコラボレーションに依存します。
一部のテストアクティビティは、テスターだけでなく開発者によっても実行されます。

過去7年間で、私は多くのチームをアジャイルテストに移行し、テスターと協力して、プロセスが新しい方法論に適合するように支援してきました。この記事では、より良いアジャイルテストへの道のりで学んだ最も影響力のあるヒントのいくつかを共有します。アジャイルプラクティス内で速度と品質の間に摩擦があるのは当然ですが、この記事では、敏捷性を損なうことなくテスト品質を向上させるために使用できるいくつかの手法について説明します。ここで概説する提案のほとんどはチームの関与を必要とするため、開発者とテスターの両方が計画に参加することは有益です。

リリーステストサイクルプロセスを形式化する

テストに関する問題の1つは、リリーステストサイクルがないこと、リリーススケジュールがないこと、または不規則なテスト要求があることです。オンデマンドのテスト要求は、特にテスターが複数のプロジェクトを処理している場合、QAプロセスを困難にします。

多くのチームは、各スプリントの後に1つのビルドしか実行しません。これは、アジャイルプロジェクトには理想的ではありません。週に1回のリリースに移行することは有益であり、週に複数のビルドに徐々に移行します。理想的には、開発ビルドとテストは毎日行う必要があります。つまり、開発者はコードをリポジトリに毎日プッシュし、ビルドは特定の時間に実行されるようにスケジュールされます。これをさらに一歩進めるために、開発者は新しいコードをオンデマンドでデプロイできるようになります。これを実装するために、チームは継続的インテグレーションおよび継続的展開（CI / CD）プロセスを採用できます。 CI / CDは、メジャーリリースの日にビルドが失敗する可能性を制限します。

CI / CDとテスト自動化を組み合わせると、重大なバグを早期に検出できるため、開発者は、スケジュールされたクライアントのリリース前に重大なバグを修正するための十分な時間を確保できます。アジャイルの原則の1つは、動作するソフトウェアが進歩の主要な尺度であると述べています。このコンテキストでは、正式なリリースサイクルにより、テストプロセスがより機敏になります。

導入ツールでテスターに力を与える

テストの一般的な摩擦点の1つは、コードをステージング環境にデプロイすることです。このプロセスは、チームが影響を与えることができない可能性のある技術インフラストラクチャに依存します。ただし、ある程度の柔軟性がある場合は、テスターやプロジェクトマネージャーなどの技術者以外の人向けにツールを作成して、更新されたコードベースをデプロイして自分でテストできるようにすることができます。

たとえば、私のチームの1つでは、バージョン管理にGitを使用し、通信にSlackを使用しました。開発者は、Git、デプロイメントスクリプト、および1つの仮想マシンにアクセスできるSlackbotを作成しました。テスターは、GitHubまたはJiraから取得したブランチ名でボットにpingを実行し、ステージング環境にデプロイすることができました。

この設定により、開発者は多くの時間を解放すると同時に、テスターが開発者にテスト用のブランチをデプロイするように依頼する必要がある場合に、通信の無駄と絶え間ない中断を減らすことができました。

TDDとATDDを試してください

テスト駆動開発（TDD）は、品質を重視するソフトウェア開発プロセスの一種です。従来、開発者はコードを記述し、誰かがそれをテストしてバグが見つかったかどうかを報告していました。 TDDでは、開発者は、ユーザーストーリーを完成させるコードを作成する前に、最初に単体テストを作成します。開発者がテストに合格するための最小限のコードを記述するまで、テストは最初は失敗します。その後、チームの品質要件を満たすようにコードがリファクタリングされます。

受け入れテスト駆動開発（ATDD）は、TDDと同様のロジックに従いますが、名前が示すように、受け入れテストに重点を置いています。この場合、受け入れテストは、開発者、テスター、およびリクエスター（クライアント、製品所有者、ビジネスアナリストなど）と協力して開発前に作成されます。これらのテストは、コードを作成する前に、チームの全員がクライアントの要件を理解するのに役立ちます。

TDDやATDDなどの手法は、テスト手順を開発ライフサイクルの初期段階に移行することで、テストをより機敏にします。早い段階でテストシナリオを作成する場合、開発者は要件を十分に理解する必要があります。これにより、不要なコードの作成が最小限に抑えられ、開発サイクルの開始時の製品の不確実性も解決されます。製品の質問や競合が後の段階でのみ明らかになると、開発時間とコストが増加します。

タスクカードの動きを追跡して非効率性を発見する

私のチームの1つには、特に小さな機能を備えた非常に高速な開発者がいました。彼はコードレビュー中に多くのコメントを得るでしょうが、私たちのスクラムマスターと私は経験不足としてそれを書き留めました。しかし、彼がより複雑な機能のコーディングを開始すると、問題がより明らかになりました。彼は、完全に準備が整う前に、コードをテストに渡すパターンを開発していました。このパターンは通常、開発プロセスに透明性がない場合に発生します。たとえば、さまざまな人々が特定のタスクにどれだけの時間を費やすかが明確ではありません。

時々、開発者は機能をできるだけ早く出し、品質をテスターに「アウトソーシング」しようと急いで作業をします。このような設定では、ボトルネックがスプリントのさらに下に移動するだけです。品質保証（QA）は、チームが持つ最も重要なセーフティネットですが、QAの存在により、開発者は品質の考慮を放棄することができます。

最新のプロジェクト管理ツールの多くには、スクラムまたはかんばんボード上のタスクカードの動きを追跡する機能があります。私たちの場合、Jiraを使用して、問題の開発者のタスクで何が起こったかを分析し、チームの他の開発者と比較しました。私たちはそれを発見しました：

彼のタスクは、私たちのボードのテスト列でほぼ2倍の時間を費やしました。
彼のタスクは、2回目または3回目の修正のためにQAから返されることがはるかに多いでしょう。

そのため、テスターは自分のタスクにより多くの時間を費やす必要があることは別として、それを複数回行う必要もありました。私たちの不透明なプロセスにより、開発者は本当に速いように見えました。ただし、テスト時間を考慮すると、これは誤りであることがわかりました。ユーザーストーリーを前後に移動することは、明らかに無駄のないアプローチではありません。

これを解決するために、私たちはこの開発者と正直に話し合うことから始めました。私たちの場合、彼は自分の作業パターンがどれほど有害であるかを単に認識していませんでした。それは、品質要件が低く、テスタープールが大きい前の会社で働くことに慣れた方法でした。私たちの会話の後、そして私たちのスクラムマスターとのいくつかのペアプログラミングセッションの助けを借りて、彼は徐々に開発へのより高品質のアプローチに移行しました。彼の高速コーディング能力により、彼は依然として高性能でしたが、QAプロセスの「無駄」が取り除かれたため、テストプロセス全体がはるかに機敏になりました。

QAチームスキルセットにテスト自動化を追加する

非アジャイルプロジェクトでのテストには、テスト分析、テスト設計、テスト実行などのアクティビティが含まれます。これらのアクティビティは順次実行され、広範なドキュメントが必要です。企業がアジャイルに移行する場合、多くの場合、移行は主に開発者に焦点を当て、テスターにはあまり焦点を当てません。彼らは広範なドキュメント（従来のテストの柱）の作成をやめますが、手動テストを実行し続けます。ただし、手動テストは低速であり、通常、アジャイルの高速フィードバックループに対処できません。

テスト自動化は、この問題に対する一般的な解決策です。自動テストにより、開発者やテスターが他のタスクに集中している間にテストコードをバックグラウンドで実行できるため、新機能や小さな機能のテストがはるかに簡単になります。さらに、テストは自動的に実行されるため、手動のテスト作業と比較して、テストの対象範囲がはるかに大きくなる可能性があります。

自動テストは、テスト対象のコードベースに類似したソフトウェアコードの一部です。これは、自動テストを作成する人々が成功するには技術的なスキルが必要になることを意味します。さまざまなチーム間で自動テストを実装する方法には、さまざまなバリエーションがあります。開発者自身がテスターの役割を引き受け、すべての新機能でテストコードベースを増やすことがあります。他のチームでは、手動テスターがテスト自動化ツールの使用方法を学ぶか、経験豊富な技術テスターを雇ってテストプロセスを自動化します。チームがどちらの道をたどっても、自動化ははるかに機敏なテストにつながります。

テストの優先順位を管理する

非アジャイルソフトウェア開発では、テスターは通常、プロジェクトごとに割り当てられます。ただし、アジャイルとスクラムの出現により、同じQA専門家が複数のプロジェクトにまたがって業務を行うことが一般的になりました。この重複する責任により、スケジュールに矛盾が生じ、テスターが1つのチームのリリーステストを別のチームのスプリント計画セッションよりも優先する場合、テスターは重要な式典を見逃す可能性があります。

テスターが複数のプロジェクトに取り組むことがある理由は明らかです。フルタイムの役割を果たすためのテストのタスクが一定の流れになることはめったにありません。したがって、チームに専用のテストリソースを割り当てるように利害関係者を説得するのは難しいかもしれません。ただし、テストアクティビティに従事していないときに、テスターがダウンタイムを埋めるために実行できる合理的なタスクがいくつかあります。

クライアントサポート

考えられる設定の1つは、テスターにスプリントのダウンタイムを費やしてクライアントサポートチームを支援することです。テスターは、クライアントが抱える問題に常に直面することで、ユーザーエクスペリエンスとその改善方法をよりよく理解できます。彼らは計画セッション中に議論に貢献することができます。さらに、クライアントが実際にソフトウェアをどのように使用しているかをよく理解しているため、テスト活動中はより注意深くなります。

製品管理

テスターの優先順位を管理するためのもう1つの手法は、基本的に、手動テストを実行するジュニア製品マネージャーにすることです。ジュニアプロダクトマネージャーはユーザーストーリーの要件の作成に多くの時間を費やし、したがってほとんどのタスクについての深い知識を持っているため、これはテスターの非番時間を埋めるための実行可能なソリューションでもあります。

テスト自動化

以前に説明したように、手動テストは自動化よりも劣ることがよくあります。このコンテキストでは、自動化の推進と、テスターがチームに完全に注意を向け、Seleniumなどのテスト自動化ツールを使用するための学習時間を活用することと組み合わせることができます。

概要：高品質のアジャイルテスト

テストをより機敏にすることは、多くのソフトウェア開発チームが現在直面している必然性です。ただし、「できるだけ早くテストする」という考え方を採用しても、品質が損なわれることはありません。アジャイルへの移行にはアジャイルテストへの移行が含まれることが不可欠であり、これを実現する方法はいくつかあります。

リリーステストサイクルプロセスを形式化します。
テスターにデプロイメントツールを提供します。
テスト駆動開発と受け入れテスト駆動開発を試してみてください。
タスクカードの動きを追跡して、非効率性を発見します。
QAチームのスキルセットにテスト自動化を追加します。
テスターの優先順位を管理します。

毎年、ソフトウェアは改善され、ユーザーの期待は高まっています。さらに、クライアントがGoogle、Apple、Facebookなどのトップソフトウェアブランドの高品質な製品に慣れるにつれて、これらの期待は他のソフトウェア製品にも移ります。したがって、今後数年間で品質の重視がさらに重要になる可能性があります。これらのテストと全体的な開発プロセスの改善により、テストの俊敏性が高まり、高レベルの製品品質が保証されます。