【社内勉強報告】「ソフトウェアテストについて」

こんにちは！

AXLBIT株式会社の@ax-shinoharaです

今回は2024年6月7日に社内で実施された社内勉強会の報告記事を書かせていただきます。

勉強会の内容は「10分でわかる〇〇」というテーマに基づいて、自身が入社してから学習してきた内容を10分程度で発表するといったものでした。
発表した内容を記事にしてまとめ直してみようと思います。

目次

1.概要
2.JSTQB、ISTQBについて
3.ソフトウェアテストの目的
4.テストとデバッグ＆エラーと欠陥と故障
5.ソフトウェアテストの7原則
6.テストの心理学

1.概要

今回の発表はテスト技術者資格制度 Foundation Level シラバス（JSTQB）より内容を抜粋して作成したものです。

「JSTQB認定テスト技術者資格」 とは、ソフトウェアテスト技術者資格の日本における認定と運営組織であるJSTQB（Japan Software Testing Qualifications Board）による、ソフトウェアテスト技術者の認定資格です。
上記資格にはFoundation Level、Advanced Levelの二種が存在します。
Foundation Level資格の対象者には、テスト担当者、テストアナリスト、テストエンジニア、テストコンサルタント、テストマネージャー、ユーザー受け入れテスト担当者、ソフトウェア開発担当者などが含まれます。

今回は「JSTQB認定テスト技術者資格」Foundation Level シラバスの
0.イントロダクションと1.テストの基礎 の章に含まれる内容をまとめて発表しました。

この記事をご覧になっているあなたも一緒にソフトウェアテストの基礎を確認しなおしてみましょう！

