『探索的テスト』を通常のブラックボックステストでなく、『動的テストツール DT10』によるグレーボックステストで実施することで、テスト対象を動かしたときのソフトウェアの実⾏経路をトレースして、ソフトウェアのシーケンスや内部構造を把握しやすくします。この⾒える化により、テストケースを削減できたり、パフォーマンス改善や不具合解析が容易になります。
『動的テストツール DT10』を活用することで、第1回目の記事で説明しました『探索的テスト』の弱みを改善し、効果的なテストの実施を考えて行きます。

 

『探索的テスト』は誰がやる？

探索に必要なスキル

『探索的テスト』はテストする⼈のスキルによっては、「アドホックテスト」になりがちで、経験と勘を持つベテランエンジニア的な⼈が実施した⽅が効果的と⾔われます。でも、これらのスキルを備える⼈は、社内やグループ内にそう多くはいないですよね。

＜探索的テストで必要なスキル＞
・テスト対象の製品の仕様、構造を理解している⼈。
・テスト技術スキルのある⼈。(⽬的別に適切なテストができる。既存テストの問題点を⾒つけられる。)
・バグが潜む可能性が⾼い弱点となる部分を探せる⼈。
・バグに対して嗅覚の優れた⼈。(バグの兆候を⾒逃さない観察⼒、バグを追い込む好奇⼼がある。)

探索でスキルを磨く

スキルを持つベテランだって、誰もが最初は若⼿エンジニアであったはず。『探索的テスト』をバグ検出だけでなく、テストのスキルアップの⼿段としても活⽤しましょう。
探索を積み重ねることで、「⾃分で考える」「気づく」といったテストの素質が養われる訳です。若⼿エンジニアであれば、『探索的テスト』をとおして、製品仕様の理解やテストケース作成の学習ができることになります。結果、アドホックテストとなっても良いので、将来のテストスキル向上のため、経験を積んでいきましょう。経験がなければ、効率の良いテストケースのアイディアは出てきません。

探索をサポートするDT10

DT10を使った『探索的グレーボックステスト』は、製品の挙動から外的な要件を理解することに合わせて、内部構造や内部仕様の理解を効率化する実⾏経路の解析結果を提供します。
コードや仕様書も眺めつつ、このテストを実施することで、製品を学習する時間が短縮できます。

関数遷移スコープを使ってソフトウェアのシーケンスを俯瞰したり、グラフをクリックすることで、ステップ単位での詳細な実⾏経路の確認ができます。

　図1　ソフトウェアのシーケンスを俯瞰できる関数遷移スコープ

また、C1カバレッジ詳細レポートの分岐構造図を活⽤することで、分岐構造で未通過の処理や分岐の複雑さなどを解析できます。

図2　関数単位の分岐構造を表示するC1カバレッジ詳細レポート

設計書が無いブラックボックス化した旧システムや先輩(他⼈)が開発した現⾏製品を『探索的グレーボックステスト』で解析し、製品仕様を理解するなど、忙しい開発業務の中でも、素早く始められて⾝になる『探索的テスト』を若⼿エンジニアの教育テーマとしても活⽤してください。DT10も併⽤して、効率良く製品の仕様を理解しつつ、テストの素質を磨いていきましょう！

 

戻れるように探索しないと後で困る

探索で見つけたバグの再現性が低い

『スクリプトテスト』のような⼿順書はないので、もしバグを⾒つけたとしても、それまでの証跡を残しにくいです。そのため、不具合症状を⾒つけても、なかなか再現できずに、バグの調査・修正が長期化してしまう場合があります。

探索に安心をもたらすDT10

