自動テストを備えた堅固なテストフレームワークは、リリースの信頼性向上を可能にする。フレームワークのクロスチームペアリングにより、リリース当初からの品質確保が可能になった。チームの結束力が向上し、テスト自動化に関する担当者のスキル向上も実現できた。
Leeds Testing AtelierのオーガナイザのひとりでテスタのGwen Diagram氏が、Agile Summit Greece 2018で、大企業において複数チームのテスト自動化ソリューションを開発した経験について講演した。InfoQではこのイベントを、要約や記事、Q&Aで報告している。
Diagram氏は、Leadsの新チームが、ロンドンの複数のチームから、相互関係の非常に不明確な多数のアプリケーションを引き継いだ状況について語った。皆が賛成してくれるようなテストフレームワークを構築するというのは、強制ではなく、皆が従ってくれるようなアイデアでなければならないということだ、とDiagran氏は言う。氏らは Dale Carnegie氏の著書“人を動かす(How To Win Friends and Influence People)”の教えに従って、新たに構成したチーム内に結束を築くことにした。
リリースに自信を持つためには、自動化されたフレームワークが必要だ。プロダクトにはまだ学ぶべきことがまだたくさんあったが、テストはあまり役に立たず、常に失敗するものもいくつかあった、とDiagram氏は言った。ほとんどのプロダクトには十分な自動化レイヤがなかったため、テスタがチーム間を移動できるようにするために、全員で使用できる堅固なフレームワークが必要だった。
氏らはクロスチームのペアリングを使って、リリース当初から品質の高いプロダクトの開発と、チームの結束を実現した。フレームワークはまた、チームのテスタたちのスキルも大きく向上させた、と氏は言う 。チームは今や、Javaで素晴らしいテストを書けるまでになったのだ。
講演を終えた氏に話を聞いた。
InfoQ: 自動テストに関して解決する必要があったのは、どのような問題でしたか?
Gwen Diagram: さまざまなテストフレームワークが、数多く使用されていたことです。ユニットテストがなく、機能テストの数が多いプロダクトもありました。機能テストは、その定義が決まっていないと、運用が非常に面倒になる場合があります。このプロダクトの機能テストはユニットからエンドツーエンドまで幅広い上に、他の開発チームがあまり使わない言語で記述されていました(アプリケーションに関しても、同じような問題の解決に着手したところでした)。
InfoQ: 自動化ソリューションを実現する上で、何が必要でしたか?
Diagram: ペアリングです!たくさんのペアリング。プロダクトはJVMで動作していたので、フレームワークはJavaで開発することになりました。ですが、テスタの中には、Javaを知っているものは1人しかいなかったのです。私のバックグラウンドはC#なので、最初はフレームワークをC#のスタイルで書いていました。大文字を間違えたり、カッコの場所を間違えたり - 最終的には出来上がりましたが、開発者たちはきっと目を真っ赤にしていたはずです!
テスタですから、どんな言語でもコーディングできますが、美しく書けるか?というと、そうではないでしょう。最終的には、開発者たちがテストフレームワークを仕上げてくれたのです。
InfoQ: チームメンバにはどのようにソリューションをプレゼンテーションしましたか? マネージャの同意を得るためには、どのようなことをしたのでしょうか?
Diagram: ソリューションのプレゼンテーションにも面白い話があります。実際のところ、失敗でした!テスタが自分たちの選択した言語とテストランナで概念証明を書いたため、Java、Python、Cucumber、Gaugeが混在していました。残念ながら私は、プレゼンテーションの部分について事前に考えていませんでした。テスタがプレゼンテーションを行った時、一部の人たちに都合のよいものになっていたのです。そこから多くを学びました - フレームワークでの選択は、皆にとって公正なものではなかったのです。
マネージメントに参加してもらうには、彼らの望んでいることを見つけ出して、それに取り組む必要がありました。この作業に、上級マネジメントから直接参加してくれたのは幸運でした。私たちのビジョンが、彼らのものと一致していることを確認できたからです。
InfoQ: テストを自動化したことで、どのようなメリットがありましたか?
Diagram: フレームワークによって、リリースに自信を持つことができたことです。最初の数回は、フレームワークによるメリットを実際に感じたのは、テストが失敗した時でした - まず最初に考えたのは、テストフレームワークに問題があるに違いない、ということだったのです。多くのデバッグを積み重ねた結果、問題がアプリケーションコードにあると分かるようになりましたが、フレームワークを信頼できるようになるまでは時間がかかりました。
自動化スキルを持っていないテスタにオートメーションを学ばせるというのも、フレームワークが堅牢でなければできなかったことです。
InfoQ: フレームワークの実装から、どのようなことを学びましたか?
Diagram: 技術的な選択を自分自身でしない、ということです。ライブラリの一部は私自身が選びましたが、フレームワークが他のアプリケーションに広がるにつれて、別のライブラリが選択されるようになり、最終的にひとつにまとめることが困難になってしまいました。フレームワークを使用する人たちが別のjsonデシリアライズライブラリを選択することや、すべての人たちが既に存在するものに同意するということがいかに難しいか、当時の私には理解できていなかったのです。しかしながら、このような状況下で、どれがよい技術化を争うのは時間の無駄です。最初から皆がバイインする前提で再出発する方法が最善の場合もあるのです。
この記事を評価
- 編集者評
- 編集長アクション