テスト偏重主義からの脱却 ～カギは内部品質と職場環境にあり～

本論文は、第55回IBMユーザー・シンポジウム論文「もう一段上の品質を目指して～テスト偏重主義からの脱却のカギは内部品質にあり～」をもとに提言型論文として、「内部品質」と「職場環境」に着目して見直しを行い再度執筆したものである。

システムの開発を行う会社や部門において、程度の差はあれ、品質管理や品質向上のための取り組みを行っていないところはない。

しかしながら、上流工程が遅れてスケジュールが圧迫され、不十分な設計のまま製造して、テストで品質を上げようとしても手戻りが発生するため、なかなか品質が上がらず、工数ばかりが膨らんでしまうというケースも少なくない。その結果リリース後にも不具合を起こして、多大な損害を発生してしまうプロジェクトも多く見かける。

本論では、SIerでの前職を含めて過去に実施したプロジェクトの経験をもとに、品質向上への取り組みについて提言する。特に「テスト偏重主義」的な品質への取り組みに対して、「内部品質」と「職場環境」に着目し、品質改善のための問題意識と対策について事例を加えて提言する。

まず、本論の背景として、「なぜ品質のよいソフトウェアを期限内に作れないのか？」について、見解を述べる。

次に第3章では、着目する「内部品質」について説明を行い、続く4章では、内部品質の重視が品質向上の成功要因となっていることを過去に経験したいくつかの優良プロジェクトで検証する。

第5章では、「内部品質」（ソフトウェアの構造、設計書やソースコード等の理解性や保守性など）に着目することで、テスト偏重主義から脱却して、「テスト開始時の品質」を向上させるとともに、ビジネスに対するアプリケーションの価値向上を目指す。

第6章では、テストに対する考え方を改め、「内部品質」へのアプローチとあわせて、「テスト開始時の品質」向上に取り組むことで、テストの効率化を図る。

そして最後に内部品質の向上のために、継続的な人材の育成と職場環境の改善の必要性について提言する。なぜならソフトウェアを作るのは人であり、単にプロセスや技法を高めても短期的な効果しか得られないためである。

本論がテスト偏重主義からの脱却を実現し、システム開発における品質向上につながれば幸甚である。

本章では、「なぜ品質のよいソフトウェアを期限内に作れないのか？」について、問題の背景と課題認識を行う。

表1の工程別工数配分比は、私が品質改善の支援で参画したお客様に開発プロジェクトの状況をヒアリングしたものである。表から分かるように、単体テストを製造工程の中に含めたとしても、テストが工数全体の約半分を占めている。

お客様に開発当時の詳しい状況を確認すると、以下のような回答が返ってきた。

このような状況でプロジェクトは進み、テスト工程で手戻り工数が増大して、完了間際まで相当混乱していた。他部門から支援を受けながら何とかサービスインまでこぎ着けたが、サービスイン後も不具合の発生は続き、工数は大幅に超過となった。

また、図1は日経コンピュータ(1998.9.28)の特集記事をもとに作成したグラフである。これからも、前フェーズ以前の欠陥がもたらす手戻りの除去コストが、製造フェーズ以降で爆発的に増えていき、テスト工程以降にしわ寄せが来ていることがわかる。

前述のお客様の事例に限らず、これは多くの開発プロジェクトに見られる傾向である。

もし手戻りを「ゼロ」にできれば、理屈の上では開発コストを半分程度に削減することができるわけだから、そのための取り組みはどこの会社でも行っているはずである。しかしながら、プロジェクトの度に同じようなことが繰り返されるは何故なのであろうか？

品質を確保するには、設計作業を行う中で品質を作り込んでいくことの重要性はよく知られているが、スケジュールなどの関係で設計を十分に詰め切れないまま製造に入って、テストという名のデバッグを行う中で、問題点を明らかにしながら品質の向上を図ろうとするケースがよく見られる。

しかしながら、テストは本来、正しく動作することを確認するための作業であり、品質を証明する唯一の手段である。