• 目次(テスト技術者資格制度 Foundation Level シラバス）　
  0.イントロダクション
  1.テストの基礎
  2.ソフトウェア開発ライフサイクル全体を通してのテスト
  3.静的テスト
  4.テスト技法
  5.テストマネジメント
  6.テスト支援ツール

2. JSTQB、ISTQBについて

いや、そもそもJSTQB、ISTQBとはなんですかという疑問が挙がると思われます
ISTQBの説明からした方が自然な流れのため、そちらから解説を

• ISTQB（International Software Testing Qualifications Board）
  ソフトウェアテストに関する国際的な資格認定を行う組織
  各種認定資格試験の出題範囲を定めたシラバスの作成・公開や、
  各国のISTQB加盟組織との連携・相互認証を仲介する役割を担う

ソフトウェアテストに関する国際的な組織のようです
では続いてJSTQBについて

• JSTQB（Japan Software Testing Qualifications Board）
  ISTQBの、日本における加盟組織
  資格や教育・訓練組織の認定についてISTQBと相互認証を行っている
  よって、JSTQB認定テスト技術者資格に合格すると、日本国内のみならず海外でも有効

上記のようにJSTQBはISTQBの日本版と捉えられそうですね
ソフトウェアテストの偉い組織のようです

これからはシラバスの内容の解説に入っていきます

3.ソフトウェアテストの目的

そもそも私たちは何のためにテストを行っているのでしょう？
ユーザーのため？はたまた、自社のエンジニアのため？
やった方がよいのは感覚として分かるが、それって絶対必要なのか？
それらの再確認のため、ソフトウェアテストの目的を確認してみましょう！

すべてのプロジェクトで、テストの目的は以下を含みます

• 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ
• 明確にしたすべての要件を満たしていることを検証する
• テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする
• テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する
• 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する
• ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する
• 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する

今までなんとなく行ってきたテストですが、上記の目的を満たすために行っていたのですね
コードを書く人やユーザのためだけでなく、要件を決定する人のためであったり、法律を遵守しているかどうかの確認もテストの目的とされるようです。

4.テストとデバッグ＆エラーと欠陥と故障

ソフトウェアテストにまつわる混同しやすい単語の定義をおさらいします
みなさんテストとデバッグの違いをご存知ですか？エラーやバグといった単語をその場の雰囲気で使い分けてはいませんか？
もう一度基本に立ち返って確認しましょう！

• テストとデバッグ
  「テスト」：実行することでソフトウェアに存在する欠陥に起因する故障を示すことができる。
  「デバッグ」：故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動である。その後、テスト担当者が確認テストを実施し、修正により欠陥が解決したことを確認する。

デバッグではテストの内容に加えて、解析、取り除くといった作業が加えられるようですね

上記の文章の中で故障や欠陥という単語が出てきました
これらはエラーとはどういった違いがあるのでしょうか？

• エラー、欠陥と故障
  「エラー」：開発過程中にプログラマがコードに組み込んでしまった人為的なミスを指す。誤った計算、不完全または誤解された要件理解、または単なるタイプミスなど、さまざまな形で生じる
  「欠陥」：バグともいう。ソフトウェアが設計仕様に従って正常に機能しない状態を指す。エラーが実際にソフトウェアの機能に影響を及ぼし、ユーザーの期待とは異なる結果を生み出した場合に生じる
  「故障」：故障とは、システムまたはシステムの一部が正常に機能しなくなった状態を指す。欠陥が存在することにより、ユーザーがソフトウェアを使用する際に故障が生じる

エラー→欠陥→故障といった順番で発生していくようです
出来るだけエラーの時点で気付いて欠陥、故障につながらないようにしたいですね
(あまりに理想論ですが、、)

5.ソフトウェアテストの7原則

ソフトウェアテストには7つの原則と呼ばれるものがあるようです

原則1: テストは欠陥があることは示せるが、欠陥がないことは示せない
原則2: 全数テストは不可能
原則3: 早期テストで時間とコストを節約
原則4: 欠陥の偏在
原則5: 殺虫剤のパラドックスに注意
原則6: テストは実施内容次第
原則7: 「バグゼロ」の落とし穴

原則1: テストは欠陥があることは示せるが、欠陥がないことは示せない

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。
テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、
欠陥が見つからないとしても、正しさの証明とはならない。

• 悪魔の証明みたいなものですかね、、

原則2: 全数テストは不可能

すべてをテストすること（入力と事前条件の全組み合わせ）は、
ごく単純なソフトウェア以外では非現実的である。
全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。

• 境界値分析を使用して効率的にしたいですね

原則3: 早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。
早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。

• 雪だるま式に増えていくイメージでしょうか

原則4: 欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、
特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。
（原則2 で触れたことと同様）

• 「パレートの法則」結果の80％は、全体の20％の要素によって生み出されているという考えと近そうです

原則5: 殺虫剤のパラドックスに注意

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。

• 開発者目線だけでなくユーザー目線でテストを設計したりするなど、さまざまな観点でテストを行う必要がありそうです

原則6: テストは実施内容次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる。

• ソフトウェアの性質によってテストの実施内容や方法を変えなければならないということでしょう

原則7: 「バグゼロ」の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。
また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

• 欠陥がゼロであっても、高品質なソフトウェアであるとは限りません
• 機能的な欠陥を無くそうと修正したことによって、セキュリティホールができたり、使い勝手が悪くなったりしては本末転倒ですね

あくまで原則

反しているからといってそれを振りかざさないようにしたいですね

6.テストの心理学

ソフトウェア開発は、ソフトウェアテストを含めて人が行うため、人の心理がソフトウェアテストに重要な影響を及ぼすといったことが述べられています

• テストはプロジェクトの進捗とプロダクトの品質に大きく貢献するが、様々な心理的要因により、破壊的な活動と見られる場合がある

• これらの心理的傾向を軽減するためには、 欠陥や故障に関する情報を建設的な方法で伝えるべき

• テスト担当者およびテストマネージャーは、欠陥、故障、テスト結果、テストの進捗、リスクの情報を 効果的に伝えることができ、同僚と建設的な関係を構築するための優れた対人スキルが必要となる

コミュニケーションを適切に行う方法

• 対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであることを再認識するとよい
• テストの利点を強調する。例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上 と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る
• テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする。客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレ ビューしたりする。
• 他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する
• 自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する

優秀な技術だけでなく、優れた対人スキルもテスト実行者には求められるようです

次回以降(登壇する機会があれば、、)

今回の発表では、ソフトウェアテストを行うためのルールや基礎知識を学びましたが、
次回以降発表をする機会があれば様々な種類のテストの説明を行いたいと思います

• 目次(テスト技術者資格制度 Foundation Level シラバス）　
  0.イントロダクション
  1.テストの基礎
  2.ソフトウェア開発ライフサイクル全体を通してのテスト
  3.静的テスト
  4.テスト技法
  5.テストマネジメント
  6.テスト支援ツール

ここまで読んでいただきありがとうございました。

テスト技術者資格制度 Foundation Level シラバス

テスト技術者資格制度 Foundation Level シラバス