書評「テスト担当者を悩ませる、10の難題克服法 ソフトウェアテストの人間関係的アプローチ」

書評「テスト担当者を悩ませる、10の難題克服法 ソフトウェアテストの人間関係的アプローチ」

ウィリアム・E・ペリー (著) , ランドール・W・ライス (著) , 成田 光彰 (翻訳) , 日経BP社

カテゴリ:テスト

概要

テストを成功させるためには、人間関係の対立や、社内の政治に対処するスキルが必要となる。ソフトウェアテストは人が作ったものをテストするため、必然的に人間関係が強く影響する。また、テストを軽視する経営責任者に対しては、その重要性を説明する必要がある。本書では、高品質のテスト・プロセスを実施しながら、政治的な状況に押し流されないための行動計画を提示する。テストの現場において、政治的な問題や人間関係に悩むすべての人に薦める。

本書の使い方

第1章:本書の位置づけを示す
第2章:読者が現在置かれているテスト環境を自己診断することができる
第3章~第12章:テスト現場における10の難題について解決策を説明する。自分が悩んでいる課題、もしくは興味のある課題から読むことができる。
第13章:テストプロセス改善のロードマップを学ぶことができる。

何を学べるか

第1章 テストによってテスト担当者もテストされる
本章では、本書の位置づけと、利用法を示す。本書で取り扱う人間関係の10大難題を紹介し、改善へのロードマップを提示する。

第2章 テストの現状の自己評価
本章では、読者が現在置かれているテスト環境の現状を知るための、自己評価を用意する。人間関係にまつわる20の質問に答えることにより、読者は、自らのテスト環境の弱い部分がどこにあるか、以降の章を読む際に、どの章がその弱みに対応しているのかを知ることができる。

第3章 難題第10位:テストに関するトレーニングを受けること
テストは専門的な分野であり、テスト担当者はテストの要求を満たすためにはトレーニングを受けスキルを身に着ける必要がある。しかし、組織によっては、その必要性の認識が低い場合がある。本章では、テスト担当者をトレーニングする必要性について、経営管理者の認識を引き上げるための、いくつかの方法を紹介する。また、テスト担当者が自らのスキルを向上させるためには、目的と達成目標をどう描けばよいのかについても説明する。

第4章 難題第9位:開発者との良好な関係を築くこと
テストは「相互協力活動」である。成功するためには各グループは自分たちの作業を遂行すると同時に、他のグループと協力する必要がある。そうしなければ、開発者はテスト担当者が遅れを招いていると非難するようになり、テスト担当者は、開発者が欠陥を生み出していると非難するようになる、と著者は説く。本章では、テスト担当者と開発者が敵対的な態度を捨てて、相互に協力しあるチームワークを形成することの重要性と、そのための方法について解説する。

第5章 難題第8位:ツールを使用せずにテストすること
ツールを適切に導入することにより、手作業のテストを効率化することが可能となる。本章では、ツールが適切でないとどのようなことが起こるか、テストツールを購入するにあたって、経営管理者にツールの必要性をどのように説得するのか。購入したテストツールをいかにしてテストプロセスに組み入れ、有効に利用するかなどを取り上げ、解説する。

第6章 難題第7位:経営管理者にテストについて説明すること
経営管理者の中にはテストを優先度の低い活動とみなしている人がいる。システムを開発して導入する際にテストは不可欠であり、その他の開発活動と同じく、経営管理者による指導と方向付けが無ければ、テストの有用性は低いものとなる、と著者は説く。本章では、テストの正確な見方、およびテストに関する経営管理者の認識を高める方法について検討する。

第7章 難題第6位:顧客およびユーザーとコミュニケーションを図ること
「新システムがインストールされる前の方が、効率的に処理できた」という話が良くある。その原因の一つとして、開発側にシステムの顧客およびユーザーについて知識も理解がなく、またシステムの開発・購入のプロセスに、顧客・ユーザーが関与していない、ということが挙げられる。本章では、情報システムの開発において、顧客とユーザーが関与していないことの影響を解説するとともに、もっと関与してもらうための方法について解説する。

第8章 難題第5位:テストの時間を確保すること
どの程度までシステムをテストすればよいか。すべてをテストすることは不可能である。一方、多くの場合開発プロジェクトにおいては、テストスケジュールは過少に見積られることが多く、テスト担当者はそのスケジュールを守るよう、強い圧力をかけられる、と著者は説く。本章ではテストに利用可能な時間を最大限に有効活用する方法について解説する。

第9章 難題第4位:投げ渡されたソフトウェアをテストすること
開発者は、最終的にテスト担当者がすべての欠陥をみつけてくれるだろうと想定して、プロダクトをテスト担当者に、「投げ渡す」ように、送りつけてくることがある。その結果、本来であれば単体テストの段階で開発者によって検出されるべき欠陥が、テスト担当者によって数多く発見される傾向が強くなる。 本章では、そのような行動の根本原因としてコミュニケーションの欠如にあるとし、開発者とテスト担当者の間で良いコミュニケーションを育む方法をいくつか提示する。加えて、開発者の品質意識を高めるためのサポートについても解説する。

第10章 難題第3位:動いている的を射ること
多くのプロジェクトにおいて、システム要求は絶えず変化する可能性がある。テスト担当者は、その変化するシステムを、テストしなければならないという難題に直面する。変化を管理し、プロダクトを十分に長い期間にわたって検証できるようにするにはどうしたらよいか。本章ではそれらをはじめとする問題について考察する。

第11章 難題第2位:どちらに転んでも損をする状況と戦うこと
ソフトウェアに欠陥があるので、リリースできないと報告すると、テスト担当者は前進への障害とみなされる。その一方で、ソフトウェアがリリース可能であると認定した後で、問題が発生すると、テスト担当者は、テストを十分に行っていなかったと非難される、と著者は説く。本章では、このどちらに転んでも損をする状況を検討し、いくつかの解決策を提案する。

第12章 難題第1位:「ノー」と言うこと
テスト担当者が直面する人間関係がらみの最大の難題は、ソフトウェアに問題があることを関係者に伝えることである。本章では、テスト担当者がテスト結果を経営責任者、開発者、ユーザー、および顧客に提示する方法について解説する。次いで、それぞれの提示方法に付随する問題を説明する。最後に、テスト担当者が検出した問題を建設的な態度で提示する方法について解説する。

第13章 テストを改善するための行動計画
本章ではテストプロセスを改善・変更するための手順を6つのステップに分けて解説する。 改善アクティビティの選択、達成目標の設定、計画の立案、支持の調達、改善プロセスの監視とコントロール、参加者への報奨、をそれぞれ解説する。