誰が何をテストすべきか？
誰が何をテストすべきかは、開発組織によって考え方が異なるはずです。
例えば、エンジニアリングで品質を改善する力がある組織であれば、ほとんどのテストが自動化され、マニュアルテストへの依存も少ないはずです。スタートアップであればQA体制が組めないケースも多く、開発者があらゆる機能をテストする体制になりがちでしょう。また大規模な開発組織であれば、職能横断型チーム（企画、開発やリリース業務が完結するチームを指しています）を作るより、開発部、QA部……と役割で組織を分け、それぞれで作業を行ったほうが効率が良いかもしれません。
本連載はアジャイル開発・DevOps時代のテストや品質のあり方を取り上げているため、アジャイル開発を採用している開発組織の役割分担を検討します。
なお、テストにはさまざまな種類があるため、この連載ではシンプルに「単体テスト」、「機能テスト」……と表現しています。また、テスト対象によっては扱うテストも異なるため、ここではWebアプリケーションをテスト対象としています。もし、ご自身の現場と異なる場合は、自分たちの現場に合わせて整理してください。
単体テストは誰がする？
単体テストは、機能単体レベルのテストとします。一番小さいテストであり、開発者の大切な仕事のひとつです。
最小単位のテストは自動化可能であり、自動化によって高速実行も可能になります。高速実行によって、テスト結果というフィードバックを早く受け取ることでき、軌道修正など変化への対応がアジャイルになります。
機能テストは誰がする？
機能テストは、単体テストを組み合わせたテストとします。ここではブラウザを介した1機能のテストを想定しています。画面テストとも言えます。
多くの開発組織では、機能テストをQAエンジニアが担当するケースが多いかもしれません。しかし、「仕様通りの機能を実現するのは開発者の責務」とも考えられるため、開発者が機能テストを担当する企業も増えてきています。筆者も同意です。
開発者が担当することで、「QAエンジニアが機能テストはじめようとしたけど全然動かない……」というように、タスクがブロッカーになってしまうことを防げます。さらに、仕様通りかどうかのテストを終わらせてからQAエンジニアがテストするため、UI/UXや非機能要件といった「仕様の確認」以上のテスト、いわゆる魅力的な品質に、QAエンジニアのコストを集中投資できます。
とはいえ、開発者も人間ですので、機能テストの見落としが発生する場合もあるでしょう。QAエンジニアは品質のプロフェッショナルとして、機能テストのレビューや、より良い機能テストの作り方を開発者に伝授することで、機能テスト品質の底上げにつなげます。
リグレッションテストは誰がする？
リグレッションテストは、アプリケーションを広く浅くテストすることで、アプリケーションが壊れていないことを確認するためのテストとします。繰り返し行われるテストであり、単調で膨大な作業ですので、自動化にぴったりなテストです。
開発者が機能テストを進めている間、QAエンジニアはリグレッションテストの作成に取り組めます。こちらも自動化できるなら自動化しても良いでしょう。
注意したいのは、あらゆるすべての機能をリグレッションテストでテストするのは困難だということです。なぜなら、UIによっては自動化が困難なケースもあり、テスト数が膨大な巨大なシステムでは、自動化は果てしない道のりとなります。もちろん、システムやサービスによっては高い基準の品質が求められるかもしれません。自分たちのシステムやサービスにおいて、最低限必要なリグレッションテストの粒度は何なのかをよく考える必要があります。
受け入れテストは誰がする？
受け入れテストは、仕様どおりに開発された機能が、期待通りの要件を満たしているかを確認するためのテストとします。受け入れテストは、スクラムでいうとスプリントレビューに近い存在です。よって、プロダクトオーナーを中心に、開発チーム全体で成果を確認する必要があります。
仕様通りかどうかは機能テストでチェックしているため、ここでは、スプリントの成果確認とともに、正しいものを作れているかどうかの確認にもなります。
このテストは特殊です。開発チーム全体で成果を確認しながら、さまざまなフィードバックを集めます。集めたフィードバックは、次回以降のスプリントで活用していきます。
テスト自動化の戦略を立てる
それでは、テスト自動化を進めるための「戦略」を具体的に考えていきましょう。戦略は状況に応じて変化するものなので、この連載ではいくつかのパターンを洗い出し、自分たちにあった戦略を選べるように選択肢を提示します。
本当に大切なゴール設定
アジャイル開発におけるインセプションデッキのように、テスト自動化におけるゴール設定はとても大切です。ゴールを明確にしなければうまくいっているかどうかもわかりません。筆者の場合は、テスト自動化を導入したいお客さまとの初回のMTGで、次のような問いを投げかけるようにしています。
ここで明確なゴール設定、課題設定ができない場合は、サービスを売ることはできません。売ってもお互い不幸せになるだけです。また、テスト自動化もおすすめできません。自動化を進めても、将来その効果を実感できないですし、うまくいった／失敗したの確認すらできません。
テスト自動化のタイムライン
ゴールの設定ができたら、そこまでの道のりを考えましょう。筆者の場合は「1か月」「2か月」「3か月」でまずはタイムラインを引きます。
重要なのは継続的にテスト自動化を進めていくことです。テスト自動化も継続的テストのひとつであり、サービス開発と並行で走る長距離マラソンのようなものなので、
- 普段の仕事をしながら
- 自動テストを増やしながら
- 自動テストをメンテナンスしながら
持続可能なスピードで走り続ける必要があります。上記のタイムラインではテスト自動化環境のセットアップからはじまり、自動テストの実装やメンテナンスの開始、CI/CDやSlackへの統合……など、実運用に沿った形で作業を進めていきます。
テスト自動化を推進する人は、関係するメンバーへの勉強会、操作のハンズオンなどを継続的に開催すると良いでしょう。この連載のようなテスト自動化の戦略と勉強会を、テスト自動化前にやっておくと、その後の作業が劇的に進捗するケースもあります。
そして、定期的にレビュー（ふりかえり）を行い、現在位置を確認しながらゴールを調整します。海外だと、四半期ごとのレビュー（QBR: Quarterly Business Review）が一般的のようです。