図2のクオリティマトリックスは、テスト開始時点の品質と運用開始時点の品質の関係を示したものである。テスト開始時点における品質が良質であれば、リリース時の品質はより良質となり、反対にテスト開始時点における品質が貧弱であれば、リリース時の品質も期待できないということである。多くのプロジェクトは、まさにこの状況に陥っていたといえる。

なぜ多くのプロジェクトで、テスト(テストという名のデバッグ)で品質を確保するような状況に陥ってしまうのか、そこには以下のような要因があると考えられる。

本論では、ここに掲げた問題に対して、「内部品質」に着目することで、テスト偏重主義の品質活動から、以下の3つの観点による品質改善の施策について提言する。

① テスト偏重主義から「内部品質」重視へ
「内部品質」を重視することで、テスト偏重主義から脱却して、「テスト開始時の品質」を向上させる。また、保守性、信頼性および効率性の観点からも「内部品質」に着目し、アプリケーションの価値向上につなげていく。

② テストに対する考え方を改める
テスト(デバッグ)の中で、問題点を明らかにしながら品質の向上を図ろうとする作業のやり方を改め、「内部品質」に着目した設計工程での対応を強化することで、「テスト開始時の品質」を向上させ、手戻りの無駄を省いて、テストの効率化を図る。

③ 職場環境の改善
慢性的な長時間残業は、心身ともに極めて重い負担を強いられるため、モラルの低下を生み出しかねない。品質を作り込むという、高い意識と正しい方針に基づく、充実した、やりがいのある、達成感を味わえる、チームワークの良い楽しい職場を目指す。

品質改善の施策について提言する前に、着目する「内部品質」について説明する。

図3は、ISO9126-1からの引用である。この図は右から見ていくのが理解しやすい。ソフトウェアの品質の影響を直接受けるのは利用者である。その段階での品質を「利用時の品質」と呼び、利用者の必要性に合致するかどうかを表しているものになる。これは利用状況によって異なる。

「利用時の品質」に直接影響するものが「外部品質」である。ソフトウェアが実行されるときの品質のことであり、テストデータを用いたテストの結果（実行時のコードの振る舞い）などが該当する。ほとんどの人が「品質」として認識するのはこれである。

「外部品質」に直接影響するものが「内部品質」である。ソフトウェアの内部的な特徴で、ソースコードのみならず、構造の良し悪しだとか、理解性、補修性などの仕様書の良し悪しも測定対象になる。静的な測定によって得られるものがほとんどで、例えばモジュール性（構造化などの保守性を含む）や追跡可能性（理解のしやすさなど）などが該当する。

「内部品質」に直接影響するものが「プロセス品質」である。プロセスとは設計／開発のやり方や手順のことである。この「やり方」の品質が結果的にすべての品質に影響を及ぼすということになる。

もう少し「内部品質」について掘り下げてみると、内部品質は構造的品質と捉える事もできる。構造的品質とは、保守性や信頼性に影響するソフトウェア属性のことであり、図4に示すようなものがある。

一般的に、ほとんどの欠陥の検出と関連する品質活動は外部的、あるいは機能的品質を中心に組み込まれており、内部品質（構造的品質）より外部品質（機能的品質）を偏重する傾向が強く見られる。その結果として「テスト偏重主義」の品質活動を助長させる傾向となっている。

『ソフトウェア品質の経済的側面』では、「内部品質(構造的品質)問題の発見と是正を最優先することにより、ビジネスに対するアプリケーションの価値を高めることができる。」と言っており、内部品質も外部品質と同様に重視すべきである。

なぜなら、ビジネスソフトウェアはリリースして終わりではなく、ビジネス環境の変化スピードに追随できるよう、柔軟に変更を行えることが求められる。内部品質の低下は、技術的負債となり、ビジネス変化に対する俊敏性や生産性の低下、将来的には属人化や業務の硬直化といったビジネスリスクを抱えることになりかねない。

