時々，コミュニティの活動でお会いした方にテスト技術の導入やテストプロセスの改善についての質問や相談を受けることがあります。なんとなく呟いてみたものの，少々反応が得られたので（つぶやき貼り付けレベルですが）記事にまとめておこうと思います。
これまであまりテスト技術や手法を技術として戦略的に導入してこなかったような現場においては，所謂「単純なテストが漏れる」という悩みが多いようです。出荷したりサービスが始まったりしたプロダクトが単純なバグにより社外で問題が生じた場合，テストを改善せよ，みたいな号令がかかることがあります。
そこでテストの改善ということになるわけですが，いきなり境界値分析がどうとか直交表がどうとかテスト観点ベースの技法がどうとかリスクベースがどうとかの話になったりします。しかしながら，先ほどの「単純なテストが漏れる」ということが起こっていた場合，いきなりそこに取り組んでも上手くいかないことが多いでしょう。
なぜならば，ベースとなる技術が導入されていなかったり，身の丈以上の技術を求めていたり，そもそもテスト技術の高度化やプロセス改善を軽んじている状況があり，そこに取り組めるだけの段階にはいないからです。
何事も一段ずつ上がっていくことが大切です。
とはいっても，どう上がっていけば良いかわからない方もいると思うので，一例を示します。
① まずは，仕様書の塗りつぶしチェックをきっちりやりきる
② 仕様書記載の仕様項目にIDをつけ，テストケースをテストケースIDと共に作り，それらを紐付けてトレーサビリティを確保する （仕様：テストケース＝1：1）
③ テスト設計技法を使い，テストのケースを合理的に増やす （仕様：テストケース＝1：n）
④ ③について量を把握し，多すぎるところは減らしたり，少なすぎるところは増やしたり，量を調整する（調整できるようにする）
⑤ 量が増えてくるとテストとしての全体像がつかみにくくなるので，全体を抽象化したモデルを作る
⑥ モデルは作っただけでは無くリファクタリングなど行い洗練する
⑦ そもそもいきなりテストケースを作らず，テストの目的や狙いを意識したモデルを作るところから始めるようにする
⑧ モデルベースのテスト分析設計手法を導入する（もしくは確立する）
⑨ テスト設計・実装・実行・報告のプロセスを整備し，技術的につなぐ
⑩ テストウェアの品質を高めるために，テストのためのレビュー技術を導入する
⑪ それらと平行して，テスト管理技術やテスト自動化，エンジニアのトレーニングや育成なども実施する
⑫ 高度化や効率化によって作り出した時間や余ったお金を使って，さらにテスト技術や活動を高める
⑬ 以降，継続的改善に取り組む
「単純なテストが漏れる」ということが発端なので，以上のような感じですすめたらどうでしょうみたいな話をすることがあります。というか，先日そう答えました。
「単純なテストが漏れる」という場合，本来は①および②から取り組む必要がありますが，そういった悩みを持つ人はいきなり③以上のことをやりたがります。ここのところ研究や実践が活発だからという（その人達にとっては）キャッチーに見える⑧～⑪みたいなところを入れたいというような話をされることもあります。ですが，その前にやるべき事はいろいろあります。「手っ取り早く導入できてできてすごく効果ある技術教えてくれませんかね，あ，無料で使えるツールとかあると嬉しいです」なんて感じで聞かれることもあり，それは世の中にないから無理ですよ，と答えることもしばしばです。
さて，先ほど挙げた①～⑬は状況を限定しての進め方の一例でしかないです。自分たちが，どう技術力を高めていこうかねー，どう改善していこうかねーということを書き出し，先ほどのように整理して，関係者と合意取らないとダメだと思います。ただし，テストの技術導入が未成熟だと書き出すこと自体が難しい場合があります。どう改善したら良いか全くわからん！みたいなときはTMMIやTPI NEXTとかの参照モデルを上手く利用したら良いのではと思います。ただしTMMIやTPI NEXT の内容を理解するためには，ソフトウェアテスト技術の素養であるとか知識がある一定レベルで必要であるため，識者の力添えが必要だと思いますが。
以上，簡単にまとめてみましたが，「単純なテストが抜ける」という方は，まずはそれを抑えることにフォーカスした取り組みから始めてみてはどうでしょうか。塗りつぶしチェックを侮るなかれ，それなりに効果が出ます。それでも抜ける場合にはじめて様々なテスト手法・技法の導入に取り組んでみてはいかがでしょうか。
