単純なテスト(テストケース)が漏れたときの,テスト技術・プロセス改善のアプローチ


時々,コミュニティの活動でお会いした方にテスト技術の導入やテストプロセスの改善についての質問や相談を受けることがあります。なんとなく呟いてみたものの,少々反応が得られたので(つぶやき貼り付けレベルですが)記事にまとめておこうと思います。

これまであまりテスト技術や手法を技術として戦略的に導入してこなかったような現場においては,所謂「単純なテストが漏れる」という悩みが多いようです。出荷したりサービスが始まったりしたプロダクトが単純なバグにより社外で問題が生じた場合,テストを改善せよ,みたいな号令がかかることがあります。

そこでテストの改善ということになるわけですが,いきなり境界値分析がどうとか直交表がどうとかテスト観点ベースの技法がどうとかリスクベースがどうとかの話になったりします。しかしながら,先ほどの「単純なテストが漏れる」ということが起こっていた場合,いきなりそこに取り組んでも上手くいかないことが多いでしょう。

なぜならば,ベースとなる技術が導入されていなかったり,身の丈以上の技術を求めていたり,そもそもテスト技術の高度化やプロセス改善を軽んじている状況があり,そこに取り組めるだけの段階にはいないからです。

何事も一段ずつ上がっていくことが大切です。

とはいっても,どう上がっていけば良いかわからない方もいると思うので,一例を示します。

①まずは,仕様書の塗りつぶしチェックをきっちりやりきる
②仕様書記載の仕様項目にIDをつけ,テストケースをテストケースIDと共に作り,それらを紐付けてトレーサビリティを確保する (仕様:テストケース=1:1)
③テスト設計技法を使い,テストのケースを合理的に増やす (仕様:テストケース=1:n)
④③について量を把握し,多すぎるところは減らしたり,少なすぎるところは増やしたり,量を調整する(調整できるようにする)
⑤量が増えてくるとテストとしての全体像がつかみにくくなるので,全体を抽象化したモデルを作る 
⑥モデルは作っただけでは無くリファクタリングなど行い洗練する
⑦そもそもいきなりテストケースを作らず,テストの目的や狙いを意識したモデルを作るところから始めるようにする 
⑧モデルベースのテスト分析設計手法を導入する(もしくは確立する) 
⑨テスト設計・実装・実行・報告のプロセスを整備し,技術的につなぐ
⑩テストウェアの品質を高めるために,テストのためのレビュー技術を導入する
⑪それらと平行して,テスト管理技術やテスト自動化,エンジニアのトレーニングや育成なども実施する
⑫高度化や効率化によって作り出した時間や余ったお金を使って,さらにテスト技術や活動を高める
⑬以降,継続的改善に取り組む

「単純なテストが漏れる」ということが発端なので,以上のような感じですすめたらどうでしょうみたいな話をすることがあります。というか,先日そう答えました。

「単純なテストが漏れる」という場合,本来は①および②から取り組む必要がありますが,そういった悩みを持つ人はいきなり③以上のことをやりたがります。ここのところ研究や実践が活発だからという(その人達にとっては)キャッチーに見える⑧~⑪みたいなところを入れたいというような話をされることもあります。ですが,その前にやるべき事はいろいろあります。「てっと利は約導入できてできてすげー効果ある技術教えてくんないですかね,あ,無料で使えるツールとかあると嬉しいです」なんて感じで聞かれることもあり,それは世の中にないから無理ですよ,と答えることもしばしばです。

さて,先ほど挙げた①~⑬は状況を限定しての進め方の一例でしかないです。自分たちが,どう技術力を高めていこうかねー,どう改善していこうかねーということを書き出し,先ほどのように整理して,関係者と合意取らないとダメだと思います。ただし,テストの技術導入が未成熟だと書き出すこと自体が難しい場合があります。どう改善したら良いか全くわからん!みたいなときはTMMIやTPI NEXTとかの参照モデルを上手く利用したら良いのではと思います。ただしTMMIやTPI NEXT の内容を理解するためには,ソフトウェアテスト技術の素養であるとか知識がある一定レベルで必要であるため,識者の力添えが必要だと思いますが。

以上,簡単にまとめてみましたが,「単純なテストが抜ける」という方は,まずはそれを抑えることにフォーカスした取り組みから始めてみてはどうでしょうか。塗りつぶしチェックを侮るなかれ,それなりに効果が出ます。それでも抜ける場合にはじめて様々なテスト手法・技法の導入に取り組んでみてはいかがでしょうか。

マインドマップから始めるソフトウェアテスト読書補助ガイドの公開


2007年に鈴木三紀夫さんと共著した書籍「マインドマップから始めるソフトウェアテスト」ですが,2016年8月17日にNaITE(長崎IT技術者会)のマインドマップから始めるソフトウェアテスト読書会SIG殿から読書補助ガイドが公開されました。

マインドマップから始めるソフトウェアテスト読書会SIG
 「マインドマップから始めるソフトウェアテスト」の読書補助ガイド 第1.0版 を公開しま…

ガイドは無料でダウンロードが可能です。

本の補助ガイドというか,この資料だけでも十分に入門資料として役に立つと思いますので,これからテストを学ぼうとしている方は参照してみてはと思います。原書については約10年前の本となるので内容としてはもはや入手困難となっていますので,その代替ともなるかと思います。

本ガイドは非営利目的であれば,個人はもちろん企業内の勉強会でも利用可能ということなので,(無料ですし)是非ご活用いただくと良いと思います。

Agile Japan 2016 長崎サテライトでの講演資料を公開しました


 2016年7月30日(土)にメルカつきまち(長崎市)で開催した「Agile Japan 2016 長崎サテライト with NaITE」で講演してきましたが,公開用の講演資料が完成しましたので本日公開しました。

Agile Japan 2016 長崎サテライト with NaITE ※仮 (2016/07/30 12:00〜)
長崎でもアジャイろう! ということで,Agile Japan 2016 の長崎サテライトを開催することになりました! アジャイルに興味がある&これから始めてみようという方々に向けて鋭意検討中です! # ◆概要(検討中) 名称 : Agile Japan 2016 長崎サテライト wit...

 講演は「Are you ready? ~アジャイルプラクティスの実践と実感~」と題し,長崎サテライトのメインテーマである「スタートアップ」を意識し,興味はあるが何から手をつけたら良いかわからないとか,まさにこれからはじめるとことだ,というような方々に向けた内容としてました。

 始めに簡単にアジャイル開発についてのおさらいをし,アジャイル開発を導入するにあたって活用が必須となるアジャイルプラクティスについて,その導入のとっかかりとなる資料を紹介しました。また,いくつかのプラクティスについては初めて使ったときにどうであったかの実感を共同発表者のツノダさんにお話しいただきました。そして最後に導入前に考えておいた方がよいあれこれについて紹介しています。

 30分というとても短い時間であったため,内容はかなり絞り込んだわけですが,それでも熱心に聴講いただく姿が檀上からよく見え,感謝に堪えません。参加者のスタートアップにつながる情報が提供できていればと思います。

 Agile Japan 2016 長崎サテライト with NaITE については,公式レポートはTwitterまとめもありますので,そちらも合わせてご参照いただくと良いと思います。

Agile Japan 2016 長崎サテライト with NaITE 当日まとめ
「Agile Japan 2016 長崎サテライト with NaITE」のハッシュタグを中心に,当日の様子をまとめました。