内部品質には「テスト偏重主義」から脱却して「テスト開始時の品質」を向上させるだけでなく、アプリケーションの価値も向上させる力も秘めている。

内部品質の重視がプロジェクト（アプリケーション自体を含む）の品質向上の成功要因となっていることを探るため、前職を含めて過去に経験したいくつかの優良プロジェクトを検証する。

某法人の組織は、本部－地方本部－地方支部 ・・・ 事務所－基地といった階層構造を持ち、下の階層から積み上げて行くルールを持つが、地方支部以下は全ての階層が揃っているわけではない。公益会計と収益会計の2つの財布があり、勘定科目によっては複雑な配賦のルールも存在する。
また、事務所や基地などの拠点の統廃合や勘定科目や配賦率など様々な運用上のルール変更は頻繁に発生する可能性があり、それを考慮した設計を行う必要があった。

このシステムでは、構造化設計の技法を用いて機能の分割および各機能間の疎結合を徹底化した。また、全てのルールをデシジョンテーブルに格納し、そのルールはパラメータによって外部から変更できる方式とした。全ての機能はこのデシジョンテーブルを参照して制御を行う方式として運用性や保守性を重視して設計した。しかも正しく計算されているかのロジック検証用に集計前後のメモリ上のデータテーブルをスナップショットするデバック機能も組み込んだ。

その結果、メンバーの仕様理解度も上がり、機能分割による並行作業による生産性と相まって、製造・単体テストまでの手戻りもほとんどなく、不具合の発生数も少なかった。
さらに結合試験以降のテスト工程では、機能が階層化され理解しやすいことやデシジョンテーブルの効果が発揮され、試験項目の抽出を含む試験仕様の品質に単体テストの品質が加味されて、非常に良い成績で効率的にテスト工程を終えることができた。

運用工程に入ってからも、毎期のように発生する拠点の統廃合や勘定科目、配賦ルール等の様々な変更に際しては、アプリケーションの変更を行うことなく効率的に運用してきた。

このシステムではオープン系のERPに切り替わるまでの約16年間に、1度だけあった専用帳票から日本語プリンターへの移行によるアプリケーション改修を行った際でも、変更対象機能が明確に判断できたので苦労なく変更を完了した。

本例は、システム（アプリケーション）の内部構造の良し悪しが、開発の生産性（テストの容易性を含む）や品質に影響を与えるとともに、保守性の高いアプリケーションがビジネスの変化に対していかに貢献できるかを示す一例であると考える。

このシステムは、いくつかのサブシステムで構成されており、そのうちの運転管理サブシステムにおいて、基本設計時の中間レビューでの品質が悪く、このままの状況では大幅な遅延が発生して、他のサブシステムとの連携が行えずに、システム全体の進捗に影響を及ぼす恐れが出ていた。

そこで、運転管理系のサブシステムの立て直しを図るために、新たなチームリーダを他のプロジェクトから連れてきて、状況確認の引継を行ってチーム体制を一新させることにした。交代したチームリーダは、プロジェクトマネージャと相談の上、以下に示すような方針を立てシステム間の結合試験までに遅れを取り返すことを約束し、お客様から基本設計からやり直す了承を得た。

状況的には非常に厳しかったが、チーム内のコミュニケーションを密にして早期の情報共有を図ることで、モチベーションを保てたこともあり、前述の方針と相まって手戻りの発生を極力抑えて途中から驚異的な生産性を示しながら品質を確保することができた。（図6）

結合試験までには先行していた他のサブシステムに追いついた。サブシステム間の結合試験以降は、他のサブシステムと比較して圧倒的に、不具合の発生件数も少なく、品質の高さを証明するとともに、システムを引っ張っていく立場になった。

本事例は、アプリケーションの構造や標準化といった内部品質を重視し、設計工程から品質を作り込んでいくことが、手戻りを最小に抑え、生産性および品質向上につながることを示しているが、それを実現した要因として、メンバーの高い意識（モチベーション）に支えられた事例でもある。

