実践ソフトウェアテスト考現学 (15) 新しいアプローチは既存の枠組みを見直すための手段

ニュース
トップ

【連載】

実践ソフトウェアテスト考現学

15 新しいアプローチは既存の枠組みを見直すための手段

湯本剛  [2009/07/29]

15/28

本連載では、Wモデルなど、テストの新しいアプローチをいくつか紹介しました。これらの特徴は「既存の枠組みを見直そうとしていること」です。今回は、各アプローチにおいて、具体的にどのような点で既存の枠組みを見直そうとしているのかを解説します。

以前、「Wモデル」や「リスクベースドテスト」「グレーボックステスト」など、テストの新しいアプローチについて紹介しましたが、これらには共通の特徴があります。それは、開発で明確に役割分担していたこれまでの枠組みを見直そうとしていることです。

「テストレベルの再構築」では、テストする順番を見直すことを提案しています。これは、教科書通りのテストだと不具合を見つけた時には手遅れで、ソフトウェアを修正するのが極めて困難になってしまっていることがあるからです。

以前、システムパフォーマンスの例を挙げましたが、例えば、「あるシステムの性能が低い」という時、ハードの増強やSQLのインデックスで改善できればいいのですが、アーキテクチャを見直す必要がある場合は、手戻りも非常に大きなものになってしまいます。テストする順番を見直すということは、この「手戻り」を最小限にするということです。

「Wモデル」では、V字モデルで言うところのバックスラッシュ側「\」=開発者の仕事、スラッシュ側「/」=テスターの仕事というプロセス的な役割分担を見直そうという意図が感じられます。役割を分担して、「ここまでは君、ここからが私」という一見合理的に思える考え方も、実はただ単に「無責任でいい範囲」を明確にしようとしているだけということがあります。これではうまくいかないので、V字のどちら側でも、開発に関わる人は皆責任があるということをモデルで表現しているのです。

「リスクベースドテスト」と「グレーボックステスト」は、網羅的なテストとピンポイントでのテストの2つのジレンマを解決し、無駄に時間をかけてテストするのではなく、優先度付けすることで現実的な落としどころを見つけるテスト分析・設計アプローチです。

リスクベースドテストは、リスク(ソフトウェアを利用する局面や欠陥が出てしまった時の修正の難しさ)をもとに優先度付けすることで、無駄にテストする範囲を抑えようとするものです。本来「利用する局面」は要件定義を担当する人たちが考えることですし、「欠陥が出てしまった時の修正の難しさ」については、設計・実装担当者が考えるべきことです。リスクベースドテストには、これらをバラバラに考えるのではなく、バランスを考慮した優先度付けが大事であるというメッセージが込められていると言えるでしょう。

グレーボックステストは、ブラックボックステストにホワイトボックステストの視点を注入することで、無駄に網羅的なテストをするのではなく、優先的にテストすべきところを明らかにしようというものです。一般的には「ブラックボックスはテスターがやるテスト」、「ホワイトボックスは開発者がやるテスト」と考えられがちですが、その考え方自体がすでに古くなっています。グレーボックステストは、誰が行うにしても両方の視点が必要であるということを示しています。

欠陥分析やテスト容易性に関しては、開発者とテスターの前向きなコミュニケーションの具体例です。

欠陥分析は、「こう設計・実装したから欠陥になった」という事実の理解につながります。「失敗から学ぶ」という言葉もあるくらいですので、欠陥の特徴や原因を理解すれば、欠陥が出ないような設計・実装にするにはどうすればよいかがわかるようになるはずです。

テストで欠陥を見つけて指摘するだけでは"粗探し"のような後ろ向きな印象で終わってしまいますが、「そもそもテストで欠陥を見つけずに済むようにしていくにはどう設計・実装すればいいのか」ということを皆で話し合うべきです。そうすれば「欠陥」も前向きなコミュニケーションツールとなることでしょう。

テスト容易性のレビューに関しても同様です。テストを効率化したいというのは皆の願いですので、冒頭で挙げた「ゴミの分別」の話のように、「この設計・実装では後で面倒なことにならないか?」という視点を入れたレビューを最初の段階で行うわけです。

その際、開発者がテストのことを知らなければテスターとの良好な関係を構築できませんし、テスターが設計・実装のことを知らなければ開発者との良好なコミュニケーションは実現できません。役割分担は大切ですが、客観的に自分たちの責務を明確化するには、隣接する領域の知見も重要だということです。

