こんにちは。 本日はソフトウェアテストの教科書JSTQBの内容と実際に業務に反映した例をご紹介します
JSTQBとは
日本におけるソフトウェアテスト技術資格認定の運営組織です。
ISTQB（International Software Testing Qualifications Board）というソフトウェアテスト技術者の国際的な資格認定団体がありますが、JSTQBはその日本版にあたります。
いくつかテストに関する出版をされていますが、私が選んだ本は以下に掲載します。
ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応
選んだ理由は下記の通りです。
テストの目的
そもそもテストの目的ってなんでしょうか。というところから本書では書かれています。
テスト期間、テスト工数（実施する時間）、メンバーのスキルレベル、開発担当者との関わり方などなど
その条件によってもテストの目的は変わってきます。
- 要件を満たしている
- 妥当性の確認
- ステークホルダーが判断できる情報提言
- 品質レベルのリスク低減
- 契約・法律・規約の検証
- 故障や欠陥を発見する
- 欠陥の作りこみを防ぐ
- 品質レベルの確認
- 評価
など、その目的は多岐にわたります。
製品を開発する上でもいくつかの観点がありますね。
機能追加の案件なんかは製品企画やお客様とお約束した要件を満たしているかチェックが欠かせません。
また、新しい機能を追加すればするほど、今まで当たり前のように動いていた機能は
これからも当たり前のように動くことを保証しなければなりません。
言うのは簡単ですが、実際に実践するのは難しいです。
機能を追加すると思わぬところに影響を及ぼしたり、処理を追加しなければいけないところが漏れていたりと
大規模な製品ほど品質レベルを維持するのは難易度が高くなりますよね。
そんな難しい観点を網羅的にテストする一つのツールとして本書からヒントを得られればと思います。
※実際の品質を保証するものではないので、利用状況に応じて善にも悪にもなるところは注意が必要です。
テストの７原則
目からウロコだったので、詳しくレポートします。
- テストは欠陥がないことは示せない
確かにそうですね。
アプリケーションのホワイトボックステストをすべて網羅したとしても、
顧客が実際に動作させるOS/ブラウザの状況はすべて再現できるわけではありません。
どんなにテストしても「絶対に100％欠陥はありません！」ということを言い切るのは難しいですし、
正確な情報ではありません。
もちろんバグが限りなく０になるようにテストはすべきです。
- 全数テストは不可能
例えば、画面に文字を打てる入力欄があった時点で無理です。
ローマ字26文字×2（大文字、小文字）、ひらがなカタカナは濁音や半濁音を含まなくても50文字ずつ、漢字は・・・。
その組み合わせは実質無限であり、どこまでいっても全パターン網羅ではありません。
- 早期テストで時間とコストを節約
ソフトウェアテストの特徴として、V字モデルがよく話に出ます。
要件定義に何か問題があった場合は、最も下流工程のシステムテストで見つかったり、
詳細設計や実装などの問題は単体テストを見つかったりと、
問題があったときに検知できるフェーズがV字のような形なので問われています。
テストにおけるコスト同じで、品質における問題が発見されるのが、
後の工程ほど上流工程に戻って修正するコストが多く発生します。
なるべく早期に問題を発見することでリリースまでの時間の節約につながります。
- 欠陥の偏在
テストにおける欠陥の8割はプログラムの２割部分に集中して存在する説があります。
見落とした観点と、見落としに関連する観点が依存しているからだと思いますが、
私の経験上も感覚が近いので、その通りかと思います。
- 殺虫剤のパラドックス
特定の虫に同じ殺虫剤を与え続けても、いずれ虫のほうが殺虫剤に対する免疫をつけるため、
どんどん効果が薄くなることを例にしています。
ソフトウェアテストにおいても同様で、同一観点で何度テストしても問題の検知がし難いです。
テスターを変える、やり方を変える、観点を変えるなど何かしら前回のテストと差をつけて
取り組むことが必要です。
- テストは状況次第
上述した目的から、テストの在り方が変わってきます。
２４時間稼働のシステムであれば過負荷でもシステムダウンしないこと、
eコマースであれば外部に公開するのでセキュリティ面で問題ないか念入りにチェックします。
- 「バグゼロ」の落とし穴
ある観点ではバグがない状態でも、他の観点ではそうではないケースがあります。
入力欄が４桁しか入力できない問題を解決するために、５桁に変更しました。
「４桁しか入力できない」欠陥はなくなりますが、
代わりにデータベースの書き込み速度が遅くなる、といった新しい問題が発生しました。
その直し方が製品全体を見たときに本当に正しい形をよくよく考える必要があります
テストの心理学
人それぞれ立場や理解が異なることから、協力体制を考えねばなりません。
心に刺さった一例を掲載します。
<一例>
開発担当者の心情として下記があげられます。
- 何度もテストしたから実装コードが正しいはずだ（確証バイアス）
- テスト担当者よりも製品の仕様をよく知っている（指摘を受けにくい）
こうなってしまうと「開発担当者 vs テスト担当者」の対決構図になってしまいます。
「良い品質の製品を納品する」という共通認識のもと、協力体制で行わなければなりません。
テストで発見した指摘は下記の効果があります
- 欠陥情報の把握
- 品質向上
- 開発担当者のスキルアップ
- コスト削減
お互いの信頼のために、開発担当者は否定的に反応した理由を、テスト担当者は理解する努力が必要です。
相互の認識の確認と、顧客の問題を解決することが目的であるという認識のもと
製品の製造を進めていくことが大事ですね。
カバレッジ
上述した全件テストが不可能という話がありましたが、その中でもなるべく網羅的に
テストがすることが求められています。
カバレッジとはテストケースを利用して特定のアイテムを実行したときの度合いを示した式になります。
デシジョンカバレッジ（％）= (テストにより実行した判定結果の数 / テスト対象の判定結果の合計数) × 100
これをどれだけあげられるかが欠陥が限りなく０に近い製品を生めるかのポイントになります。
カバレッジの実践
実際にある案件のテストケースレビューでこの観点を取り上げる場面がありました。
伝票のヘッダーに対して明細が１：２のテストをするとき、
「複数明細の伝票」という観点でテストケースが生成されていました。
しかしユーザーの操作は明細がいくつも作れるので、１：２だけのテストでは不十分です。
もちろんテストに対する工数も有限なので実施できるパターンはやはり限られます。
しかしカバレッジを少しでもあげることは、欠陥の少ない製品に近づけるので
時間の許す限り、実践していくのが良いと判断し、メンバーに追加のテストを依頼しました。
テスト技法
一般的に紹介されていました。 個々の詳しい説明については割愛します。
- ブラックボックステスト
プログラム内部は参照せず、画面/APIなどのUIから思いつく操作を実施する手法です。
- ホワイトボックステスト
プログラム内部を参照し、分岐処理を網羅的に打鍵する手法です。
- 同値分割法
条件的に同じ判定になりうるパターンはグルーピングして一つのパターンとみなしてテストする手法です。
例：- ６歳未満は無料
- ６歳から１２歳以下は半額
- １３歳以上は定額
上記の条件であれば、「ありえない」「無料」「半額」「定額」の４つのパターンとみなしてテストします。
- 境界値分析
同値分割法の一種ですが、どの範囲で同値とみなすかを定めています。
例：２０～３４歳までの男性がアクセスするとM画面を表示する
- ２ポイント境界値分析法
- ３ポイント境界値分析法
- ２ポイント境界値分析法
- デシジョンテーブル
それぞれ；の因子を掛け合わせた観点をテストする手法です。
例：
ある美術館の入館料は次の通りになっている個人入館料
- 大人・高校生：2000円
- 中学生・小学生：1000円
- 幼児：600円
学校団体入館料
- 大人・高校生：1200円
- 中学生：720円
- 小学生：600円
- 幼児：360円
※ただし、個人・団体を問わず県民の日は高校生以下無料
上記のケースだと全部で１９ケース存在します。
ユースケーステスト
ビジネスシナリオやシステムの使い方に基づいてテストケースを設計します。
結合テストに近いです。
ユースケース名、目的、アクター、事前条件、事後条件、基本フロー、代替フロー、例外フロー、備考など
実際に使われうるケースで要素を考えます。状態遷移テスト その製品の操作状況によって実施するパターンを遷移していきます。
状態遷移テストの実践
応用して経理システムに反映すると下記のようになります。
実際に利用するとパターンが増えるので、より可視化が重要になります。
テストツール
それぞれ紹介されていました。
実際の業務で利用されるものばかりです。
要求マネージメントツール TestLink
欠陥マネージメントツール Redmine, Bugzillia
構成管理ツール Git, Subversion
継続的イテレーションツール Jenkins
レビューツール Redmine、Trac、ReviewBoard
静的解析ツール SpotBugs, Checkstyle
テスト設計ツール PictMaster
モデルベースドテストツール GraphWalker
テスト実行ツール Selenium, JUnit
要求カバレッジツール OpenClover
性能テストツール Jmeter
動的解析ツール Valgrind
数々の要素
上述したもの以外にもたくさんの要素がテストに関係しています。
経験ベースのテスト技法
これはエラー推測が重要になります。- アプリケーションの過去の動作状況
- 開発担当者が犯しやすい誤りの種類
- 他のアプリケーションで発生した故障
探索的テスト
- チェックベースドテスト
マネージメント、レビューも良いテストを実現するために大きく左右します。
まとめ
それぞれの状況に応じてベストプラクティスは異なります。
テスト技法を用いて個々の状況に適したテストを選択できるかがポイントです。
おのおの限りがあるコストの中で重大な欠陥、故障を見つけることが必要になります。
そのために実行するテストの優先順位づけも重要です。
先人が行っていたテンプレートを鵜呑みにせず、テストケースの作成、
テストの実行時に 気づいた観点はすぐ実行することが
重大なシステム欠陥を防止する策になると思います。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
