DevOps テストカルチャー: SDLC全体を通じて品質を作りこむ際に避けるべき５つの誤り

この記事はCameron Lairdによるゲスト投稿です

企業は高い品質を提供したいと望むいっぽうで、開発スケジュールや市場の需要、さらには新しい機能をできるだけ早くリリースすることとのバランスをとる必要があります。SDLCにQAを組み込み、テストによって品質を確保することは、常に高い品質を達成するための鍵です。しかし、ソフトウェア開発ライフサイクル（SDLC)でテストが後付けするものと考えられていたり、ボトルネックであると考えられていたりする場合―あるいはSDLCの１つのステップと考えられている場合も―製品を十分にテストできず、QAはリリースの障害とみなされるでしょう。

前回のブログ記事「DevOpsカルチャー: SDLC 全体を通じて品質を作りこむ方法」では、QAをSDLCに組み込む方法を説明しました。今回は、SDLC全体を通じて品質を作りこむために避けるべきよくある間違い５つを説明します。

ポジティブな目標はやる気のもとです。同時に「あやしい臭い」、つまり警戒するべき兆候について、また兆候が出てきたときにどう対処するべきかを知っておくのもよいプラクティスです。以下は、QAチームが犯しがちな５つの誤りと、誤りを避けて安全に進む方法です。

1. 適切に定義された要件またはユーザーストーリーなしにテストする

健全なQA部門に向けての最初の一歩にしておそらく最も重要な一歩が立ち止まることである場合もあります。何もしないこと。休憩をとること。テストを任せられたソフトウェアの要件自体が品質水準に達するまでは、どんなテストも実行しないこと。

慣習的に、ソフトウェアがQAのいわば「玄関先」に置き去りにされ、QAがリバースエンジニアリングや読心術や推測を駆使して顧客にとってのソフトウェアの価値をわかってくれるだろうと期待される状況に陥りがちです。そのようなことは、どんな形でもやめましょう。QAは明示的な文書化された対象を継続的にテストするのだと周知徹底しましょう。創造力はすばらしいものですが、ここは創造力を発揮すべき場面ではありません。QAメンバーがソフトウェアのあるべき動作を解明するために労力を費やさなければならないなら、ソフトウェアの実際の動作を検証する能力が削がれます。わかりにくい、あいまいな要件に順応するのは「よいこと」ではありません。それは別の場所で発揮されるべき力を奪います。

このような状況を変えるのは、製品管理者への異議申し立てになるでしょうか？そうかもしれません。QAの創造力を役立てる最もふさわしい方法は、製品管理者がよい要件を承認できるよう支援することでしょう。おおもとの要件が作成される時点で支援するのが理想的です。そうすれば、要件を理解し、要件がテスト可能でユーザーストーリーと整合性が取れていることを確認できます。製品定義の前に要件を作成すると、要件自体をテストして要件の完成度、明確さ、簡潔さ、一貫性、整合性を検証できます。

理想的な状況ばかりとはかぎりません。過渡期には、仕様定義に関わっていなかった製品のQAを実施するよう求められることもあるかもしれません。それでも、過去はどうであれ、QAが要件に関して推測するのは当然ではないとはっきりさせましょう。ソフトウェアができてから要件が上がってくるのは、より根の深い問題の症状です。

周囲の人たちは、テストフレームワークに関する知識やチームのテスターが見つけたバグの数であなたを評価しているかもしれません。しかし、あなたはエンドユーザーを念頭におき、明確で適切な目標を共同で策定し、それに向かって進むように組織の運営を変化させることによって、自身の価値を何倍にも高めることができます。要件が適切に完成するまで、あるいは少なくとも明確に把握できるようになるまでテストを止めることは大きな成果であり、それを目標とするべきです。

では、要件を受け取った後はどのように要件をテストすればよいのでしょうか？これは大きなテーマであり、今回の入門的な記事の範囲を超えています。さしあたり、経験をベースにしましょう。あなたは「速い」といった主観的ラベルを定量化する必要があることを知っています。またエンドユーザーが誰も予想しないような操作をする「アンハッピーパス」に気を付ける必要があることを知っています。SDLCのできるだけ早い段階で全体を見て評価を伝え、QAを関与させることには価値があると製品チーム全体に認識させましょう。

2. ミーディングを通じたコミュニケーション

QAチームの発見を伝達するのに、開発チームとミーティングを行っていないでしょうか？過去にはミーティングという手段でコミュニケーションをとる理由があったのもたしかですが、2022年現在では、もっとよい手段が必要です。

通常、QA活動による発見をまとめたものが作成されます。それは「パンチリスト」、「バグレポート」、「チケットコレクション」など、さまざまな名称で呼ばれているでしょう。これはQAから開発チームにに最速で知見を伝えるには必須です—ただし伝える方法はミーティングではありません。

あなたの組織でも、おそらくすでにバグまたは課題管理システムを使用しているのではないでしょうか。テスターは、発見があったらできるだけ早く課題管理システムに入力します。週に1回のミーティングを待っていては、コミュニケーションは向上しません。問題を検出したらただちにコミュニケーションを開始しましょう。テスターは、問題を再現できるようにレポートを書く方法を学ぶ必要があります。さらによいのは、テスト結果データとコメントから自動的にバグレポートを生成するテスト管理ツールを使用することです。

再現可能なレポートを書くスキルはテスターに大きな自由を与えます。このスキルを持つことは、いったんバグレポートを入力した後はほうっておいて、次のタスクに全力で集中できるということを意味します。数日後にバグミーティングが開催されるまで何を報告するべきかを覚えておく必要はありません。言うべきことはすべて再現可能なレポートに盛り込まれています。

