JSTQB FLを復習しよう①

期間が空いてしまいました。

JSTQB FLに受かったからって調子に乗ってるんじゃねぇシリーズと題してwシラバスの復習をやっていこうと思います。
ALでもやはりFLのシラバスの内容はベースになるんじゃないかなぁと言うことで。

■テストの基礎

・テストとは何か？

テストとは、本番で使われる前に、期待通りの動作をするかを確認する行為。
　→動作しない場合＝故障→その故障が発生しなくなるまで見届けることで、本番環境で故障が発生する可能性を低くすることが出来る。

テストをしないとどんなことになるか……

・経済的な損失
・時間の浪費
・信頼の失堕
・傷害や死亡事故に繋がることもある

・テストのプロセス

【テスト実行前作業】
・テスト計画
・テスト分析
・テスト設計
・テスト実装

【テスト実行時の作業】
・実行結果のチェック
・テスト終了基準の評価
・テスト完了作業
・テスト結果報告
・テストウェアの整理

【全体を通して行われる作業】
・モニタリングとコントロール

・実行するテストと実行しないテスト

テスト＝ソフトウェアを実行して結果を確認することだけではない。
実行するテストもあるが、実行しないテストもある。

【実行するテスト】
・動的テスト
　→テスト対象のコンポーネントやシステムを実行する。
【実行しないテスト】
・静的テスト
　→テスト対象のコンポーネントやシステムを実行しない→作業成果物のレビュー等が当てはまる。

・テストは検証だけではない

ソフトウェアを実行した時に、期待結果と確認結果が一致しているためだけに行うわけではない。

妥当性確認も行う。
妥当性確認では、ユーザーやその他のステークホルダーのニーズを運営環境でシステムが満たしていることを確認する。

・テストに共通する目的

【目的】
作業成果物の評価。
作業成果物をレビューする中で、正しく書かれていること以内についても確認する。
目的にする場合は、観点をあらかじめ洗い出し、評価対象の作業成果物が出来た段階で確認をする。

【検証】
・テスト対象となる作業成果物、コンポーネントやシステムが要件を満たしているか検証する必要がある。
・最も共通的なテストの目的でもある。

【妥当性確認】
・受け入れテストは、ユーザーやステークホルダーが期待していると思われる動作内容を確認する。
　→ユーザー視点での確認等が該当？欠陥の検出を目的にしないで、ソフトウェアの品質確認を行うこともある。
・所定の時期にリリースすればどんなリスクがあるのかをステークホルダーに提出するため。

【テスト対象が所定のレベルにあることの確証】
・明確化したすべての要件を満たしていることの検証。
・故障や欠陥の発見。
・妥当性確認。

上記を検証した結果は、開発担当者/PM/ユーザーに伝えることが可能な情報になる。
だが、テスト結果や欠陥修正の結果をメトリクスを使って確認する必要あり。

【欠陥の作り込みの防止】
・改善活動の一環としてテストを使うことにある。
・過去のテストで検出された故障と修正済の欠陥の原因分析を行う。
　→その後の開発時に評価観点に分析結果を取り込むことで、同じ欠陥を作りこむことを防止する活動など。

【故障や欠陥の発見】
   ・開発でのテストのメインの目的。
・なるべく多くの故障を発見して、ソフトウェアの欠陥を特定して修正する。

【ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十分な情報の提供】
・テストの最も重要な目的でもある。
・テストを行った結果、品質が所定のレベルであることを確証できない部分についても適切に評価することも含まれる。

【(以前に検出されなかった故障が運用環境で発生するなどの)不適切なソフトウェア品質のリスクレベルの低減】
   ・ ここで必要となるのがリグレッションテストである。

【契約上/法律上/規制上の要件や標準を遵守する、そして(または)テスト対象がそのような要件や標準に準拠していることの検証】
   ・ソフトウェアシステムが使われる業界ごとに、業界独自の要件や標準がある。
・それらの要件や標準に従ったテストを行う必要があり、それを検証する。

・テストとデバッグ

【テストとデバッグの違い】
・テスト
ソフトウェアに存在する欠陥に起因する故障を発見すること。
テスト担当者が責任を持つ。

・デバッグ
故障の基となる欠陥を見付けて、欠陥の原因を解析し、修正する、一連の開発活動。
開発担当者が責任を持つ。

※但し、ソフトウェア開発ライフサイクルによって、役割が変わることもあるので注意。

・テストの必要性