第2回目の記事で紹介したマインドマップで観点や⼿順をメモしながら、『探索的テスト』を実施することで、バグ発⾒の経緯を振り返ることができようにするのも⼀つの⽅法です。
⼿順を再現するために、ある童話の兄妹がパンくずでしていたように、⽬印を残しておくといったアプローチです。
『動的テストツール DT10』を使う『探索的グレーボックステスト』においては、ソフトウェアの実⾏経路のログを残すことで、少ない⼿数でバグを修正できるようにします。これはバグ発⽣時のソフトウェアの動きに対して、同様に目印つけていくといったアプローチです。DT10でテストポイントによる実⾏経路のログを解析し、バックトレースすることで、何度も不具合を再現させる必要がなくなり、バグ修正に⾄るまでの作業時間が短縮します。深い森に迷い込まず(難解なバグに時間を掛けず)に、解決への近道を示してくれます。あの兄妹のようにお宝を見つけ金持ちになれるとは言えませんが、きっとハッピーエンドが期待できますｗ

正常時と異常時のトレース比較

２つのレポートの実⾏経路をステップ単位でトレースできるツール「DT-TREx」。ソフト修正後の再テストにおいて、修正前後のレポートデータを比較でき、ソフト修正の影響の有無や正しさを容易に確認できます。

図3　DT-TRExによる２つのテストレポートの比較

 

転んでもタダでは起きない

『探索的テスト』はテストの網羅性に欠け、品質を保証しにくい

『探索的テスト』は、事前に設計するテストケースのリストもありません。テストの漏れ、ダブり、テスト結果の網羅性は分かりにくく、テスト設計の品質が分かりにくいです。テスト結果に対する客観性、可監査性といった点も同様に弱みとなり、『探索的テスト』だけでは品質を保証することはできません。
でも、折⾓『探索的テスト』を実施したのに、バグが⾒つからなかった場合、テストしたことが意味あったのか？無駄だったのか？上司にテスト結果をどのように説明しますか？どうすれば、「⾮公式なテストに⼯数を掛けるな！」なんて⾔われないようにできるでしょうか？

非公式なテストを有意義にするDT10

『探索的グレーボックステスト』では、探索をしながらにして、その時のコードカバレッジも計測できます。C0/C1カバレッジ結果をエビデンスとして⽰すことができます。
⼀般的に、スクリプトテストとの相互補完として『探索的テスト』は活⽤されますが、もしテストケースを作る前であれば、『探索的グレーボックステスト』を実施することで、品質保証のためのスクリプトテスト作成の⼯数を削減、⼿戻りの防⽌が期待できます。少ない数の代表的なテストの実施で、どの程度までコードを網羅できたのかをカンタンに知ることができます。
膨⼤になりやすいスクリプトテストに対して、『探索的グレーボックステスト』の結果をもとに、無駄のないテストケース構築のための検討が可能となります。
既にスクリプトテストを実施済の段階であれば、テスト漏れの確認やバグ検出を『探索的グレーボックステスト』の実施で補完することで、実⾏経路の解析結果から未通過コードやデッドコードを検出したり、バグの早期解決が可能となります。

図4　未通過のステップをリスト化するC0カバレッジレポート

 

まずは個人的な品質改善活動をしてみては？

このように、『探索的グレーボックステスト』のアプローチは、『動的テストツール DT10』のテスト結果として付加される実⾏経路情報やカバレッジ結果を活⽤し、従来の『探索的テスト』の弱みを補完します。『探索的グレーボックステスト』を通して、個⼈のスキルアップや個人レベルでの身近な品質改善の方法を探索していきましょう。

いかがだったでしょうか？
3回に渡って『探索的グレーボックステスト』についてご紹介してきましたが、探索的テストを実施する場面で『動的テストツール DT10』を活用されるユーザーも増えています。
他社の取り組みや事例などの情報が集まり次第、今後もどんどん共有していきたいと思います。

ハートランド・データの動的テストツールをぜひお試しください。

無料のトライアルをご用意しています。導入もカンタン！すぐに探索を始められます。
－ 「動的テストツールDT+」の詳細はこちらから －

---

＜参考文献＞

高橋寿一「知識ゼロから学ぶソフトウェアテスト【改定版】」翔泳社
テスト技術勉強会 井芹 洋輝「探索的テスト入門」
株式会社NTTデータ 熊川 一平　「探索的テストを活用したシステム開発手法の提案」