画像: 欠陥プラグインを使用すると、バグトラッキングツールのAPIまたはWebサービスを使用してTestRailからバグトラッキングツールに直接バグレポートをプッシュできます。また、TestRailから直接バグレポートの情報を検索できるので、レポートされた問題のステータスや変更を追うのが簡単になります。

課題管理システムを通じたコミュニケーションは、開発者にとってもいろいろな利点があります。問題を確認するための認知負荷を1週間のうちに均等に分散し、必要な深さまでバグを調査する機会を与え、特定の項目を担当するのにふさわしい人材を割り当てることを可能にします。

ミーティングは問題を議論し、見通しを共有し、部分的な理解をより広い計画全体にはめこみ、責任の所在を明らかにするには有効です。しかし、ルーティン的な技術的発見の伝達であれば、もっとよい方法があります。

1週間を通じてプロ級のレポートを書き、問題を発見したテスターから問題を解決する開発者に伝え続けることで、「バグレポート」ミーティングの交通渋滞をスムーズな流れに変えます。

3. 製品についての決定を行う

これまでに製品が「出荷できる状態か」と聞かれたことはあるでしょうか？QA部門のリーダーとして、この質問への答えは簡単で常に変わらないはずです。「それは私が決めることではありません」

「ゴー/ノーゴー」は製品管理の管轄です。製品の要件の場合と同じように、あなたは境界やインターフェイスや責任を明らかにすることで組織に貢献するだけです。QAの職責はソフトウェアが定義済の要件をどの程度満たしているかを明らかにすることにあります。何を顧客に届けるかの決定はまったく別の領域の話です。

自主的な選択として製品管理を支援するのは自由です。特定のリリースを顧客がどのように受け止めるかについて、あなたには個人的な意見があるかもしれません。ただし、明確な線引きをしてQAのコアアクティビティが損なわれないよう守りましょう。QAは要件を解析することと、要件を満たしていなければ欠陥をレポートすることに最大限のエネルギーを注げるよう徹底する必要があります。

4. スプリントのたびに大騒動になる

連携の問題に厳しい目を向けましょう。4週間のスプリントで、最初の10日はテスターが暇な状態で、スプリントの最後になってメンバーを集めて徹夜するという状態になっていないでしょうか。これは確実により深刻な問題の症状です。SDLCの仕組みを変え、負荷を分散してテスターがスプリントの全段階で生産的にテストできるようにします。リリースが近くなれば、当然、QAは従来的なバグを探してテストします。しかし、それより前の段階でも、次に挙げるようにできることは数多くあるでしょう。

要件自体をテストする
テスト環境が処理する負荷に合ったハードウェア容量を備えているかを確認する
開発者と共同で継続的テスト(CT)を実現する
前回のQAサイクルの振り返りを行う
その他

一般論としては、あるグループが別のグループを待っている時間があるということは、ワークフローの依存関係と余剰を再検討し、おそらく流れの出入りをスムーズにする余地があることを意味します。課題管理システムは「バグミーティング」の問題を大幅に軽減します。よりよい「データ構造」をかしこく利用すると、ほかにも多くの過剰な連携の問題を解決できます。優れたチケット/インシデント/アイテム管理システムは、たとえば、マネージャーがスペシャリストに口頭で説明を求めなくても関心のあるバグのステータスを確認できるようなしっかりしたレポート機能を備えているはずです。これでスケジュールすべき会話やミーティングが１つ少なくなります。

たとえば次のようなシナリオが考えられます。QAテスターは要件が承認されたらすぐに解読を始めます。実装の準備ができるのを待たず、スプリントの最初の週で定義済みの要件をレビューします。あいまいな点があれば指摘し、特別な環境設定が必要であれば手配します。これにより、最終週に必要になるはずだった作業の一部が1か月前倒しされます。これはQAの負荷を分散し、他の部門との共同作業を改善するのに役立ちます。

5. 何らかのビッグバンがある

ドラマチックなことを警戒しましょう。日々の、あるいはスプリントごとの変更が原則として小さくなるようQAアクティビティを構築しましょう。英雄的努力や特別なイベントに頼るのではなく、サイクルを重ねても維持できるよいルーティンを確立しましょう。「ゆっくり着実に」作業を続けることで競争に勝利しましょう。あなたが後輩に対してメンターとして伝えられる最も価値ある助言の１つは、大きな課題を小さなピースに切り分け、毎日、あるいは毎時間でも着々と進めるということです。

上記のアクションを起こすことをチームメンバーや同僚に伝えましょう。アクションの成功を認めたり、行うべき調整に気づいたりしたときは知らせましょう。QAにはSDLC全体を通じて品質を向上させ、リスクを制御する能力があります。上記をはじめとする正しい戦略を選択すれば、QAは潜在能力に恥じないすばらしい記録を打ち立てることができます。戦略的意図にしたがってアクションを遂行し、対処しましょう。そうすれば、みなが考える以上の成果を達成できるQA部門になるでしょう。

Cameron Lairdは、賞を授けられたソフトウェア開発者で著述家です。Cameronは、Python Software Foundationの投票権を持つほか、いくつかの業界のサポートや標準化組織に参加しています。長くTexas Gulf Coastに住み、農場自動化アプリケーションがお気に入りです。

（この記事は、開発元Gurock社の Blog 「DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC」2022年7月12日の翻訳記事です。）