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

MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST'13東海SIG(9)

JaSST'13東海SIG(8)からの続きです。

今回は、「JaSST'12東海SIGでの気付き」の【4.観察】です。
(※1/25に本稿を公開する予定でしたが、私のミスで【5.推測】を先に公開してしまいました。申し訳ございません。)

(1)テスト対象の表示値やLED等の出力の変化

テスト実施結果でOK/NG判定するとき、製品利用者に見える形で表示部分の値やLEDの出力をじっくり観察することがあります。特に、リアルタイムOSで動作している組み込み系機器は、時間の変化と共に状態が変化していますので、出力の変化については変化の瞬間に注視しています。探索的テストでバグのにおいを嗅ぎつけるきっかけの1つになります。

(2)仕様書の変更頻度

テストベースとなる仕様書は、下記に示す要素により変化します。

  1. 仕様の認識誤り
  2. 要求の変化
  3. 他モジュールとのI/Fの食い違い
  4. マイコンやメモリの制約が発覚
  5. ビジネスの変化

上記の変化がテスト実施時に発生することがありますので、時々テストベースとなる仕様書の変化を見て、変化内容がテスト実施内容に影響がある場合は、変化内容をテストチャータとして利用します。

(3)仕様書の更新時間帯(特に深夜)

社内政治によって開発工数が縮減したり経営層からのコスト削減の重圧が発生している場合、開発メンバーが焦り、成果物(仕様書)の出来具合が劣化することがあります。特に、深夜の時間帯に成果物(仕様書)が更新されたとき、内容を確認すると仕様の条件が抜けるなど、仕様の欠陥が散見されます。仕様の欠陥によって、結果的に誤ったコーディングを行ったり、複雑なソースコードをアウトプットすることに至りますので、バグの怪しいポイントになると思います。

(4)設計者席の雑踏度(問い合わせ頻度)

時々ですが、私が設計者に外部仕様の不明点について質問することがあります。また、設計者がチーム内の設計者や他部門(他開発部隊、マニュアル部隊、営業部隊など)から質問されることもあります。私の職場は、設計部隊もテスト部隊も同じフロアにいますので、通路側を見て誰が通ったか、もしくは声に耳をそばだて、「何が不味いのか?」を特定し、仕様やコーディング時の欠陥になりそうなポイントを押さえたりします。特に、お問い合わせ頻度から、欠陥の傾向を推測します。

(5)設計レビューで揉めた機能 or キーワード

経験則ですが、仕様書の設計レビューで揉めたところは、仕様書やテスト対象の欠陥が多い傾向にあります。また、設計レビューの指摘リストを見ると、傾向をつかんだときにキーワードが思いつくことがあります。テストチャートの1つの要素として活用すると、欠陥が検出しやすいです。

(6)設計レビューで何度も実施している機能

先述の(5)に類似していますが、欠陥数が多い傾向にあります。具体的には、テスト実施時に「挙動が○○だが、仕様書を見ても2つ以上の解釈が出てきて混乱する」という声もあります。設計レビュー指摘も注意深く観察すべきです。

次回は、「JaSST'12東海SIGでの気付き」の【5.推測】です。