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

ブラックボックスのテスト設計手法でもコードを見なくていいわけではない

 要求に対する妥当性確認のような、ブラックボックスでテスト設計を行うテストでも、製品のコードや開発のコミットログは大変重要な情報になります。


 理由はいくつかありますが、例えばコミットログからは以下のような情報が得られます。

  • 単純に、コミットログ確認による変更レビューでバグを見つけられることがある。事前レビューでのバグ検出は、実際にテストを始めてバグを見つけた時より手戻り工数を削減できることが多い。またテストすべき危ない変更もレビューで検出できる。
  • 変更の影響範囲の予測材料になる。例えば割り込み関数の変更を見つけることで割り込み発生時のタイミングの変化を予測する、といったことが可能になる。一般的に、タイミング・非同期処理・並行処理・ハードウェア起因といった、ごく稀な条件に依存するバグについては、テスト全体の網羅性を底上げするだけでは検出が難しい。そこではある程度怪しい箇所を絞り込んで探索的テストを実施したり、網羅性の厳しいテストを実施したりする。コミットログから読み取れる変更の影響範囲は、その絞りこみを精度良く行うための有効な情報になる。
  • バグの混入リスクを読み取れる。例えばコミットの乱雑度(あるコミットに対する追加・修正コミットが繰り返されている等)からプロジェクトの混乱度が読み取れるし、コードから開発者の腕もある程度読み取れる。そういったものはバグの混入密度を予測する有効な材料になる。例えば、開発者の能力的な問題でバグが埋め込まれることがあれば、その開発者は他の変更でも色々バグを埋め込んでいることが多いと経験的に実感している。こうした情報は変更の影響範囲と同様、追加テストやスモークテスト、テストの作りこみを検討する際の重要な情報になる。

 こうした情報は、テストケースの粒度を調整したり追加テストを検討したりする際に有効に活用できます。


 またブラックボックスのテスト設計であっても、テスト設計が適切かチェックする情報源としてコードを活用することができます。
 例えば境界値分析や同値分割がその典型です。境界値分析や同値分割は仕様ベースのテスト技法であり、仕様を元にテスト設計を進めていきます。コードを見なくても進められる手法ですが、そこではコードも一緒に確認すると同値クラスや境界値をより適切に見つけられるようになります。
分かりやすいのでユニットテストの例で説明しますが、例えばinputを入力とし、戻り値を出力とする以下のような関数hoge()を考えてみます。

int hoge(int input)
{
    ...(色々なコード)...
  if (input > 30 && input < 234) {
        ...(出力を操作するコード)...
        return xxx;
    }

    ...(色々なコード)...
}

 このhoge()に対して、関数の入出力仕様を元に境界値分析や同値分割を行う場合、一応上記の内部のコードは見なくてもテスト設計を進められます。
 ただそれでもコードの中の、例えば上記の「if (input > 30 && input < 234)」のような記述には注意を向けた方が無難です。それが仕様として有意な条件分けなら、「input > 30 && input < 234」の入力範囲が同値クラスとしてピックアップされており、かつ30、31、234、233等の値が境界値としてピックアップされている方が望ましいことが少なくないためです。もしそれがテスト設計の中でピックアップできていなければ、テスト対象の仕様に不備があったり、コードに不備があったり、あるいはテスト設計のやり方に間違いがあったりすることもしばしばあります。
 また「ユニットテストの網羅性の扱いについて - 千里霧中」でも書きましたが、ブラックボックスでテスト設計を行ったテストが、コードをどの程度網羅しているか調べるのも有効です。例えば仕様に対して網羅的にテストを書いてもコードカバレッジが高くならなかった場合、やはり同じように、仕様から離れた冗長なコードがあったり、仕様に不備があったりと問題が存在する可能性があります。
 ただ逆に言うと、テスト設計時にコードの中身を見てみれば隠れた同値クラスや境界を見つけ出すことができるかもしれないですし、テスト設計後テストとコードと比較すれば、テスト設計に問題がなかったかチェックできる場合が出てきます。


 まとめですが、理想的な仕様を網羅する完璧なテスト設計の実現は、テストの理想像の1つです。ただ現場ではコスト・デリバリー・技術的な問題等を抱えていたり、そもそも理想的な仕様なんてなかったりと色々阻害要因が存在するため、その理想像の実現は困難です。そのためバグの可能性やリスクを分析してテストを補強したり、テスト対象に合わせてテスト設計手法を使いこんだりと、様々な工夫をして理想に近づいていくことになりますが、コードやコミットログ等はそうした工夫を支える強力な情報源になりえます。なのでテストエンジニアがコードやリポジトリを参照できる環境は大事ですし、テストエンジニアであってもコードを読む力は身につけておくべきだと思っています。

 なお仕様と構造両方を見てテスト設計を進めるアプローチとしてグレーボックステストがありますが、上記のような心がけはグレーボックスかそうでないかに関わらず重要です。例えばブラックボックスのシステムテストを設計する際にも、必要に応じてコミットログを見たり、気になった所があればコードを見てみたりといった姿勢はテストをより洗練させる助けになります。