読者です 読者をやめる 読者になる 読者になる

ソフトウェア品質シンポジウム『不具合と開発現場の実態に基づくテスト分析手法の提案』 参加レポート #SQiP

はじめに

  • 本発表における用語は概ねISTQBに準じます

研究の動機

  • どうしても不具合は発生する
  • 再発防止の活動を行っている
  • テストに関する不具合は不十分
    • 上位のテストレベルでないと検出できない
    • 中には平易な手順で発生するものもある

不具合の分析

  • 対象は直近の不具合50件
  • 不具合1つ1つにテストの技術要素(テストレベル、テストタイプ、テスト設計技法、その他気付くべきこと)を抽出・整理

その他気付くべきこと

  • 連打
  • 特殊なユーザ
  • 状態遷移完了直後
  • これらをなんと呼ぶべきなのか?
    • ISTQBのテスト条件?
    • NGT/VSTsPのテスト観点?
  • 不具合誘発条件と呼んだ

不具合の分析

  • 基本的なテスト設計技法を用いれば検出できる
  • テストタイプが非機能テストの場合、不具合誘発条件に当てはまることが多かった

存在する文書の調査

  • テストベースあり
  • テスト計画書あり
  • テストケースあり
    • テストケースからはどんなことを目的としているかわかりづらい

インタビュー

  • テスト仕様書以外のところまでテストする必要があるのか

課題

  • 品質特性に関するテストタイプの定義・選択が不十分
  • テスト分析プロセスが無く、不具合誘発条件を導出していない
  • 基本的なテスト設計技法の活用が不十分である

不具合誘発条件の分類

  • 入力ファクター
  • 内部状態ファクター
  • 外部状態ファクター
  • アプローチファクター
  • ユーザーファクター

#FL表と不具合誘発条件 + 5種のファクターごとにFL表を作成した

テストタイプ別思考過程による書式

  • テストベース(トレーサビリティ)
  • 確認内容
    • 機能
    • パフォーマンス
  • 不具合誘発条件(あれば記載)
    • 入力ファクター
  • テスト設計技法(3択)

アンケートによる評価

  • 抵抗の6階層で抵抗度を測る

評価実験

  • 従来発見できなかった不具合8件のうち、5件を発見できた
  • 新たに2件の不具合を発見
  • テスト設計書行数76件中、従来テストケースと同等でないものは22件あった

質問

  • Q.すり抜けた3件について教えて欲しい

    • A.冒頭の50件と実験のすり抜けた3件は違うもの
    • 1つは複雑な状態遷移
    • 全く関係ないと思われた変数が関係あった
    • 複雑な手順
  • Q.アプローチファクターの中で特徴的なもの(負荷をかけたら、とか効きそうなこと)

    • A.深堀りは十分出来ていない
    • アプローチファクターは入力の仕方なので、固有の誘発条件があるのだろうと思っている
    • 負荷というのは内部状態ファクターなので、アプローチファクターではない
  • Q.テストを設計するときに、テスト設計者が分析する必要があると思うが、そのノウハウはあるか?

    • A.仕様書から直接導けるファクターと経験則のファクターがあるはず
    • 入力や内部状態の一部は書いてあるが、連打などは熟練度からの教育が肝になる
  • Q.特別な不具合管理システムと仰っていたが、特別と特別ではない違いは?

    • A.一番多いのは、市場で発見されたもの
    • あとは、社内指摘でも品質管理部門で「たまたま見つけられたもの」と判断したもの
  • Q.どういうレベルで管理しているのか

    • A.再発防止策を記載していること
    • 原因と対策方法が詳しく(図やソースコード)書かれている
  • Q.ソースコードまで入ったシステムということか

    • A.全てではないが、そういうこと

感想

  • 不具合誘発条件がバグ分析と似たようなものに思えました