弊社において、韓国メーカーの内部統制監査の評価支援パッケージを日本国内における総販売代理店として取り扱うことが決定し、我々のチームで日本語バージョンの機能検証や販売開始前の受入検査を担当することになった。

α版の検証において、不具合の発生状況（件数および現象）から、チーム内では製品の品質に対する疑問の声も上がった。このため、β版提供時に検査報告書や品質データの提示を求めようという話も出たが、情報が韓国語であることや契約形態の関係から強制することは難しいこともあり、品質データの提示は断念した。
メーカーにはβ版作成において、十分なテストを行うよう要請するが、β版以降も同様の状況は変わらず、日本語バージョンのリリースの目途が立たず、チームも疲弊してきた。

メーカーが韓国ソフトウェア振興院の「ソフトウェア輸出メントリング (Mentoring)事業 ^※1 」を弊社がパートナーとして支援することで、申請が通ったことをきっかけに製品品質への取り組みを強化してきた。このことは、弊社とメーカーの協力体制を作る上で大きな役割を果すことになった。

メーカーは経営の関与が強まり、プロジェクト関係者の意識が高まって、積極的な品質改善への参加が促され、弊社においては、よりアドバイスや要望ができる環境が整ったことで、品質改善に向けた取り組みを加速できた。

具体的には、韓国メーカーとの連携ということもあって、コミュニケーションに問題を含んでいたので、メーカーと当社間における受入検査の不具合管理のフローを見直した。それまでの文書ベースでの不具合報告から、「判定会議」という会議体を設けて、週一回を目途に通訳を立ててWeb会議を実施し、情報共有と相互認識の上で対応を決定するプロセスにした点に特徴がある。（図7）

これによって、不具合の原因分析が習慣づけられ、同様の不具合の再発防止のため、アプリケーションの構造やプロセスの変更にもつながった。

また、品質に関する考え方の相違も見られたので、韓国に出向いて日本での品質（内部品質を含む）に関する考え方やテストに関する手法についてもレクチャーを行った。さらには、機能に関する要望事項については弊社のQAチームが資料を作成する場合、平文で記述するのではなく図表やデシジョンテーブルを用いて明確に条件が分かるように改善した。このようにして、受入検査の観点を明確に示すことでメーカーのテストも受入検査を意識してもらうようにした。

このように、外部品質だけでなく内部品質も重視した、テストプロセスの改善や教育の甲斐もあって製品の品質改善がみられるようになると、良い製品を出したいというメンバーのモチベーション・アップにつながった。図8に示すようにバージョンアップを重ねるごとに品質が改善されていった。

前述の事例考察からも、ソフトウェアの構造、設計書やソースコード等の理解性や保守性などといった「内部品質」に着目することで、テスト偏重主義から脱却して、「テスト開始時の品質」を向上させる。さらに、ビジネス変化に対するアプリケーションの俊敏性や生産性の低下、将来的には属人化や業務の硬直化といったリスクを抑えて、ビジネスに対するアプリケーションの価値向上を目指すことを提言する。

前述のプロジェクト事例でも示したように、内部品質を向上させるメリットついて整理する。

図9に示す3つのプログラム構造を比較してみると、どの構造が理解しやすく、また管理が行いやすいか一目瞭然である。

よく言えば名人芸のような"凝った"プログラムは、理解しづらく、誤りを発見しにくく、テストを行うのも大変である。また、他人がプログラムの変更や修正を加えることも容易でない。

構造の良し悪しは、理解のしやすさや管理の容易性以外にも、保守性の向上や誤りの気付きやすさ、テストのしやすさといった効果がある。

スケジュールが遅延しだすと、設計書は後回しにして最終的にコードからリバースしたりする。無いよりはましかも知れないが、そのような設計書は本当に役に立つのか疑問である。時間が経つと設計時の経緯や背景などが分からなくて、アプリケーションの変更に時間を要するなどの弊害も起きる。

