アトラシアン社ブログでは、さまざまな分野のエキスパートによる記事を不定期で掲載しています。今回は弊社 (ゴートゥーグループ) の米国人エンジニア、リッチによる品質管理に関する記事が掲載されましたのでご紹介いたします。なお、原文は こちら でお読みいただけます。
今回のゲスト ブログは、QA コミュニティ内でのテスティング改革に関する関心を高めることを目的とした Atlassian ブログ シリーズの一環です。また、このシリーズの他の記事については、QA 改革タグ付きの記事を参照してください。
今回の記事は Go2Group 
のシニア コンサルタント兼 QA ディレクター、Richard Hale 氏によるものです。Atlassian のプラチナ エクスパートである Go2Group は、Atlassian、HP、Perforce、MuleSoft、IBM、および SalesForce.com の統合ソリューションに関する専門技術を持ち、お客様に世界有数の ALM およびテスティング サービスを提供しています。
私は QA ディレクターとしてこれまで多様なソフトウェア開発環境や文化に関わってきました。ほとんどが優秀で生産的ですが、機能不全 (言葉は悪いかもしれませんが) なものもありました。Penny Wyatt 氏も自身の記事で バグを調査および報告するようにテスターに促すチーム文化の育成 の重要性について触れています。私の経験では、チームやチーム内の一部のサブグループが多すぎる欠陥や特定の種類の欠陥の報告を嫌うことがあります。理由はそれ自体が微妙な問題であったり、プロジェクト内の弱い部分であったり、欠陥の合計数を管理する都合から欠陥数を “抑える” 意図があるためなどです。
これはさまざまな理由で行われます。通常、発見された欠陥の重要性をよく理解していない上層部がプロジェクトの進捗について悪い印象を持たないように、管理認識手法が取られます。私が気づいた限りでは、正規の慣習ではないものの、プロジェクトが進行するにつれて不具合の合計数 (またはその他の数字) をこっそりと改変しようとする動きが見られることがあります。多くの場合、これは自分の上司による状況把握を管理したいと思っている中間管理層の要請で行われます。場合によっては開発者に依頼されることもあります。
今回のブログ記事では私が経験した例をいくつか挙げ、どのように発生したか、およびプロジェクトにとっての真の意義について説明します。これらのケース スタディから多少なりとも学ぶべきものがあれば幸いです。
私が気付いた典型的なシナリオは以下のとおりです。
- たちの悪いバグ
- 要件に含まれない
- 開発者が既に修正中 – 開発チームが “把握済み”
“たちの悪いバグ”
時折、QA チームは不具合と思われる現象の原因となるデータや設定上の問題に遭遇したり、複雑な環境を扱わなければならない場合があります。こうしたケースでは“不具合” はコードや機能自体にあるわけではありませんが、これらの問題が原因でテスト ケースの結果が失敗になることがあります。
たとえば、テスト環境の一環として特定の地域の価格体系を含むデータ サンプルが表示されるはずなのに、適切な価格データがないためにテスト ケースが失敗したとします。環境が正しくセットアップされていることを確認するのはデータ チームまたは開発チームの責務です。テスト ケースの失敗はテストのスケジュールに影響を与え、状況が解決されるまで QA チームの時間が無駄になってしまいます。
こうした状況に遭遇したときに不具合を登録しようとすると、開発チームは「バグではないから不具合として登録しないでくれ」とか「たちの悪いバグだ」と言うかもしれません。しかし、登録して追跡しないと、構成管理 (CM) プロセス、環境およびデータ セットアップ プロセス、アプリケーション展開手法などで問題を修正する機会が失われてしまいます。また、この欠陥により問題の解決に費やす要員や手間を把握でき、問題が再現しないように有用なベンチマークを提示できます。
QA チームはこうした種類の不具合を登録して適切に分類し、関連チームと協力して根本原因を特定するよう努力する必要があります。原因が特定されたら、後で適切な参考事例となるように不具合の説明や属性による特徴付けを変更できます。これによりプロジェクトのキー プロセス (実際にプロジェクトのライフ サイクルをサポートするもの) がソフトウェア開発ライフ サイクル (SDLC) を通して継続的に改善していくことができます。また、こうした問題の解決においてすべてのチームに関連する作業を把握できます。
“要件に含まれない”
これは要件の成果物に対して欠陥を登録すべきケースです。
テスト ケースの失敗では必ずしもありませんが、テスターが欠陥と見られるものを見つけたとします。この欠陥はその場でのスタイル テストで見つかることがあります。その場合、テスターは発見された問題が要件におけるずれかどうかを要件チームに確認する必要があります。通常ここで起こるのは、目的の機能を含めるために要件がすばやく更新され、開発チームとテスト チームがその新しい要件に対応すべく作業を続けるということです。
しかし、この時点でのうまい状況対処方法は、抜け落ちた要件でもって要件の成果物に対して欠陥を登録し、要件チームの要員を割り当てることです。適切な課題タイプを使用することで、テストが当初の要件書に含まれていない必要機能を明らかにするシナリオを追跡できるようになり、発生時に QA チームの作業の一環として捉えることができます。これを行わないと、こうした事案はプロジェクトの進行における隠れたコストとなってしまいます。
“開発者が既に修正中”
QA が要件書に従ってテストを実施しており、テスターが機能の問題を発見したとします。要件と完全に合致しないか、特定の機能を取り巻く要件が明確ではないために、ドキュメントや製品の実際の機能の目算にずれが生じます。テスターはその問題についてかなりの確信はあるものの、念のため開発者に確認します。すると開発者はこのように答えます。「ああそれですね、私が見つけました。既に修正済みで次のビルドに反映されます」と。
結果としてテスターはバグを登録せず、要件書も修正されません。以降、テスト ケースはこの機能について具体的に記述されることはなく、この話題はそこで終わりとなります。
ここでの問題は、QA が欠陥を適切に文書化せずにこうした状況が頻発するようになると、プロジェクト メトリックスと進捗測定に歪みが生じるということです。QA チームは要件チーム、事業チーム、および開発者と頻繁にやり取りをするため、こうした努力の真価はプロセス内で失われ、明らかにされることがなくなります。不具合を登録し、新しい要件を明らかにするに越したことはないのです。今回の場合では、アクティビティに費やした作業量を追跡できるように要件の成果物に対しても不具合を登録する必要があるかもしれません。こうすることで問題が頻発するようになった場合に経営陣が未完了の要件の問題を切り分けられるようになります。
信念を持って不具合を登録
まとめると、不具合の登録は何も悪いことではありません。不具合や問題はさまざまな種類の事案で正しく分類することで、以下の点においてプロジェクト全体にとっての必須事項となります。
- プロセスの改善の促進と、チームや個人の規律を継続的に改善していくこと
- プロジェクトの真のコストを把握し、数値化すること (潜在的な目に見えないコストを特定すること)
- 特定のプロジェクト サポートの問題の根本原因を切り分け、それを解決すること (CM、環境、データなど)
- より有用なプロジェクト メトリックスをサポートすること
作業の数値化、進捗管理、および継続的改善における非常に重要なタスクは、問題を登録するという正しい行為に依存します。
Rich Hale 氏はソフトウェア開発業界に 15 年以上携わっています。同氏は開発者、QA アナリスト、テスト自動化アーキテクト、および SDLC ツール/プロセス スペシャリストとしての経験があります。
