この記事はRachel Kiblerによるゲスト投稿です。
最初に最重要事項を。チームがDevOpsを採用すると、テストには以前よりずっと多くのコミュニケーションとコラボレーションが必要になります。メンバーのスキルが重要であり、質問することが重要です。
DevOps環境でのテストに役立つかもしれないプラクティスはほかにもあり、DevOpsで成功するには、そういったプラクティスの多くを取り入れるとよいでしょう。以下の簡単なチェックリストを使って、すでに採用済みのDevOpsテストプラクティスを確認するとともに、他にどのような改善が可能なのかを知りましょう。
1.フレームワークを設定する
a. バグの定義とバグに対するポリシーを決めます。運用環境で見つかった、期待から外れるものすべてをバグとしますか？バグはすぐに修正されますか、それとも優先順位が付けられますか？ただちに対処が必要なバグをどうやって決定しますか？
b. ロールバックプロセスが容易であることを確認します。(以上、説明不要)。
2.チーム全体をストーリーの作成に参加させる
a. ストーリーをリリース可能な(そしてテスト可能な)最小の塊に分割します。フロントエンドにつながっていないAPI 呼び出しは粒度が高く、UIが完成する前に個別にテストできます。
b. 受け入れ条件を慎重にレビューします。修正対象の問題が本当に理解されていることを確認します。Elisabeth Hendricksonが言うように、ソフトウェアが「常に」～する、「決して」～しない、などの絶対的な表現に注意します。これらの表現は潜在的な問題を示唆する可能性があります。全員が同じ前提に立ち、アプローチを理解していることを確認します。
c. リスクについて質問します。 — ユーザー、セキュリティ、ビジネス、考え付くかぎりすべてのものに対するリスクについて質問します。
d. コード変更に伴って対処すべきことをはっきりさせます。チャーターやその他のテスト ノートを作成します。それに対してフィードバックを求めます。変更がどのようにテストされるかを開発者やプロダクトオーナーに理解してもらうと、より良いコードにつながる可能性があります。「より良い」とは、より明確でテストしやすいコードを意味します。また、利用者やメンテナンスする人にとってスムーズなプロセスも意味します。
3.コードが作成されている間にできるいくつかのことをする
a. 開発者とペアを組みます。コードと変更の影響をより深く理解できれば、結果として、より適切にテストできます。また、ペア作業中に問題を提起し、テストでどのような点に着目するかをより良く開発者に理解してもらうこともできます。
b. テスト環境をセットアップします。あるいは、テスト環境が利用可能になったらどのようにアクセスするかを確認します。シナリオをセットアップし、テストに必要になるデータがあれば準備し、ユーザーを適切な状態にします。
c. 必要に応じて自動テストの作成を開始します。
4.コードの準備ができたら、あなたがいつもやっていると皆が考えていることをする
a. コードの変更を確認します。単体テスト、統合テスト、UIテストなど、開発者が作成することになっている自動テストがあれば、作成されているかどうかを確認します。テストが作成されていなければ、理由を尋ねます。
b. セットアップしたシナリオをテストします。それまでに収集したすべての注意事項とそれまでに行ったすべての話し合いを活用します。
c. すべてのリスク領域をカバーしていることを確認します。開発中に物事が変わる可能性があるため、開発者と会話して変更の影響を受けるコード領域を確認します。
d. 適用可能なすべての自動テストを実行します。通常、優先度の高いテストまたはスモークテストから実行を開始します。自動テストを使用して、手動でより深く堀り下げる必要がありそうな領域を認識します。
e. (まだ分からない場合)見つかったバグをどう報告してほしいか、開発チームに尋ねてください。(1つずつレポートする? すべてをまとめてレポートする? Jiraの課題で? サマリーのメールで?)。作業の切り替えをどのように感じるかによって、開発者は、先にできるだけテストを進めてから問題を知らせて欲しいと考えている場合もあれば、テストの進捗に従って、問題が見つかったときに都度修正したいと考えている場合もあるでしょう。
f. あなたが作成した自動テストを追加します。既存とは別個のブランチまたは同じブランチに追加します。開発者が従っているのと同様のプロセスに従うようにします。
5.コードがリリースされても、まだ完了ではない
a. 運用環境をチェックして、変更が正しく反映されていることを確認します。パイプラインがおかしい場合もありますし、何かが止まったり正常にリリースされないこともあります。パイプラインが安定していれば、そういった事態にあまり遭遇しないかもしれませんが、チェックしておく価値はあります。テストをすべて再現する必要はありません。簡単なチェックだけで十分です。
b. エラーログを見て、変更によってエラーのスパイクが起きていないことを確認するようにします。ログを見る時間は、どのくらいの頻度でエラーが起こる可能性があるかによります。ログイン処理への変更をリリースした場合は、おそらく何時間も確認する必要はないでしょう。ユーザーがあまり遭遇しないフローへの変更をリリースした場合は、クエリーをセットして後でまた確認します。
これで終わりです。DevOps は楽しくやりがいがあります。ここで紹介した確かなプラクティスを実践することで、DevOps環境でテストを成功させるための準備が整えられます。DevOps ブログ記事でさらに詳細を確認してください。
Rachel Kiblerは1-800 Contactsで働くテスターです。Twitterアカウントは@racheljoi、Webサイトはracheljoi.comです。
（この記事は、開発元Gurock社の Blog 「5 Steps to Successful Testing in DevOps」2020年10月5日の翻訳記事です。）