アドベントカレンダー２１日目 第１章 点に意識を向ける（２）
こんにちは。リリカルです。前回の続きでWACATEの予習です。
WACATE2016 夏 満員御礼！と 予習内容について - WACATEブログ
今回も続いてソフトウェアテスト技法ドリルを読んでいこうと思います。
第１章 点に意識を向ける
過去の経験を活かす
第１章で取り上げられていることの一つに、「過去の経験を活かす」というものがあります。現在、新規開発に関われる機会というのはむしろ少なくなってきており、スクラッチで作るよりは前のリプレースであったり保守・運用であったりします。なので過去の経験から学ぶというのが非常に重要になってくるのですが、残念ながらあまりうまく過去の失敗から学べているとはいえないのが現状です。
なぜでしょうか？ハードの世界では故障モードをもとにFMEAを作成し、デザインレビューを行うことで再発を防ぐ試みがある程度成功しているようです。
ソフトウェアの世界では、鉄がさびるといった自然科学で説明のつく故障のメカニズムと異なり人的なミスがその原因の大半を占めます。自分の経験で言うと、「仕様をよく確認しないで、誤解したまま進めてしまった」「インタフェースを勘違いしていた」「仕様書に誤植があり、そのままコーディングしてしまった」などです。どれも、自然科学とかいうよりは認知心理学とかの方が分野が近そうです。
ドリル本では、対策の一つとして「多くのバグ票を読むこと」が挙げられています。もちろん作り込み要因の欄に「コーディング誤りのため、修正する。」としか書いていないようなバグ票は何の参考にもなりませんから、きちんと原因を書いてもらうようにしましょう。そして原因欄を読み、「このバグを作り込んだ根本原因は何だろうか」というのを考えてみます。例えば「定数設計書のパラメータに誤りがあった」のであれば、パラメータが妥当かどうかを有識者にレビューしてもらうようにするとバグが減るかもしれません。これを体系的にやろうとすると、分類してメトリクスをとって分析して…というふうになります。
経験ベースのテスト
他にも経験ベースのテストには種類があって、エラー推測や探索的テストといった手法があります。経験を積んでいくと、間違いが起こりやすいところとか誤りの多いパターンが見えてきますから、そこを狙っていくわけです。当然これらの技法は、豊富な経験があるベテラン技術者にか十分な効果を発揮できないということに注意が必要です。
第１章まとめ
第１章では、はじめに「三色ボールペンを使って仕様書を読み込む」「具体的な値の間、対称、類推、外側を考えてみる」「意地悪条件を考える」といったことが述べられました。
それから、過去の経験を活かすというところも紹介されました。バグそのものよりも、「バグが作り込まれるメカニズム」に着目するのが重要です。
基本的な事柄ではありますが、これだけでも意識するとテストの品質はかなり上がるのではと思っています。
開発者の立場であったとしても、例えばユニットテストなどの時に自分がどんな間違いをしやすいのか考えるのは有益ではないでしょうか。
それではまた次回に続きます。
