2013年9月10日火曜日

「ホワイトボックス単体テストにおけるペアテスティング」を読んで



上記のツイートを見て興味があったので読んでみました。
感想とか気づきのまとめ。

ペアテスティング

ペアプログラミング、と同じ感じだよな、と直感的にわかりますが、Googleさんに聞くとテスティング・ペアとかも出てきてます。
ペアでテスト設計したときの品質に与える影響、および方法、最も良いテスト品質を実現するには?というあたりが、このペーパーの内容です。
また、テストコードでのホワイトボックス単体テストを対象としています。他のテストレベルだったり、ブラックボックステストだったりすると、変わってくる部分、同じような結果になる部分がまた出てきそうだなと思いました。

テストカバレッジ

テストカバレッジが高いほど欠陥検出力が高い、という引用があります。
ここではホワイトボックス単体テストなのでコードカバレッジなのですが、テストカバレッジってコードカバレッジだけなんだっけ?と思いJSTQB用語集を見ると、coverage参照となっていて、
指定の網羅条件をテストスイートが実行した度合い。パーセンテージで表す。
となっていました。コードカバレッジは別であったので、限定的なものではないなと再確認。

ミューテーション解析

ミューテーション解析は、初めて聞いた言葉でした。テストコードの妥当性をどう担保するのか、というのはいつも説明が難しいところでした。
JavaやJavaScriptでもツールがあるようですし、Jenkinsのプラグインもあるようなので、今後使ってみたいなと思いました。

検証結果

検証の結果は予想を覆すもので面白いと感じました。特に、被験者がやりやすいと感じた「ペア1台」の方法が必ずしもテストコード品質につながっていない、というところです。
先日TDDBC Boot Camp長岡1.0でペアプロしたときに「やりやすさ」だったり「楽しい」ということ感じましたが、ペアテスィングでも同じ傾向がある気がします。
ただ、必ずしも品質につながっていない、というのはペアプロも同じで、こちらはいろいろな研究がなされていることが書かれています。
ツールとしてのペア作業も、条件下にあった形で行う事で生産性や品質に及ぼす影響が大きく違うんだと、なんか当たり前のようななんだけど、感心しました。
また、そういった研究が行われているのであれば、実際の作業に活かしていく事が重要だなあ・・・って、思いました。行われていることすら知らなかったという・・・ですが。


その他

こういうペーパーを読んでないのがバレバレですが、「妥当性の脅威」、「まとめと今後の展望」という章があり、気になったところに触れられていて、今後も気になりました。
あと、こういう研究でプラクティスへの裏付けがとられていく事は長期的にとても重要だし、すでに研究されていることを活かす事も必要だと改めて感じました。
SEMATもこういう部分をどうにかしていくものなんだと思ってます。

0 件のコメント:

コメントを投稿

RedmineプラグインをGitHub Actionsでテストする

Redmine Advent Calendar 2019 の Qiita で書きました。追っかけで もう一つ 。 Travis-CIで行っていたRedmineプラグインのCIを、GitHub Actionsに変更したものです。 GitHub Actionsをやってみようという...