ドキュメントは検討（設計）した結果であり、ドキュメントを作ることが設計ではない。

文書化（ドキュメント）をキチンと行うことは、以下のような効果がある。

一歩進んでドキュメントを書く際に「テストを考慮して書く」を実践されることを推奨する。「どうやったら動くものができるのか」だけでなく「どう動けば合格なのか」を考えて記述すれば、試験項目抽出だけでなく、合格基準も明確になり試験効率も向上する。具体的には図10のように平文で記述するのではなく図表やデシジョンテーブルを用いて明確に条件が分かるように記述する。

これは、テストだけでなくドキュメントレビューでも理解のしやすさや誤りの発見といった面で効果を示す。

ビジネス環境の変化スピードに追随できるよう、柔軟に変更を行えることが求められるが、よく「エンタープライズシステムの『大規模で複雑』な要件と、ビジネスが求める『変更容易性』という要件は相いれない」と否定的なことを言われるが、本当にそうだろうか。


設計時点で変更が入りやすい箇所を特定し、そこを変更が受け入れやすいアーキテクチャにしておくことで、対応可能であると考えた。以下に示す項目などは、実際に採用してきた一例である。

保守性の向上はテストの容易性にも直結するので、十分な検討が必要である。

ここまで述べてきたように、「テスト偏重主義からの脱却」には、設計作業を行う中で品質を作り込み、テスト開始時の品質を向上させることが重要である。第3章の過去の優良プロジェクトにおいても「内部品質」に着目して設計工程に力点を置くことで、「テスト開始時の品質」の向上に成功して、テスト時の手戻りを大幅に減らしてテストの効率化を実現するとともにアプリケーションの品質も確保できている。

この好循環の効果を図に表したものが図11である。この好循環を続けることで、設計工程の十分な工数確保が可能となり、メンバーの開発作業や品質に対するモチベーションを維持できる。この効果については、次章以降に詳しく説明する。

「テスト偏重主義からの脱却」を図るためにも、前述した「内部品質」へのアプローチとあわせて、「テスト開始時の品質」向上に取り組むことで、開発工数の約半分を占めるとも言われるテストの効率化を図ることを考える。

2章の図2で示したクオリティマトリックスのように、「テスト開始時の品質」が貧弱であれば、リリース時の品質も期待できない。本来、テストはデバックではないはずであるが、なぜこのような風潮があるのだろうか。これは以下のMyersの言葉が勘違いして伝わっていると思われる。

ソフトウェアのテストの目的はバグを見つけることであり、バグの見つからないテストは失敗である

確かに、人が作るものであるから、誤りが組み込まれる可能性は高いかもしれないが、バグを見つける（すなわちデバッグ）ばかりがテストではないということで、以下のようにも論じられている。

ソフトウェアの確からしさの確信を増すことである ^※2
Myersの呪縛からの解放が必要である ^※3

テストは、ソフトウェアの誤りを発見するという観点だけでなく、ソフトウェアの品質について確認・評価し、品質を保証するという役割を持つ。

一方で、テストは「品質を証明する」唯一の手段であるため、どんなに品質がよいと思われても、テストを省略することはできない。

品質向上のための作業は、設計や実装と合わせて「作り込む」ものであり、開発者が行うべき役割であると考えることが必要である。前述したように、「テスト開始時の品質」とテスト自体の効率化がカギであると考え、「内部品質」に着目して設計に取り組むべきである。

開発プロジェクトには納期があり、テストに使える時間には限りがある。できるだけテストに割く時間を短くし、設計に時間をかけて品質向上を図りたいと思うのは誰しも同じである。そのためには、テストでの不具合発見による手戻りを少なくするだけでなく、テストの作業自体も効率化することが「テスト工数の削減」には欠かせない。これに対する1つの解は、前章で示したように「内部品質」への取り組みである。