・成功に対するテストの貢献

テストを行うことで、コンポーネントやシステムの本番稼働時/市場で利用する際に問題が起きるリスクを軽減できる

それを怠ると…

リリース後に致命的な故障が見つかり、全品回収になる可能性。
システムの性能の著しい低さが原因で、ユーザーや顧客の作業/業務への支障の可能性。

品質向上の貢献、契約や法律上の要件/各業界の標準に合致していることが必要となる。
そのためにも、ソフトウェア開発ライフサイクルの適切な時点で適切なテスト技法を適用したテストを行うことが重要になってくる。

【要求分析】
・テスト担当者が行う。
・ユーザー欲求やユーザーストーリーのレビュー。
・このタイミングで欠陥を取り除くことによって、正しくない機能や、どのようにテストすればいいのかわからない機能を開発してしまうリスクの低減につながる。

【システム設計】
・テスト担当者とシステム設計担当者が連携する必要がある。
・設計内容のレビュー。
・設計の欠陥が混入するリスクの低減につながる。
・設計内容に対してどうテストするかを理解することによって、早い段階でテストケースの設計が可能。

【コード開発/コンポーネントテスト】
・テスト担当者と開発担当者が連携する必要がある。
・コードとそのテストケースのレビュー。
・コードに欠陥が混入するリスクの低減。
・コードのテストケースに欠陥が混入するリスクの低減。
・コンポーネントテストはコードを開発した開発担当者自身がテストを行うことが一般的。

【統合テスト/システムテスト/受け入れテスト】
   ・テスト担当者が行う。
・リリース前に行う。
・テストしなければ見逃してしまうかもしれない故障の検出につながる。
・欠陥レポートの作成によって、デバックを行う開発担当者の作業の支援につながる。

・品質保証とテスト

【品質の分類】
・当たり前品質。
・機能そのものが意図した通りに動くこと。

【魅力的品質】
・その製品を使いたくなるような特徴。
・ユーザーにとって魅力的なユーザーインターフェースなど。

但し、相反することもある。

品質保証（QA）とテストは品質マネジメントの構成要素である。
つまり、品質保証≠テスト。

・品質保証＝プロセスを守らせる活動。
・テスト＝品質を向上させる活動。

【品質保証】
品質が適切なレベルに到達するようプロセスを遵守させる活動。
※テスト活動を含む開発プロセス全体が適切に進められるよう活動する。

適切なプロセスとは…

・開発ライフサイクルをお構成する活動とその実施順序。
・計測活動の手順。
・問題報告・是正の手順。

プロセスを適切に遂行すると、これらのプロセスで作成される作業成果物は一般的に高い品質を持つ

【品質コントロール】

品質を適切なレベルに達成させる活動
※テスト活動は品質コントロールに含まれる

【品質マネジメント】

品質に関して組織の方針を示し、組織をコントロールする活動
※品質保証と品質コントロールは品質マネジメントの一部

テストは品質コントロール活動の一部
なおかつ品質保証のためのデータ提供を行うことで品質マネジメントに貢献する

・エラー、欠陥、故障

言葉の定義は現場によって異なることもある。
ここではISTQB(JSTQB)での定義を取り上げる。

【エラー】

間違った結果を生み出す人間の行為。

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

【欠陥】

作業成果物に存在する、要件or仕様を満たさない不備or欠点。
→エラーによって作業成果物やプログラムに血管を埋め込んで実装してしまうと言ったイメージ。

※バグ・欠陥・フォールとは同義であるとしている。

【故障】

コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。

但し、欠陥に依存しない故障(設定ミスや実行環境の問題など)や、期待通りではないテストの結果がすべて故障であるとは限らない場合(欠陥の含まれたプログラムが実行されない/されたとしてもユーザーに影響がないなど)もある。
また、すべての欠陥が故障となるわけではない。

【エラー/欠陥/故障のイメージ】

エラー：仕様書に書かれていた「年齢20歳以上」を「年齢20歳以下」と勘違いする。
欠陥：プログラムで「入力＞＝20」と記載すべきところに「入力＜＝20」と記述。
故障：「年齢」に「21」と入力するとしようと異なる結果が出力される。

・欠陥/根本原因/影響

【根本原因】

欠陥を埋め込んだ最初の行為or条件のこと。
欠陥を分析して根本原因を識別し、類似の欠陥が今後発生しないようにしなければならない。

【根本原因の影響】

影響も根本原因の結果である。