株式会社ネクスタ_製造業向け生産管理SaaSシステムで最強を目指すために_ソフトウェアテスト編#1
9月27日〜10月5日
文字数 約11,000
はじめに（所感）
ネクスタのスマートＦは毎週アップデートする驚異的なスピードで付加価値を向上しています。
ただ一方で限られたリソースで不具合をどうやって撲滅するかに頭を悩ませています。
なんとかテスト人員を1.5名とカスタマーサクセスチーム3名で毎週テストを実施しています。
かろうじて、テストレベル3（第1章参照）までは到達していると安心はしましたが、テストの仕方は各人バラバラ。
早急にQAチームを立上げたいのですが、これがなかなか採用に苦労しています。
ネクスタのPdMとして、テストに対しては無知では許されないので、2冊一気に読み込みました。
先に言っておくと2冊の違いは大きくありません！
ただ素人には次に紹介する本の方がおすすめです！（公開後にリンク貼ります）
（どちらも10,000文字を超えてしまうので、ちょっと読むの大変かと思いますが）
同じ悩みを抱えている企業様も多いと思いますので、一助になればと思います。
本当にスマートＦは素晴らしいプロダクトなのでQA経験者も大募集です！！
是非興味が少しだけでもあれば、連絡ください！
＜株式会社ネクスタの採用ページ＞
■ネクスタのPdM業務
第1章 テストのプロセス
・システムの規模がどのようなものでも、すべての異なる組み合わせとすべての異なる入力データの組み合わせに対してテストすることは不可能
・リソースの限りがある中でテスト担当者がほんの小さな部分（サブセット）を選んでテストする以外に方法はない
◼️テストとは
・テストの本質的な部分は「実際どうなっているか」と「本来どうあるべきか」を比較するプロセス
・IEEEでは「ある特定の条件下でシステムまたはコンポーネントを操作するプロセスであり、その結果を観察または記録してシステムまたはコンポーネントのある側面を評価すること」と定義されている
・ある条件がテストケース
・テストの成熟度レベル
レベル0：テストとデバッグには何の差もない。
・デバッグ以外にはテストには特別な目的はない
レベル1：「テストの目的はソフトウェアが動くことを示すこと」
・ソフトウェアが正常という前提から始まるため欠陥を見つけ出そうとする眼を曇らせる可能性がある
レベル2：「テストの目的はソフトウェアが動かないことを示すこと」
・レベル1とは全く異なる姿勢で、テスト担当者は欠陥を見つけ出そうと努力する。このアプローチは鬼のように厳しいテストケースで調べ上げテストする
レベル3：「テストの目的は、何かを証明することでなく、プログラムが動かないことによって発生する危険性をある許容範囲まで減らすこと」
・システムが正しくないことはたった1つのテストケースで証明できるが、正しく動作することを証明するのは不可能。それを証明するには有効な入力データと無効な入力データのすべての組み合わせをテストしなければならない。ソフトウェアの品質を理解しどれくらい不完全かをプログラマに提供し、もしシステムを現段階で顧客に提供したら、自社にとってどれだけマイナスのインパクトがあるかを評価する
レベル4：「テストは行動でなく大袈裟なテストをすることでなく品質の高いソフトウェアを作るための精神的な規律」
・この成熟度は、よりテストの容易なソフトウェアを開発することに重点が置かれる。さらには自己診断可能でテスト担当者が検出しなくても自らエラーをレポートするようなコードを書くことも意味する
◼️テストケース
・有効性と効率のためにはテストケースを「設計」しなければならない
・きちんと設計されたテストケースの3つの構成
①入力
・キーボードが入力さーたデータだけでなくI/Fからのデータ、ファイルやデータベースからのデータ読み出しなど
②出力
・出力にも多様性がある。画面に表示されたデータだけでなく、I/Fへのデータ、ファイルやデータベースへの書き込みなど
・テストケース設計において期待する結果が何かを決定するのが「オラクル（神の御宣託）」
③実行の順番
1、順番通りのテストケース
・作成されたテストケースは相互に影響し合う可能性がある
・良い点はテストケースが一般的に小さくて単純
・難点は1つのテストが失敗すると後に続くテストが全部無効になる
2、互いに独立なテストケース
・各テストケースが完全に自己完結し、相互に依存関係を持たない
・良い点はどんな順番でもテストを実行できる
・難点はテストケースが大きくて複雑になるため、設計、作成、メンテが難しくなる
◼️テストの種別とレベル
種別1「ブラックボックステスト」
・要件や仕様に基づいてテストする戦略
種別2「ホワイトボックステスト」
・テスト対象の内部パス、構造、実装に基づいてテストする戦略
レベル1「単体テスト」
・ソフトウェアの最も小さい部品で、通常1人のプログラマの作業成果で1個のファイルとして保存される
レベル2「結合テスト」
・単体をサブシステム、最終的にはシステムとして結合する
・単体としては機能しても結合すると障害が起こることがある
レベル3「システムテスト」
・システムコンポーネントは顧客に届ける製品を作り上げているすべてのソフトから構成される
・最も高いレベルの統合時に起こる欠陥に焦点を絞ったテスト
・機能性、ユーザビリティ、セキュリティ、ローカライゼーション、パフォーマンス、バックアップと復元など諸々のテスト
※本書では機能テストのみ取り扱う
レベル4「受け入れテスト」
・顧客がソフトウェアを受け入れて代金を支払うテスト
ISBN978-4-8222-8251-1
P11〜P21
PartI ブラックボックステスト
第3章 同値クラステスト
・同値クラステストとは、十分なテストカバレッジを保ちながらテストケースの数を管理可能な程度に減らすための技法
・例えば年齢によって雇用するかどうかを決めるシステムの場合、各年齢ごとの処理が最もわかりやすいが、そんなプログラムは作らないし、一つずつテストするのはしんどい
・これを年齢の範囲を条件にした処理にすればプログラムはシンプルになるし、テストも一歳ずつする必要はない
・テストが必要なのは1つの値のみだがどの値を選べば良いのか
・実はどの値を選んでも範囲内のどの値とも同じ程度に有効
・ここでいう範囲のことを同値クラスという
・同値クラス内のあるテストケースで欠陥が検出された場合は、同じ同値クラスの他のすべてのテストケースで同じ欠陥が検出される（逆も然り）
・入力値がFRED、$&#!@のような無効な入力値に対してもテストケースを作成する必要があるかと考えると「場合による」という答えになる
・この答えを理解するには、オブジェクト指向と世界で言う契約による設計の考え方を理解する必要がある
・契約による設計アプローチではモジュール（メソッド（メソッド）は事前条件および事後条件と定義される
・事後条件とはモジュールが何をするか約束するもので、事前条件は事後条件を満たすためにそのモジュールに何が必要かを定義し、事前条件と事後条件はモジュールとその呼び出し側との間の契約を成立させる
・つまりもし特定の条件でそれが動作する必要がなければその条件でのテストは不要となる
・もう一つのアプローチとして防御的設計がある。これはモジュールなど、どんな入力でも受け付けるように設計される
・事前条件が満足されない場合はモジュールはエラーか例外を返す
・設計が契約または防御的かによってテストアプローチは変わる
◼️同値クラステストの技法
①同値クラスが何かを識別する
②それぞれの同値クラスに対してテストケースを１つ作る（時間と予算があれば追加のテストケースがあっても良いがあまり効果はない）
③入力値の型が異なれば、違う型の同値クラスが必要
・入力が連続する範囲の値の場合は有効値のクラスが一つと、範囲外上下の無効値2つがある
・有効値が連続でなくリストが少ない場合は有効値クラス一つひとつにテストケースを作るのは有効
・同値クラステストの技法が適しているのは入力データの大半がある範囲内または集合内の値をとるシステム
ISBN978-4-8222-8251-1
P29〜P41
第4章 境界値テスト
・前章でも利用した年齢による人材雇用アプリのルールは
0〜16歳：雇用しない
16〜18歳：パートタイムでのみ雇用
18〜55歳：正社員として雇用
55〜99歳：雇用しない
・プログラムで境界値の等号（＞、≧）を間違えることはよくある
◼️境界値テストの技法
①同値クラスを見つける
②各同値クラスの境界を見つける
③境界上の値、境界のすぐ下・上の値を選びテストケースを作る
・境界のすぐ上の値が別の同値クラスに含まれる可能性があることに注意、テストを重複して実施する必要はない
・リソースに余裕があるなら境界から離れた同値クラス内のテストケースを追加しても良いが効果は少ない
・システムの全ての入力項目のすべての境界値に対してテストケースを作成する時間はまずないので、複数の入力フィールドを同時にテストするテストケースを作成する
ISBN978-4-8222-8251-1
P43〜P50
第5章 デシジョンテーブルテスト
・デシジョンテーブルとはある種類のシステム要求を把握して内部システム設計を文章化するためのツールであり、条件の集合に基づいて複雑なビジネスルールを表現する
・デシジョンテーブルはシステムが実装しなければならない複雑なビジネスルールを記録するために用いられる。それに加えてテストケースを作成する指針としても役に立つ
・縦軸：入力条件1〜m、アクション1〜n（入力条件の様々な組み合わせで決まるアクション）
横軸：ルール1〜p（条件の一意な組み合わせで、結果としてルールに関連付けられたアクションが実行される）
・デシジョンテーブルには条件のすべての組み合わせを含んでいる
例）2つの2値条件の場合YESとNOの場合、｛YES、YES｝、｛YES、NO｝、｛NO、YES｝、｛NO、NO｝
・各ルールはこれらの組み合わせの一つに相当する
・デシジョンテーブルで条件とアクションが出し切れれば、テストケースの選択は単純にそのものになる（各ルールがそのままテストケース）
・各ルールに対してテストケースを少なくとも1つ作成する必要がある
・ルールの条件が2値であれば各組み合わせに対して1つのテストケースで十分
・条件が値の範囲で定義される場合は範囲の下限と上限の両方のテストを考える必要がある
ISBN978-4-8222-8251-1
P51〜P60
第6章 ペア構成テスト
・ペア構成テストが有効な理由はよく分かっていない
・仮説としてほとんどの欠陥は
①シングルモード欠陥：テスト対象の機能が単に動かないので、どんなテストでも欠陥を検出できる
②ダブルモード欠陥（ある機能/モジュールと別の機能/モジュールのペアでは障害が起きるが、ほかのすべてのペアでは正常）
のどちらかだということ
・ペア構成テストはシングルとダブルモードの欠陥をすべて可能なテストケースの最小のサブセットを定義してくれる
◼️技法
・すべてのペアを見つけるための2つの技法
①直交表
・表現としてL_4(2_3)（P65）
・手順（P69〜83に詳細例）
1、変数の識別
2、各変数がとりうる値の数を求める
3、列の数が変数の数と同じ以上で各変数のとりうる値の数に対応する値が列に含まれるような直交表を見つける
4、直交表にテスト問題を割り付ける
5、テストケースを作成する
②全ペアアルゴリズム
・直交表のように外部から持ってくる仕掛けを用いるのではなく、直接ペアを生成できるアルゴリズムを利用する方法
・直交表で選択した組み合わせと全ペアアルゴリズムで選択した組み合わせは必ずしも同じでないがあまり重要ではない
・肝心な点はパラメータの組み合わせがすべて選択されていること
・①、②のどちらが良いかは色々と議論があるがペア構成テストの効果を保証するソフトウェア欠陥物理学は存在しない。確かめるにはとにかく試してみるしかない
ISBN978-4-8222-8251-1
P61〜P90
第7章 状態遷移テスト
・状態遷移図はデシジョンテーブルと同様に、あるタイプのシステム要求を把握して内部システム設計を文書化するのに役立つツール
・デシジョンテーブルとの違いは処理のルールに関してほとんど記述しないこと
◼️技法
1、状態
・円で表現されシステムが一つまたは複数のイベントを待っている状況。
・状態は過去にシステムが受け取った入力を記憶し、後でイベントが発生した時にどう応答すべきかを規定する。
・一般的に状態はシステムの1つ以上の変数値により表現される
2、遷移
・矢印で表現され、イベントによってある状態から別の状態に変わる
3、イベント
・矢印のラベルとして表現され、システムの外部からI/Fを通してシステムに入力され、時にはシステムの内部で生成されることもある
◼️状態遷移表
・現在の状態、イベント、アクション、次の状態という4つの列で構成される
・状態遷移表の利点は有効なものだけでなくすべての可能な状態遷移の組み合わせを列挙していること
・認識されていない、文書化されていない、あるいは扱われていない要求を組み合わせて掘り起こすことにもつながり、コーディング前に認識できることの価値は大きい
・1つの状態から他の状態への無効なパスの実行を可能にする実装上の欠陥も検出できる
◼️テストケース
①全ての状態を少なくとも一回訪れるような一組
②全ての状態を少なくとも一回は起動されるような一組
③テスト対象の全てのパスを少なくとも一回は実行されるような一組
④すべての遷移を少なくとも一回はテストするような一組
一般的には④のレベルが推奨される
ISBN978-4-8222-8251-1
P91〜P106
第8章 ドメイン分析テスト
・同時に複数の変数のテストをする方法について検討する
・変数が相互作用を持つ場合、変数を一つひとつ独立にテストしても欠陥を検出できない
・ドメイン分析テストは複数の変数を一緒にテスト可能な場合に有効で効率の高いテストケースを特定できる
◼️技法
用語の定義
①onポイント：境界上の値
②offポイント：境界に隣接する値
③inポイント：すべての境界条件を満たすが境界上にない値
④outポイント：いずれの境界条件も満たさない値
※閉じた境界（X≧α）：offポイントは境界の近傍かつ外側
開いた境界（X＞α）：offポイントは境界の近傍かつ内側
・1×1ドメイン分析技法によるテストケースの選択はできる
1、それぞれの不等式条件に対して一つのonポイントとoffポイントを選択する
2、それぞれの等値条件（＝）に対して1つのonポイントと2つのoffポイント（少しだけ小さい値た少しだけ大きな値）を選択する
ISBN978-4-8222-8251-1
P107〜P115
第9章 ユースケーステスト
・ここでは個別のトランザクションを一つひとつテストすることによってシステムの機能を最初から最後まで通しで実行するようなテストケースの設計について考える
・ユースケースは、アクターがある特定の目的を達成するためにシステムをどう使うかを示すシナリオ
■ユースケースの有用なポイント
1、使われている開発パラダイムに関係なく技術的な視点でなくユーザの視点からシステムの機能要件を把握できる
2、要件収集と要件定義のプロセスにユーザーが積極的に参加するために利用できる
3、システムの鍵となる内部コンポーネント、構造、データベース、関係を特定するためのベース
4、システムテストと受入テストのテストケースの開発するための基盤として役立つ
◼️技法→P119に詳細リスト
・ユースケースは入力データを規定しないのでテスト担当者がそれを選択する必要がある
・テスト対象のトランザクションに目を向けそれぞれのリスクの大きさを考慮することが重要
・テストケースを作成するときは、まず最も頻繁に使われるトランザクションのための正常データから始め、次に境界値と無効データを試す
・実稼働状況で起こりうる場合は、トランザクションをおかしな順番で試してみる
・主成功シナリオに対して少なくとも1つのテストケースを作成し、さらにそれぞれの拡張に対して少なくとも1つずつテストシナリオを準備すればあるレベルのテストカバレッジは達成できるが、どれだけ行っても入力値の組み合わせはほとんど未テストである
ISBN978-4-8222-8251-1
P117〜P124
SectionII ホワイトボックステスト技法
第10章 制御フローテスト
・2種類あるホワイトボックステスト技法の一つ
・制御フローテストはプログラムコードのモジュール内の実行パスを識別し、それらのパスを網羅するようにテストケースを作成する
・一般的に使用されているプログラムモジュールですべての制御フローパスに網羅するテストを実施しようとすると、以下の重要な問題点に直面する
1、パスの数がとてつもなく大きくなる可能性がある
2、仕様書で記述されている要件を満たすパスがモジュールでは単純に欠落しているかもしれない。どんなテストを用いても実装されていないパスは見つけられない
3、制御フローは正しくてもステートメントの取り扱いが不正確なために欠陥が生じるかもしれない
4、モジュールが大半のデータを正しく処理できても特定の少数のデータの場合は処理に失敗するかもしれない
◼️技法
・制御フローグラフは制御フローテストの基盤になるもの（フローチャートのようなもの）
・カバレッジとはテスト可能なコードに対して、実際にテストされたコードの割合がどれくらいかという意味
・カバレッジのレベルには0〜7までの8段階がある（P132〜137）
・構造化テスト（基礎パステストと呼ばれている）の手順は
①ソフトウェアモジュールから制御フローグラフを作成する
②グラフのサイクロマチック数（C）を計算する
C＝リンク数ーノード数＋2
③C個の基礎パスの組を選ぶ
④各基礎パスに対応したテストケースを作る ・
・サイクロマチック数とは、直列の組み合わせでモジュールを通過するすべての可能なパスを生成できる、独立でループを含まないパス（基礎パス）の最小の数
・基礎パスを抽出するための手順
①基準のパスを選ぶ（例外処理などではない一般的な実行パス）
②基準のパスの一番目の条件判定を変更する（他の条件判定の最大数は基準パスと同じにする）
③基準パスに戻って2番目の条件判定を変える
④3番目の条件判定を変更する。それぞれの判定結果をグラフの最後にたどり着くまで一つ一つ変更する
⑤基準のパスに沿ったすべての条件判定が変更されたので、今度は第二のパスに戻って条件判定を一つ一つ変更する
⑥①〜⑤で出てきた各パスに対応するテストケースを一つずつ作成する
ISBN978-4-8222-8251-1
P129〜P148
第11章 データフローテスト
・データフローテストは、よくあるプログラムのミスである「最初に値を代入せずに変数を参照するようなエラー」を見つけるために強力なツール
◼️技法
・データ値を持つ変数は生成、使用、消滅のライフサイクルがある
・データフローダイヤグラムら定義、使用、消滅のパターンが正しいかを確認する
ISBN978-4-8222-8251-1
P149〜P159
SectionIII テストのパラダイム
・パラダイムとは「ルールと規範であり、①境界を明確にし、②成功するために境界でどう行動すれば良いかを教えてくれるもの」
・今日のソフトウェアテストには正反対と言って良い2つのパラダイムが対立している
①スクリプトテスト
・要件を順番通りに検証する考え方に基づく
・テストを設計し、テストケースを文書化し実施する流れ
②探索的テスト
・順番通りのやり方の代わりに製品について学習しテストを設計し実装する作業を同時並行で進める
・現実にはスクリプトテストに何かしらの探索的テストの要素が含まれ、その逆も然り
ISBN978-4-8222-8251-1
P162〜P163
第12章 スクリプトテスト
・スクリプトテストはウォーターフォールモデルの一部分として世に登場した
・ウォーターフォールモデルにおける代表的なフェーズは
1、システム要件
2、ソフトウェア要件
3、要件分析
4、プログラム設計
5、コーディング
6、テスト
・再現性、客観性、監査性（テストケースに対するトレーサビリティ）が重要なときにスクリプトテストが利用できる
・IEEE829-1988において、ソフトウェアテストで利用可能な8つのドキュメントを定義している（P169〜173に詳細）
①テスト計画書
②テスト設計仕様書
③テストケース仕様書
④テスト手順書
⑤テスト項目移管レポート
⑥テストログ
⑦テスト不具合レポート
⑧テストサマリーレポート
ISBN978-4-8222-8251-1
P165〜P177
第13章 探索的テスト
・テスト設計とテスト実行と同時並行的な学習行為という考えの基、実施するテスト
・次に行うテストがその前のテスト結果に何かしら依存するのであれば、ある程度探索的テストを行っていると言える
・注意として場当たり的なテストとは全く異なる
・チャーターとはテストセッションの明確なミッションを定義するもので
1、何をテストするか
2、テスト担当者はどのドキュメント（要件書、設計書、ユーザーマニュアルなど）利用可能か
3、どの戦術を使うか
4、どんな欠陥を探すか
5、どんなリスクが関係するか
が含まれている
・チャーターは活用すべきガイドラインであり、従わなければならないスクリプトとは違う
・チャーターがなくても探索的テストを行うことが可能で、自由形式の探索的テストと呼ばれる
・探索的テストのアプローチは熟練技術者のスキルを尊重するもので、それに強く依存している
◼️利点
①次に実行すべきテストケースが事前に決まらず、一つ前に実行したテストとその結果に従って選択すべき場合に、高い効果を持つ
②要件が曖昧なとき、システムが不安定な開発プロセスの早期段階で、短い時間内に製品の品質についての端的かつ迅速なフィードバックを即席で欲しいと言われた時に役立つ
③欠陥の検出後、その欠陥の規模、範囲、バリエーションを探索してより十分なフィードバック開発者にしたい場合に役立つ
④スクリプトテストが疲弊しているときにそれを補完するものとして役立つ
◼️難点
①欠陥を予防する力はない。スクリプトテストは要件収集や設計のフェーズでテストケースがかいしされるので、早期に欠陥が識別され、修正できる
②どのテストをどの順番で実行する必要があるかが事前に確認できている場合は、探索する必要はない
③契約などでスクリプトテストの実施が要求される場合はそれに従わなければならない
ISBN978-4-8222-8251-1
P179〜P186
第14章 テストの計画
・古典的と適応型の計画を対比すると
①古典的テスト計画
＋要件定義、分析、設計、コーディングの過程（システムが出来上がってテスト可能になるずっと以前の段階）
②適応型テスト計画
＋テスト戦略の選択段階（現段階で入手可能な知識の量に従って）
＋各画面、機能、フローがテストできる以前
＋個別のテスト開始時点
＋テストの途中（予期せぬこと、理解できない現象を観察した時）
・適応型計画では、利用可能な時間とリソースに基づいて計画できるときに、利用可能な知識に基づいて計画できるところまで計画するが、計画が可能になる前にはそれを行わない
ISBN978-4-8222-8251-1
P187〜P193
Part IV 支援技法
第15章 欠陥の分類
◼️プロジェクトレベルでの分類
・SEI(The Software Engineering Institute） はソフトウェアシステムの開発で遭遇するさまざまなリスク要因を識別し、クラス分して評価するのに役立つ（P199）
・SEIの分類から心配な点があれば、それに対して重点的に実施することをマップしていく
例）
＋要件の安定性→公式のトレーサビリティ
＋不完全な要件→探索的テスト
＋要件の記述が不正確→デシジョンテーブルや状態遷移図
＋システムのパフォーマンス→パフォーマンステスト
＋単体テストが不十分→テストに資源を追加投入
＋使いやすさに問題→ユーザビリティテスト
など
◼️ソフトウェア欠陥の分類
・Boris Berzerによる分類（P202）
・Kaner、Falk、Nguyenによる分類（P204）
・Robert Binderによるオブジェクト指向用の分類（P205）
・Whittakerによる探索的テストでどこを探索すれば良いかを教えてくれる分類（P206）
ISBN978-4-8222-8251-1
P197〜P210
第16章 テストの終了判定
・テスト終了判定の5つの基本条件
①カバレッジ目標
・テスト可能な事項に対して、実際にどれだけの割合がテストされたかを意味する尺度
・目標を設定するとテスト担当者が欠陥を検出する可能性を下げ、カバレッジ目標を楽に達成出来そうなテストケースを無意識のうちに作成しかねないという批判的意見もある
②欠陥検出率
③限界コスト
・製造業における限界コストは単体一つを余計に製造することに付随するコストと定義している
・製品業では一般的に生産個数が増えると限界コストは減少するが、ソフトウェアテストでは全く逆になる
・最小の数個の欠陥を見つけるのは比較的簡単でコストもあまりかからないが、新たに発見する作業は段々と時間もコストもかかる
④プロジェクトチームの合意
⑤「いいから出荷しろ」の一言
ISBN978-4-8222-8251-1
P211〜P217
＜株式会社ネクスタの採用ページ＞
■ネクスタのPdM業務
この記事が気に入ったらサポートをしてみませんか？