令和の時代に入り、アジャイル開発という手法がソフトウェア開発の主流となりつつあります。開発スタイルはウォーターフォール型とアジャイル型では考え方が異なるというのは周知の事実ですが、アウトソーシング(業務委託)のQAエンジニアはいかにその流れに対応するべきか、を筆者なりに解説したいと思います。
※ここで「アジャイル開発」はスクラムでの開発をイメージしています。また、QA(クオリティアシュアランス)はテストエンジニア、QAエンジニアの総称とします。
アジャイル型組織のQAの役割とは？チーム一丸の理由
結論としては、アジャイルではソフトウェアのリスクのコントロール全般がQAの役割です。対してウォーターフォールでは各工程で段階的に決められた基準に沿ってを品質を担保することが主な役割でした。ここではウォーターフォール型とアジャイル型におけるQAの役割の違いを身近なものに例えて論じていきたいと思います。
ウォーターフォール型ははっきりと各フェーズが分かれています。要件定義、設計、コーディング、テスト工程が明確に分かれて存在し、ソフトウェアの品質を段階的に積み上げていくイメージです。QAの参画目的としてテスト工程の段階で「テストをしてリリース前の品質を担保する」ことが役割でした。
対してアジャイル型は、ソフトウェアを適切なビジネススピード、タイミングで限られた期間およびリソースの中でリリースすることを目的とし、設計からリリースまでをチーム一丸となって役割を全うするものです。ウォーターフォール開発では、比較的規模が大きいプロジェクトで適用され、それぞれが独立（PM、開発、QA）して個々の役割を果たしていました。
一方でアジャイル開発ではチームを細分化し、個々のチームがプロジェクトの状況にあわせて柔軟に対応できる体制となります。チームを細分化することで、ウォーターフォールのように個々の役割の壁を越えて、プロジェクト成功の為に、開発者とQAが密にコミュニケーションを取ることでチーム一丸となれます。
バルテスのサービスがわかる
テストアウトソーシング基本ガイドブック
テスト実行しかやってくれないテストのアウトソーシングがダメな理由
テストを最後の工程でしか行わないと何が問題かというと、何かあったときに多大なるコストがかかる点です。テスト/改修など製品開発のピークを後半に作ることをシフトライト(shift right)と言います逆に、開発の段階からテスト、検証を少しずつすることをシフトレフト(shift left)と言います。アジャイルで目指すべきはシフトレフトですが、その理由をここで論じていきたいと思います。
テストを最後にまとめて行った場合、下記のリスクがあると言われています。。
【テストを最後にまとめて行った場合のリスク】
- リリース日までに全部のテストが終わらず、深刻なバグが残ったままリリースされる可能性がある
- 設計段階で発見すべきだったバグを見つけてしまい(仕様の考慮もれ等)、修正に多大な時間と費用がかかる
- そもそもテスト実行が止まってしまうほどの大きなバグがあり、開発は急ぎで対応、テスターには待ち時間が発生する
普通に考えると壮大なリスクがあるのですが、現代でもテストを最後にまとめて行うスタイルをよく目にします。しかも、サイトによっては、最後にテストをまとめてやった方が品質は良くなる、と書いてあるものまであるぐらいです。テストは最後に行うもの、という固定観念はなくしましょう。今こそマスターヨーダの教えである「You must unlearn what you have learned.」が大事ではないでしょうか。塾講師でアルバイトをしていた経験を例に上げたいと思います。中三の生徒が受験を控えて勉強していますが、二次関数のグラフが書けません。
よくよく話を聞いてみるとそもそも中一の内容である比例のグラフが書けないのです。よって比例、一次関数、二次関数のすべてを再度勉強して理解しないといけないことがわかり、多大なる勉強時間と費用がかかってしまったという例です。この事例はソフトウェア開発にも当てはまるのではないでしょうか？設計段階で仕様の不備があったまま開発を進めてしまい、テストをしたらバグとして指摘され、設計段階に戻って修正する必要が出てくるのです。
受験を控えた生徒に対しては「なんで中一の内容を理解してなかったんだよ」と指摘できる人はたくさんいるかもしれません。しかしテスト中に設計段階の仕様バグを見つけても「なんで設計段階でそんなミステイクを犯してるんだよ」と指摘できる人はどのくらいいるでしょうか。指摘するだけ時間の無駄だし、そもそも指摘できるような立場ではないし、それよりも早く修正してしまおう、と考える人が多い気がします。
イテレーション内のフィーチャー検証や、リリース前のプロダクト品質テストをサポート
アジャイル開発テスト支援サービス
アジャイル型組織でQAがやるべきこと
「シフトレフト」、アジャイル型組織でやるべきことは、これに尽きます。
プロジェクトのキックオフからチームの一員として、リスクを早い段階からコントロールするのがアジャイル型開発でQAがやるべきことなのです。とはいえ、具体的には何を意識してシフトがレフトなQA活動を行えばいいのでしょうか？ここで業務受託者(アウトソーシング)という立場で意識しているQA活動をご紹介したいと思います。
【QA活動のポイント】
- チームのメンバー間で信頼関係を構築する
- 開発者に議論してもらう
- 定期的に振り返りを行い、よかったことや改善点を全員で考える
1つ目の信頼関係についてです。信頼関係の構築は、何よりも最初にすべきことです。理由は、指摘を行う業務委託のQAという立場上、信頼なくしていい指摘はできないからです。「郷に入っては郷に従え」という言葉をまず実行しましょう。理由は、それができていないと、仮に正しい指摘をしたとしても、伝わるまでに時間がかかる可能性があるからです。チームメンバーの名前を覚えることは当たり前のマナーです。さらにやるべきことは、プロジェクトが立ち上がった背景、発注元の社長の経歴や会社を立ち上げた理由などを理解し、リスペクトすれば信頼関係の構築の近道なのです。
2つ目の議論についてです。時折、質問や指摘をした際に、開発者とマネジメント層で議論が始まることがあります。まだエンジニアとして駆け出しのころ、筆者は「余計なことを言ってしまったか・・。」と反省している時期もありました。ですが、逆にこういう状態になると健全な状態であると言えます。何が言いたいかというと、開発をしながらも議論が活発なプロジェクトは、テストを行ってもバグがほとんど出ないのです。理由はチームであらゆる可能性を考慮できているからです。
開発者に議論をしてもらえるような指摘や質問をする、というのがアジャイル型QAの大事な仕事と言えます。テスト観点のレビュー依頼も早ければ早い方がいいでしょう。プロジェクトの初めの方でじっくり議論してもらうことこそが、シフトレフトに他ならないのです。3つ目の振り返りに関してです。ウォーターフォール型開発だと行わないことの一つに、振り返り(スプリントレビュー)があります。この振り返りはチーム全員で行い、発言することが大事です。
アウトソーシングという立場上、あまり発言しない人も見かけますが、「ここではあれはよかった(感謝)」、「これはちょっと改善してほしい(依頼)」といった意見を共有して、次のスプリントに向けた前向きな議論を行いましょう。開発側からQAに対しての意見もあるでしょう。また、なぜあのタイミングであの判断をしたのかみたいに気になっていることもあるのでしょうし、気になった点を改善して、よりよいプロジェクト運営にしたいものです。我慢をため込むことはアジャイル開発において美徳ではないのです。
まとめ
ソフトウェアテストのプロフェッショナルはテストを行ってバグを出すだけでOKな時代は終わりました。アジャイル開発という手法が日本でも主流になりつつある今、アウトソーシングのQAとして最高の品質保証を行うために、このような点に気を付けて柔軟に対応していきたいものです。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。
