テスターの評価は解決された障害の内容で決まる しかし,テスターが報告した障害を,テスターの判断だけで解決することはできません。実際に障害を修正するプログラマやプログラム・マネージャは,テスターが報告した障害を,再現手順や再現環境,製品の仕様やユーザーに与える影響など,様々な角度から調査します。その結果,障害報告データベースに解決方法を登録します。その解決方法はテスターに伝えられ,テスターとの間で解決内容を確認し,その障害報告は閉じられることになります。当然,テスターが同意できない場合は,対策を再度検討することになります。 そのため,テスターによる障害報告が,製品の品質向上や管理にどのような形で寄与したかは,プログラマやプログラム・マネージャによって出された解決方法によって測ることができます。 さらにテスターによって報告された障害報告は,製品品質の向上や管理に対して意味をなさなければ,その本質的な意味がありません。またテスター自身の評価は,単に報告した件数を競うだけでなく,いかに効率よく問題となる障害を的確にレポートしているかにかかってきます。そのためには,図3に示した障害報告件数の内訳をさらに細かく見ていきます。 表2は,機能別の処理済み件数の内訳です。前述した「修正済み」「重複」「仕様など」,そして「未処理」の件数も示しました。それぞれ各機能を担当するチームがあり,表2を見るとそのチームの評価が分かります。
ここでは障害報告を,プログラマとプログラム・マネージャが判断した解決方法によって分類しています。テスターが障害だと認識し,報告しても,製品の仕様を決め,実装するプログラマやプログラム・マネージャにとっては,必ずしも実装による修正が必要になるとは限りません。 この辺りは,なかなか現場での判断が難しいところで,仕様を完全に把握してテストすれば修正を要する問題を的確に指摘できるのですが,開発(実装)とほぼ同時期にテスト作業が始まる開発形態では,開発半ばでの仕様変更がしばしばあります。そのため,なかなかテスト全般を通して,テスターが常に仕様を完全に把握することは困難です。従って,テスターは「疑わしきは報告せよ」という姿勢でテストせざるを得ないのです。 テスターは障害だと認識して報告した報告でも,プログラマやプログラム・マネージャが調査した後では,その判断が変わってきます。また,テスターは基本的にコンパイル後の生成物をテストするのが役目で,ソース・コードなどを見ながらテストするわけではありません。そのため,テスターが報告した障害は実際に自分の目で確認したものなのですが,実際にソース・コードを見ながら実装しているプログラマや,製品の仕様を管理しているプログラム・マネージャはより深いレベルで判断しています(当然,仕様変更のリクエストやテスターが報告した障害をプログラマが取り違えて判断している場合など,例外はあります)。
報告した障害の分類からテスターを評価する
●修正済み 表2では,機能Aチームの処理済みに占める修正済みの割合は56.5%です。これは解決された障害のうち半分は,製品に反映されていると考えられ,機能Aを担当したチームまたはテスターは,正しい視点で効率よくテスト作業を実行しているといえます。 それに対して機能Bを担当したチームの場合は,処理済みに占める修正済みの割合が36.1%です。これは7割近くが,製品に反映されない障害報告だったことになります。このような場合には,機能Bのチームまたはテスターは,自分のテスト作業の視点が,正しいかどうか,的確に現開発段階でテストしなければならない領域をとらえているかを見直し,改善の必要があるといえます。
●重複 そのため,重複が多いテスターは,障害を報告する前にデータベースで重複の確認を怠っていると思われます。従って,そのような傾向を持つテスターに関しては,注意の徹底が必要になります。実際には何万個という障害報告のすべてを毎回チェックするわけにはいかないので,重複調査にかけられる時間との兼ね合いとなってしまいます。 表2を見ると,機能Bの障害報告件数は機能Aを上回りますが,重複数が機能Aの2倍になっています。さらに,修正済みの割合と重複の割合を比べるとほぼ同じになっています。この点から,機能Bチームが報告した障害の2つに1つが重複しているものだったと考えられます。この場合,機能Bチームは,重複した障害を報告したことによって,本来見つけるべき障害を見つけるための労力と時間をムダに費やしてしまったと考えられます。テスト作業自体の改善が必要です。
●仕様など ただ,中には単なる不注意が原因の場合だけではなく,実際に開発期には最終判断が下されるまで仕様が決まらないことがあるため,一度仕様などとされた障害報告が各チームでの議論を通じて仕様変更を導き,最終的には修正を要する障害に変わることも,まれにあります。その間の議論は長々と続く場合があります。 また,障害と思われる問題が,仕様書などを調べても明らかになっていないことがあります。実装とテスト作業がほぼ同時に進行している私たちの開発モデルでは,たまに見られるケースです。その場合テスターは,その問題が障害なのか仕様なのかの判断を,プログラム・マネージャやプログラマなどに求めることもあります。このようなとき,テスターは意図的に,その問題を障害報告データベースに登録します。 機能BとCのようにこれに分類された障害が多い場合,テスターはテスト作業でムダを生じていることになります。その場合,テスターはテスト作業自体を見直す必要があります。
障害を深刻度によって分類する 私たちの現場では,深刻度に対して以下のような認識を持っています。 ・深刻度1:最も深刻で,その障害が起きると,その機能自体の実行が妨げられる恐れがあるものです。つまり,その障害によってそれ以降の機能操作が不可能になるものです。具体的には,アプリケーションのクラッシュや,ユーザー・データを喪失する障害などが深刻度1になります。 ・深刻度2:深刻度1のように機能自体が遮断されることはありませんが,ユーザーの操作に不都合を与える障害です。この種の障害は回避策が存在しますが,その回避策自体もユーザーの操作に不都合を強いるものになります。 ・深刻度3,4:軽度の障害です。例えば,ダイアログ・ボックスの文字が,読解可能だが,厳密に見れば欠けている場合や,機能は全く問題ないが,コントロールの成形やダイアログ上のコントロールの配置が整っていないなどです。深刻度3,4の障害は,ユーザーがアプリケーションを操作するうえでは何も影響を与えない障害です。 表3は機能A~Dの全ての障害報告件数を,深刻度別に表したものです。この数値は,「修正済み」もあれば,「重複」「仕様など」と分類されたもの,あるいは「未処理」「繰り越し」と,すべての項目に分布しています。
報告した障害の深刻度からテスターを評価する 深刻度の高い障害は,その度数が高ければ高いほど,プログラマやプログラム・マネージャが実装または仕様を計画するときに,懸念される障害です。そのため,製品開発の極めて初期の段階では多く存在するかもしれませんが,製品の品質が固まってきている開発後期にはあまり出現しない傾向にあります(そもそも,品質が安定してくる開発後期にそのような深刻度の高い障害が多数ある場合,テスターだけではなくプログラマまたは仕様を管理するプログラム・マネージャの作業自体にも疑問が生じます)。従って,この場合は,機能Bのテスト作業は効率よく実行されているといえます。 この深刻度別による評価は,単なる障害報告の数だけではなく,各テスターが各開発段階で,深刻度の高い障害をどの程度見つけているかを調べられます。また,深刻度の高い障害は製品の出荷時点では必ず解決していなければならないものなので,その製品の管理や品質向上に対する貢献度も測ることができます。
終わりに また,テストという作業は単純ではなく,テスターには障害の発見以外にも様々な要素が要求されるものだと思いました。皆さんの現場ではどうでしょうか。3回にわたったテスト・チームの話も今回が最後になりました。Visual Studioの開発チームの中でもあまり表に出る機会が少ないといわれているテスト・チームが,皆さんにはどう写ったでしょうか。 次回はVisual Studio開発チームのプログラム・マネージャ(PM)が担当し,Visual Studioの開発プロジェクト全体を管理して製品リリースにこぎ付けるための「プロジェクト・ライフサイクルとグループ・マネージメントの実際」について説明する予定です。 |
Visual Studioの開発現場から(第4回)p3
あなたにお薦め
今日のピックアップ
-
ずさんな安全管理が露呈したLINEヤフー、総務省が注視するNAVERとの「支配関係」
-
AIが社長に? 分身が欲しい中小企業社長の切実な願いを実現するサービス
-
フェイク排除にプラットフォームの対策が必要、リテラシーだけでは防ぎきれない
-
GUIプログラミングやバイトコード、一歩進んだPythonの使い方を知ろう
-
好きなジャンルの曲をボーカル入りで作成、話題の作曲生成AI「Suno」がすごかった
-
6万円台で勝負に出るZTE、安価な「折り畳みスマホ」は日本で普及するか
-
PCやスマホが激遅なのには理由がある、余計な処理を止める方法
-
個人情報保護委員会がLINEヤフーに行政指導、個人データ52万件流出受け
-
日本IBMが金融向けに生成AIを「拡張」、MicrosoftやAWSのサービスも選択可能
-
医療機関に4つの生成AI、業務負荷を軽減し研究用データベースの充実へ
-
関係者多数の改革プロジェクトでもめる、食い違う意見を擦り合わせる対処法は
-
SNSなど多様な公開情報を解析、セキュリティー対策に生かす「OSINT」とは
注目記事
おすすめのセミナー
-
「仮説立案」実践講座
例えば「必要な人材育成ができていない」といった課題に、あなたならどう取り組みますか? このセミナ...
-
CIO養成講座 【第35期】
業種を問わず活用できる内容、また、幅広い年代・様々なキャリアを持つ男女ビジネスパーソンが参加し、...
-
改革リーダーのコミュニケーション術
プロジェクトを成功に導くために改革リーダーが持つべき3つのコミュニケーションスキル—「伝える」「...
-
パワポ資料が見違える「ビジネス図解」4つのセオリー
インフォグラフィックスとは、形のない情報やデータなど伝えたいことを分かりやすい形で表現する技法で...
-
オンライン版「なぜなぜ分析」演習付きセミナー実践編
このセミナーでは「抜け・漏れ」と「論理的飛躍」の無い再発防止策を推進できる現場に必須の人材を育成...
-
問題解決のためのデータ分析活用入門
例えば「必要な人材育成ができていない」といった課題に、あなたならどう取り組みますか? このセミナ...
-
業務改革プロジェクトリーダー養成講座【第16期】
3日間の集中講義とワークショップで、事務改善と業務改革に必要な知識と手法が実践で即使えるノウハウ...
-
ITリーダー養成180日実践塾 【第14期】
8回のセミナーでリーダーに求められる“コアスキル”を身につけ、180日間に渡り、講師のサポートの...
注目のイベント
-
若手の離職防止につながる、マネジメント・チームづくりのポイント
2024 年 4 月 10 日(水) 10:00~12:30
-
ITモダナイゼーションSummit2024
2024年4月10日(水)、11日(木)12:45~17:50
-
【4月11日】最新HCIの特徴やメリットを学ぶ、参加者にはもれなくプレゼント進呈
2024年4月11日(木)
-
「ニッポンの未来図」――テクノロジーアップデート2024
2024年4月16日(火)14:00~15:00
-
【4月17日】AI活用につなげるIT基盤・組織・運用とは? 鍵は「Edge to Cloud」
2024年4月17日 (水)
-
【4月19日】データの活用と保護を両立、「段階的なDX」を実現するIT基盤とは?
2024年 4月 19日 14:00
-
【4月25日】ハイパーバイザーの基本を学ぶ、参加者にはもれなくプレゼント進呈
2024年4月25日(木)
-
日経クロステックNEXT 関西 2024
2024年5月16日(木)~5月17日(金)
-
人手不足を乗り越える 日本の産業界成長のシナリオ
2024年5月30日(木)開催予定
-
キャリア・オーナーシップが社会を変える
2024年6月3日(月)~6月5日(水)
おすすめの書籍
-
ソフトバンク もう一つの顔 成長をけん引する課題解決のプロ集団
ソフトバンクにはモバイルキャリア事業以外のもう一つの顔が存在する。本書ではキーパーソンへのインタ...
-
対立・抵抗を解消し合意に導く 改革リーダーのコミュニケーション術
本書は、改革リーダーに必須のコミュニケーション術を3つのスキルの観点からまとめ上げたものです。今...
-
もっと絞れる AWSコスト超削減術
本書ではコスト課題を解決するため、AWSコストを最適化し、テクニックによって削減する具体策を紹介...
-
優秀な人材が求める3つのこと 退職を前提とした組織運営と人材マネジメント
「学生に人気のコンサルであっても、大手企業であっても、せっかく獲得した人材が数年で辞めてしまう...
-
Web3の未解決問題
ブロックチェーン技術を主軸とするWeb3の技術について、現在の社会制度との摩擦と、その先にある新...
-
ロボット未来予測2033
ロボットの用途・市場はどう拡大していくのか。AI実装でロボットはどこまで進化するのか。技術の進展...
日経BOOKプラスの新着記事
日経クロステック Special
What's New
経営
- ジェイテクトエレクトロニクスのDX事例
- NTTドコモ支援の実践型教育プログラム
- DXを成功に導くITインフラとは?
- NTTデータに優秀なデジタル人財が集まる理由
- 地域創生で重要になる「事業化」の視点とは
- ERPプロジェクト≫IT人財の必須条件は
- 先進都市対談>生成AIは行政DXの切札?
- 多様化する地域の課題解決に向けて議論
- 地域×テクノロジーでミライを共創する
- 脱レガシー案件≫SIerに必要な人財像は
- 役所文化の変革!奈良市のデジタル市役所
- 3段階で考える、DXで企業力を高める方法
- イノベーションの起爆剤
- 東芝が描くDXの道筋とその先の未来とは
- 石戸氏に聞く。生成AIを教育で使うには
- 次世代技術をもっとリアルに体感したいなら
- 大規模プロジェクトでPMが注意すべき点は
- ファンケルの躍進を支えたMAの徹底活用術
- 経営戦略と連動したシステムのあるべき姿
- 大阪・名古屋エリアのDXが注目される理由
- 力点は「未来予測」へ:データ利活用の勘所
- 生成AI活用でSAP BTPの価値が進化
- ServiceNowでDXを加速≫方法は