テストの効率化への具体策の1つとして、前述したドキュメントを書く際に「テストを考慮して書く」がある。これによってテスト条件などの曖昧さを排除でき、テストの効率化に寄与できる。

その一方で、テストの効率化を支えるのが「ツールの活用」である。しかし、『テスト開始時の品質が貧弱であれば、リリース時の品質は期待できない』といわれるように、「テスト開始時の品質」が悪ければツールの効果も十分な期待はできない。テストの効率化を支えるのは、「テスト開始時の品質」の向上であり、テスト自体の効率や質を向上させる「ツールの活用」の両輪であると考える。（図12）

テスト開始時の品質を上げるための施策についてここまで述べてきたが、ツールの活用については、次の機会に論じることとし、本論ではその内容については省略する。

5章、6章では、技術的側面から施策を述べてきたが、本章では、内部品質の向上のために人や組織といった面から施策を考える。

元日立で品質管理を指導されてきた、つくば国際大学の保田勝通氏は、「高品質を実現するために、一番重要なことは何か？それは、『品質を保証するぞ』という組織としての強い覚悟である」と言われる。プロセスや技法を高めても、短期的な効果しか得られない。なぜならそれを実施するのは人であり、長期的、継続的に品質を高めるには組織が系統的に人材の育成に力を入れるとともに、職場環境の改善に取り組むべきである。

過去の事例からも、品質は要員の高い意識に支えられていると感じる点は多い。品質を作り込むという、高い意識と正しい方針に基づく、充実した、やりがいのある、達成感を味わえる、チームワークのよい楽しい職場が、品質の良いソフトウェアのためには必要である。

過去のプロジェクトや組織、IBMのU研活動を通じて情報収集してきた人材育成と組織の文化に対する取り組みについて示す。

長期的に継続して品質を高めていくために、当該組織では以下のような取り組みで内部品質に対する知識やノウハウを育成している。

a）習慣化教育
ちょっとした不注意を減らすだけでもテストの効率は向上することから、新人の育成期間に先輩からのOJTを通じてケアレスミスの低減の習慣化を徹底する。

b）日常業務教育
現場にノウハウを求めて、データでものを見て、現場にフィードバックさせるために、日常業務教育の実施。

c）技術教育
品質向上には技術力の向上は必須である。特に新人から初級社員にはプログラミングやプログラム設計の基本として、「構造化プログラミング」や「構造化設計」について社員を講師として、毎年教育を実施している。
先輩諸氏から引き継いだ技術の継承だけでなく、生産性やテストの効率向上のために、他プロジェクトの設計(方法論)の勉強会やツール等のセミナーへの参加も積極的に実施している。
また、中堅には将来を見据えて、見積りや品質管理、協力会社の対応なども業務を通じて教育するようにしている。

d）自己研鑽
技術力育成の上では自分で学ぶ姿勢も重要である。資格取得の奨励だけでなく、社外セミナーや社外の研究会等への参加を後押しするために、マネージャ陣は計画的な作業の進め方や業務の調整に理解を示すよう心がけている。

前述した保田氏は、「達成感を味わえる、チームワークのよい楽しい職場から、良いソフトウェアは生まれる」とも言われている。よいマネージャは、組織の文化水準向上を特に意識しているわけではないが、以下に示すような点に留意して組織運営を行っている。

その成果は、結果としてプロジェクトの成果物の品質に表れると考える。

テストは「目に見えないソフトウェアの品質を証明する」唯一の手段であるため、どんなに品質が良いと思われても、テストを省略することはできない。検証としてのテストは必要不可欠であるが、「デバッグ」は最小限にとどめるべきであり、そのためには不良を作り込まないことに注力すべきである。

品質を確保するには、テストで品質を確保しようとするような「テスト偏重主義」からの脱却を図り、設計作業を行う中で品質を作り込み、「テスト開始時の品質」を向上させることが重要である。このことで、テストの効率化が図れ、テストに掛かる工数を削減でき、その分を設計作業に回すことができる好循環を生み出すことにつながる。