これらのアプローチは、今までのやり方の一番の問題点である「個別最適」の課題を解決する手段でもあります。

執筆者プロフィール

湯本剛 (Tsuyoshi Yumoto)
株式会社豆蔵 シニアコンサルタント。1991年に製造メーカーに就職し、原価管理、製品管理システム構築プロジェクトに参画。その後ソフトハウスにてパッケージソフト、プリンタドライバ、C/Sシステム、Webシステムなどソフトウェアテスト業務に携わる。現在は豆蔵にてソフトウェアテストのコンサルタントとして活動中。日本科学技術連盟SQiPステアリング委員、JSTQB技術委員、s-open幹事、NPO法人ソフトウェアテスト技術振興協会理事。

『出典:システム開発ジャーナル Vol.4(2008年5月発刊)
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。

15/28

インデックス

連載目次
第28回 5段階のスクリプティングレベル
第27回 キャプチャ/プレイバックツールを使いこなすためのコツ
第26回 ソフトウェアテスト自動化ツール(3)
第25回 ソフトウェアテスト自動化ツール(2)
第24回 ソフトウェアテスト自動化ツール(1)
第23回 ソフトウェアテストのトレンドをチェック! (6)テストケース生成「MBT」
第22回 ソフトウェアテストのトレンドをチェック! (5)テスト技法「HAYST法」
第21回 ソフトウェアテストのトレンドをチェック! (4)テスト技法「マインドマップの適用」
第20回 ソフトウェアテストのトレンドをチェック! (3)テストプロセス改善手法
第19回 ソフトウェアテストのトレンドをチェック! (2)方法論「STEP」
第18回 ソフトウェアテストのトレンドをチェック! (1)方法論「Agile Testing」
第17回 コーディネートした結果を合意する
第16回 開発の各役割が行うテストのコーディネート
第15回 新しいアプローチは既存の枠組みを見直すための手段
第14回 すべてのテストを自動化するのは現実的じゃない
第13回 「ゴミの分別」と「効率の悪いテスト」の関連性
第12回 テストの新たなアプローチ - 複数の視点の組み合わせ
第11回 テストの新たなアプローチ - レビュー(2)
第10回 テストの新たなアプローチ - レビュー(1)
第9回 テストの新たなアプローチ - "テストレベルの分割"と"開発者以外がテスト"
第8回 テスト戦略のパラダイムシフト - 個別最適から全体最適へ
第7回 戦略を立ててもうまく行かない時の「もどかしさ」、感じてませんか?
第6回 ソフトウェア工学に見るテスト戦略の4つの原則
第5回 開発プロジェクでの勝つための決め手となる「テスト戦略」とは?
第4回 「テストの最適化」はシステム開発成功への近道
第3回 調査だけではわからないシステム開発の実態
第2回 調査から見る日本のシステムのクオリティ
第1回 立場によって異なるテストに対する思い

もっと見る

関連したタグ

新着記事

転職ノウハウ

あなたの仕事適性診断
あなたの仕事適性診断

4つの診断で、自分の適性を見つめなおそう!

Heroes File ~挑戦者たち~
Heroes File ~挑戦者たち~

働くこと・挑戦し続けることへの思いを綴ったインタビュー

はじめての転職診断
はじめての転職診断

あなたにピッタリのアドバイスを読むことができます。

転職Q&A
転職Q&A

転職に必要な情報が収集できます

ドS美人面接官 vs モテたいエンジニア
ドS美人面接官 vs モテたいエンジニア

入室しようとしたら、マサカリ投げられちゃいました!?

特別企画

一覧

    人気記事

    一覧

    イチオシ記事

    新着記事

    JR西日本、新大阪駅13・14番のりばを南隣の3号ホームへ変更 - 来年1月から
    [08:20 12/18] 旅行
    JR東日本、拝島駅八高線ホームに昇降式ホーム柵 - 2015年3月から試験導入へ
    [08:13 12/18] 旅行
    JR東日本「ウルトラマンスタンプラリー」ウルトラヒーローグッズもらえる!
    [08:06 12/18] 旅行
    クリスマス、恋人に「壁ドン」「あごクイ」する予定のある男性は●%
    [08:00 12/18] 恋愛・結婚
    【レビュー】暗所に強い手ブレ補正機能内蔵のフルサイズミラーレス一眼が登場! - ソニー「α7 II」実写レポート
    [08:00 12/18] 家電

    特別企画

    一覧

      求人情報