[初心者向け]ソフトウェアテストの必要性

徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第２弾。

テストの役割

通信障害で携帯電話で通話できなくなったとか、ATMが使えなくなったとかみたいなトラブルをよく耳にするが、テストはこのような"失敗"に陥るリスクを低減する役割を果たす。

ソフトウェア開発ライフサイクル（SDLC）

ソフトウェア開発モデルのこと。
代表的なモデルは、予測型・反復型・漸進型・適応型・ハイブリッド型がある。

ウォーターフォール型モデルでは

コストやスケジュール、スコープなどの計画の大半を初期段階で立案し、その計画によって開発を進めていくため、予測型の1つの方法である。

アジャイル開発モデルでは

反復型・漸進型・適応型の要素を取り入れている。
反復型はコストやスケジュールを柔軟に変更しながら変更しながら開発を進めるスタイル。漸進型は必要に応じてスコープを変更する。適応型は非常に短いサイクルで開発ウィ進める方法。

鉄の三角形

コストかスケジュールかスコープのどれかを犠牲にしなければならないという管理成約をモデル化したものだ。

この３つの制約がなぜ三角形になっているかというと、これらの成約はお互いに依存していて、「いずれかの成約を変更すると他の2つの制約に影響を与える」ことを示している。

⏬この記事がとってもわかりやすかった
https://zenn.dev/hakoten/articles/dfbff053d8df57

各フェーズにおけるテスト担当者の関与

ここで紹介するやり方はやや古めではある。より失敗率を下げるためには、もっと前のフェーズでもテスト担当者が関与して、テストの専門的知識を適用する事が推奨される。

要件定義フェーズ

要件定義とは

どのようなシステムを作るのかの全体構想をまとめる作業のこと。
このフェーズでは、システム構想を要件定義署にまとめ、ユーザーストーリー（ユーザーがどのようにシステムを利用するか）を作成する。

テスト担当者が入る理由

ユーザーが欲しいものをテスト担当者が理解できる

昔のソフトウェアは、仕様書通りに動く「当たり前品質」が重視されており、テスト担当者は仕様書通りに動くかをテストすれば十分だった。
しかし、現代は顧客が満足するものを作る「前向き品質」を大切にしている。テスト担当者が要件フェーズでユーザーニーズを把握することは、出来上がったシステムがニーズを満たしているか判断するのに役立つ。

テスト担当者の知見を生かせる

テスト担当者は欠陥に関する経験やノウハウが豊富なため、設計担当者や開発担当者とは違った視点で指摘する事ができる。
過去にユーザーのクレームなどから得た知識で気づいたことを指摘する事ができる。

設計フェーズ

設計とは

システムの欠陥の多くは、設計フェーズで生じる。
設計に欠陥があると、プログラマーが設計通りに作ったとしても、完成したシステムはユーザー要件を満たさないものになってしまう。
プログラマーに対して指示すべき項目の記載漏れも設計の欠陥とも言える。

テスト担当者が入る理由

欠陥の指摘

要件定義フェーズと同じく、設計担当者の記載漏れを気づかせるなど、テスト担当者ならではの知見の活かし方ができる。

テスト計画を考える

設計内容を理解することで、どのようにテストするか、テストケースをイメージできる効果もある。

開発フェーズ

開発では

同じ設計書に基づいてプログラミングするとしても、全く同じプログラミングコードになるわけではない。
コーディング規約を作成し、それに基づいて各プログラマーががコードを書いたとしても、スタイルやスキルによって書き方に違いが出てしまう

テスト担当者が入る理由

テスト担当者には、プログラミングコードが書ける人もいれば、読めない人もいる。どちらの場合でも、テスト担当者はプログラマーと連携して作業することで、コードをどうテストするか、お互いに理解を深める事ができる。

テストフェーズ

テストでは

これまでのフェーズでは、テスト担当者が入っていく立場だったが、テストフェーズはテスト担当者が主役になる。
このフェーズの役割は、リリース前にソフトウェアを検証して、リリース後に重大な故障を起こすリスクを低減することである。

テスト担当者が入る理由

欠陥を開発担当者に修正してもらい、テストの目的を達成することによって、ステークホルダーのニーズに合致したソフトウェア開発の成功に貢献する。

品質保証

テストの必要性は、各フェーズからテスト担当者が参画するやり方が有効な、成功のために行うこと。そして、もう一つは品質保証や品質コントロールだ。

品質保証・品質コントロール

品質保証はQA（Quality Assurance）と呼ばれている。似たような言葉で、品質コントロールはQC（Quality Control）があるが、以下のように意味が少し異なる。

QA	QC
品質保証（Quality Assurance）	品質コントロール（Quality Control）
品質が適切なレベルに到達していることを示すための活動	品質が適切なレベルに到達するように、テストを含む適切な活動を行うこと

品質マネジメント

品質マネジメント（QMS:Quality Manegement System）は、品質コントロールと品質保証の両方を結びつけるものだ。QAとQCを含む、品質に関しての組織の方針や活動全てが含まれている。

エラー・欠陥・故障

人間はエラー（誤り）を犯す。そのエラーがソースコードなどの作業成果物の欠陥(フォールトやバグ)となる。その欠陥が故障（期待した結果と違う結果が発生すること）につながる。
エラーはプログラミングのミスだけではなく、上流工程である要件定義や設計のフェーズでも誤りを犯す事があり、それがコードに影響する要因になる。

エラーを引き起こす原因

シラバスでは以下が例示されている。

• 納期のプレッシャー
• 誤りを犯しやすい人間の性質
• プロジェクト参加者の経験不足または技術不足
• プロジェクト参加者間の誤ったコミュニケーション
• コードの複雑さ、設計の複雑さ、アーキテクチャに複雑さ、解決すべき根本的な問題の複雑さ、使用する技術の複雑さ
• システム内、システム間のインターフェースに関する誤解
• 新しく不慣れな技術

これらを踏まえて、以下のようなプロジェクトは最悪と言える。

1. 短納期で複雑で、不慣れな技術を使ったシステムを
2. 経験不足・技術不足のエンジニアがプロジェクトに参加して
3. コミュニケーションが悪くて誤解が多い中で作ったもの

偽陽性と偽陰性

偽陽性

テストデータやテスト環境などが悪かったせいで、欠陥がないのに故障のような結果が出る事がある。これを偽陽性（誤検出）という。実際には欠陥がないものを欠陥として報告することだ。
テスト担当者のテストのやり方が悪いと、偽陽性をたくさん報告してしまうことになる。

偽陰性

偽陽性の反対で、検出漏れともいう。検出すべき欠陥を検出しないで見過ごすことだ。
テスト担当者のテストが甘いと、テスト完了後に山ほど欠陥が見つかってしまう。

欠陥・根本原因・影響

ある欠陥が発見されたときに、なぜその欠陥が入ったのか、原因を探る。そして、なぜその原因が生じたのかを遡り、その欠陥を埋め込んだ最初の行為である根本原因を見つける。
根本原因を見つけ出すのは、欠陥を除去するためというよりも、今後のプロセス改善に役立てることを目的とする。

次回