さらに、プログラム構造、ドキュメント(設計書)、保守性などに着目して内部品質の向上を図ることで、テスト開始前の品質向上によるテストの効率および質の向上ばかりではなく、ビジネスに対するアプリケーションの価値向上といった「もう一段上の品質」につながる。

「もう一段上の品質」は更なる要員のモチベーションの向上につながり、内部品質を向上させるような活動を促し、テストの効率向上につながり、品質を一段高めるサイクルを生み出していく。（図13）

また、このサイクルを支えているのは、メトリクスを用いた可視化による品質予測・対策の活動である。この活動はプロジェクト単位で行うと、プロジェクトが解散してしまうとノウハウが残らないため、PMO(Project Management Office)的な機能が重要となる。
PMOは、この活動で各プロジェクトの状況を見ながら、資源配分を調整して全体最適を図り、さらに、数値で管理されたKPIをフィードバックし新しいPDCAサイクルに繋げ、生産性を上げ、より設計や教育にウェイトがかけられるように改善を図るべきである。

最後に、プロセスや技法を高めても、短期的な効果しか得られない。なぜならそれを実施するのは人であり、長期的、継続的に品質を高めるには組織が系統的に人材の育成に力を入れていくべきであり、この視点も大切であることを付け加えておく。

本論がテスト偏重主義からの脱却を実現し、システム開発における品質向上につながれば幸甚である。

参考文献
1.　高山隆一，第55回IBMユーザー・シンポジウム論文、「もう一段上の品質を目指して～テスト偏重主義からの脱却のカギは内部品質にあり～」、2016/01
2.　保田勝通（つくば国際大学）、JaSSTソフトウェアテストシンポジューム-'06 in Tokyo 一ケタ高い品質のためのソフトウェアテスト
3.　高橋寿一、技術評論社、「現場の仕事がバリバリ進む ソフトウェアテスト手法」、ISBN 4-7741-2711-6、2006
4.　日経コンピュータ、特集2:"テストありき"でソフトウェア品質を確保、2006.06.12号
5.　日経ソフトウェア、ソフトウェア・エンジニアリング、2006.07号
6.　CAIT(旧中央情報教育研究所)刊、高度情報処理技術者試験-プロジェクトマネージャ テキスト
7.　高山隆一，アシスト誌、最新技術動向「システム開発と品質への取り組み」、2005 09号
8.　高山隆一，アシスト誌、最新技術動向「もう一段上の品質を目指して」、2007 01号
9.　Rick Craig、Stefan P. Jaskiel 著/宗雅彦 監訳/成田光彰 訳、「体系的ソフトウェアテスト入門」、ISBN 4-8222-8207-4、2004
10.　G.J. Myers, et al. 長尾真他訳: ソフトウェア・テストの技法(第2版), 近代科学社. 2006/07
11.　玉井哲雄, 松田茂広, 三嶋良武: ソフトウェアのテスト技法, 共立出版. 1988/01
12.　西 康晴: 不具合の分析とフィードバックによるテストの設計, JaSST03予稿集. 2003/01
13.　Capers Jones, Olivier Bonsignour. 小坂 恭一監訳: ソフトウェア品質の経済的側面, 共立出版. 2013/12
14.　Lisa Crispin, Janet Gregory. 榊原 彰監訳: 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド, 翔泳社. 2009/11
15.　テストの実践手法を理解する、ITpro（日経コンピュータ）、http://itpro.nikkeibp.co.jp/article/lecture/20070209/261590/
16.　「特集：今、市場に求められるITアーキテクトの視点（2）」、＠IT、http://www.atmarkit.co.jp/ait/articles/1605/19/news016.html
17.　「ツールを活用した継続的なテストとフィードバック」、テクマトリック社セミナー資料、2016/07
18.　上流工程で効く，「テストの考え方」、バルテス株式会社/Qbook+、https://www.valtes.co.jp/qbookplus/1499

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。