JaSST'13東海SIG(14)
JaSST'13東海SIG(13)からの続きです。
「探索的テストに必要な要素は何か？」(別案)
今回は、SIGでの話題を数回に分けてまとめ、私の考えも述べてみます。
SIGでの話題
探索的テストを探索する from Masao Tsuzuki
JaSST'13東海SIG(13)でも書きましたが、当初 「探索的テストに必要な要素は何か？」というお題でしたが、「考えにくい」「何を書けばよいか分からない」という意見が挙がったため、「テストチャータを作るときに必要な要素は？」というお題で議論を進めることにしました。
「テストチャータを作るときに必要な要素は？」(前編)
テストチャータを作るときに必要な要素を参加者と私で付箋に書き、ホワイトボードに貼り付けてみました。
操作
- (イベント)操作のタイミング
- 操作のバリエーション
- 操作手順が多すぎる
1.は、組み込み系機器開発でインシデントレポートの記載内容を見ると、発生状況及び原因(内部状態のインターロックが取れない/メモリアクセスできずデータを読み飛ばした/電気信号の遅延等)といったに起因したものを目にします。ハードウェア系の特性やドライバの挙動は、テストケースとして表現できないことが多いため、テスト実施段階で現象が現れることがあります。組み込み系機器の領域では、電気工学/電子工学/制御工学の知見を保有すると、タイミング関係のチャータを考えやすいと思います(経験上)。
2.は、操作の組み合わせによって発生するバグを時々発見することがあります。バグ発見のきっかけは、過去に実施したスクリプトテストの操作を数点思い浮かべ、「○○の操作と□□の操作を組み合わせたら、△△な動作するのだろうか？」と推測し、実際に操作を組み合わせたことです。スクリプトテストに記述されている「因子」と「水準」をベースに操作のバリエーションを考えてみることも有効です。
3.は、操作手順が多すぎるということは、複雑な仕様になっていることがあり、設計時に想定していなかった操作や設定の組み合わせで想定外の挙動が出てくる場合があります。操作手順が難しいと感じたならば、メンバーで共有することも必要だと思います。
開発背景
- お客さん側、担当者、経営者間の乖離が大きい
それぞれの立場で製品を検討しますが、すり合わせが上手くいかないとき、仕様の追加/変更/削除が発生することがあります。また、要求仕様が実はまとまっていなかったこともあります。それぞれの立場で、認識のずれに着目してテスト実施すると、製品に内在する問題が発見する場合がありますので、メンバー間で議論することも必要です。
想定外
- 必要ない組み合わせ
複数の機能を組み合わせて実現するシステムの場合、複数の開発グループや課/部で機能を分割して担当分けしますが、1つの開発グループで実装されたモジュールで、他の開発グループのモジュールを組み合わせて動作させると想定外の挙動を見ることがあります。前者と後者のモジュールは互いに影響が無い仕様だが、メモリ領域を余分に確保したため、関係ないモジュールのメモリ領域を破壊することがあります。
次回は、「テストチャータを作るときに必要な要素は？」(後編)です。
