関西Presentsテスト采配ワークショップ～ええあんばいに、あんじょうやりましょ！～本日の進め方・はじめに・前準備（テスト観点抽出）・評価基準での優先度付けについて
・状況変化への対応について（状況分析と柔軟な対応）

コンテンツ作成：JaSST Kansai実行委員会
発表：角口勝隆、亀井浩気、新美崇宏
２０１１／１／２５

・まとめ2

はじめに

制約：プロジェクトを進めて行く上での障害

 ソフトウェア開発では、急な仕様変更や、納期短縮、人員や資源の不足、前工程の遅れ、デモ展示対応などの制約により、プロジェクトが失敗に陥ることがある。
 いわゆるQCD(品質・コスト・納期)を計画通りに満たしたプロジェクトの成功率は、３１．１%と言われている。
(日経コンピュータ2008年12月1日号より)
 比喩的に「３Ｋ」といわれるIT業界において、どのような状況下でも最低限の成功を納めるために、当ワークショップ
では、現場で必要となるスキルの一つである「状況分析力」に触れて頂くことを目的としている。

 制約は大きく２つに分類される
 事前に事前に対策可能な対策可能な制約
可能な限り、事前に抽出し、対策を行っておく。
 随時対策が随時対策が必要な必要な制約ノウハウを溜めておき、制約が発生した際に、柔軟に対応する。

3采配とはhttp://www.jasst.jp/archives/jasst10w/pdf/A2-2.pdf

4

最適な采配を行うには

 采配 →目的を達するための指揮「状況分析」
状況分析」が必要。

①紙の幣(しで)の一種。昔、戦場で大将が手に持ち、士卒を指揮するために振った道具。厚紙を細 長く切って作った総(ふさ)を木や竹の柄につけたもの。色は白・朱・金・銀など。
②指図。指揮。「―をとる」③ 《形が①に似ているところから》はたき。ちりはらい。

現状＋制
約追加

采配

⇒状況はどう変化した？

その場で判断判断をして、指示指示を与える
判断
指示
5⇒今回は、優先順位を用いた状況分析について体験頂きます。

6

本日の進め方

おさらい1：テスト観点の大切さ

・はじめに・前準備（テスト観点抽出）

 例えば、突然ですが「セブンイレブンのセブンイレブンのロゴをロゴを書いてください」
いてください」と、依頼した場合、どのようになるでしょうか？
 Ｓｅｖｅｎ Ｅｌｅｖｅｎ？

・評価基準での優先度付けについて・状況変化への対応について（状況分析と柔軟な対応）

 ＳＥＶＥＮ ＥＬＥＶＥＮ？
 ７-ＥＬＥＶＥＮ？

 これまで、何度も目にしてきたのに、いざとなると思い出せません。

・まとめ
7

8

おさらい2：テスト観点を出すにはテスト観点＝ねらいどころ 答えは、

 多角的に、テスト対象テスト対象を対象を分析することが重要。
最後が「ｎ」で小文字であることに、気付いてましたか？

要求書・仕様書類
テストスキルアプリケーションの知識
ユーザの視点エラー事例

 観点：「大文字、小文字の違いに注意すること」

技術的な知識分析

最適なツールの適用と応用方法

各種チェックリスト

重要：観点があれば、気付きやすい。
観点が無ければ、見えているのに、気付かない。
つまり、見逃しやすい。

品質特性
9

市場のトレンド
テスト計画
・テスト観点(着眼点)・適用ツール/手法

法規・規則

あなたの適正をチェック！

あなたの適正をチェック！

 手元の用紙に、縦に４つの折り目をつける。
 １番下の枠に、大きく氏名を記入。
 １番上の枠に、以下の質問の青・さわやか
・Cool
答えを記入。
・派手ではない ２番目の番目の枠に、以下の質問の答えを記入。

10

あなたの好きな動物を１つあげて下さい。
動物をあらわす
その動物
動物をあらわすイメージをあらわすイメージを３つあげて下さい。
イメージ
例：ゾウ「ゾウ「大きい」「きい」「瞳」「瞳が優しい」「しい」「動」「動じない」
じない」

あなたが好きな色を１つあげて下さい。
色をあらわす言葉
その色をあらわす言葉の言葉のイメージを３つあげて下さい。
メージ
例：青色「」「派手青色「さわやか」「さわやか」「Cool」「」「」「派手ではない
派手ではない」ではない」

 ３番目の番目の枠に、以下の質問の答えを記入。
通路の向こうから、誰かが歩いてきます。
その人は、何歳何歳ぐらいの何歳ぐらいの人ぐらいの人でしょうか？
※：あまり悩あまり悩まず、まず、直感的に直感的に答えてくださいね1112

それでは、グループをつくりましょう！

適正チェックの回答

 座席の、前から奇数番目奇数番目の奇数番目の方。
 後ろを向ろを向いて、いて、偶数番目の偶数番目の席の方と、ペアになってください。
ペア

 ゴメンナサイ！
 ここは、ワークショップ当日のみ公開です。
 どうしても知りたい方は、

 テーブル単位
テーブル単位で単位で、グループになってください。

kansai-query@jasst.jp までお問い合わせください。

 自己紹介の後、先ほどの適正チェックでの共通点について、グループ内グループ内で似たような人たような人を探してみてください。

 一番多い一番多い共通点が共通点が、グループ名グループ名になります。

紙は、ネームプレートとして、リユースしましょう！

例：青いゾウさん
ゾウさんチームさんチーム
13

あなたの立場 あなたは、社内の有識者を集めた検証チーム
検証チームにチームに所属します。
所属 あなたの所属するXXXX電子では、ハードハードウェア（ウェア（センサー）センサー）の開発力に開発力に定評はあるも定評のの、ソフトウェア開発技術が未熟。
 ライバル企業（他グループ）との差別化をハードウェア（図るため、ハードウェアハードウェア（センサー）センサー）を活かした機能
した機能を機能を、ソフトウェア開発
ソフトウェア開発により開発により実現により実現し実現たい。

14

開発する製品の、プロジェクト概要

XXXX電子XXXX電子├経営層├経営層├企画チーム├企画チーム├ハード開発チーム├ハード開発チーム├ソフト開発チーム├ソフト開発チーム├検証チーム：├検証チーム：
製品の出荷判定に製品の出荷判定に強い権限を持つ
強い権限を持つ（出荷停止の権限を持つ）（出荷停止の権限を持つ）

 ある健康管理腕時計
健康管理腕時計の「健康管理腕時計 「春モデル」モデル」を開発します。
 プロジェクト要件は以下のとおりです。
 開発期間は６カ月。(テスト実施期間は２カ月)
 必要な予算は必ず出るが、追加申請はNG。

 ライバル企業に打ち勝つために、低価格・低価格・高機能・高機能・高品質の高品質の達成が達成が必須。
必須
 まずは、デザインレビュー
デザインレビューのデザインレビューの前に、テスト計画テスト計画を計画を作成するところから、ストーリ作成ーは始まります。
15

健康管理時計の機能

16２０～
２０～３０代前半
３０代前半の代前半の社会人ががターゲット。
社会人ターゲット。

開発する「健康管理機能」について
 健康管理機能の要件は以下の通りです。

１．時計表示 現在の年月日、時分秒を表示する
時刻や、個人情報(年齢、身長、体２．設定重)の設定が可能
３．通知

カロリー消費計
カロリー消費計
入力 加速度センサーで運動量

体温計
温度センサで体温を計測

を計測

時報や、アラームを鳴らす

表示 毎日の消費カロリーを表示 ボタン操作で、体温を表示

４．健康（次のページに、詳細を記載します）
管理機能

通知 一日の目標クリアでファンファーレ♪

：

体調不良時にアラーム通知細かい機能や仕様は、グループで自由に追加してください
1718ここまでの準備、OK？

分析の視点について

 プロジェクト要件や、開発する機能は理解できましたか？

 分析には、段階に応じて以下４つの視点（ビュー）があります 仕様ビュー
仕様ビューをビューを「品質特性」品質特性」で、設計・設計・実装ビュー
実装ビューをビューを「セオリーパターン」セオリーパターン」で検討してみましょう。

 それでは、テスト計画作成にあたり、テスト観点を検討しましょう。

ユーザービュー

要求分析

適格性確認テスト
仕様ビュー

方式設計

結合・機能テスト
設計・実装ビュー

詳細設計

バグビュー

実装

単体試験（部品など）
実装確認

20

品質特性とは？

品質特性での検討例

 「品質特性」とは、品質を構成する要素（特性）。
 「ISO/IEC９１２６ 品質特性」の概要を紹介します。

「要求機能」と、「品質特性」を照らし合わせて、「ねらいどころ」を検討する目的に合っているか？
実用に耐えるか？

１．時計

OL２５歳の場合

機能性要求に対する仕様の正しさ、および仕様に対するプログラムの正しさ

信頼性

機能が正常に動作し続けられるかどうか

使用性

使いやすさ、わかりやすさ

効率性

目標時間内で、決められたことを実現・処理できるか

保守性

障害解析（故障時の原因のわかりやすさ）、修正、テストのしやすさ

移植性

他の環境への移しやすさ、応用性の高さ

現在の年月日、時分秒を表示する

機能性

アウトドア派の場合：：何年先まで表示可能？

ピッタリ合うことボタンで、時刻の調整が可能
時報や、アラームを鳴らす

信頼性
長年の利
正確で用に耐えうあるか？
どこまで正 るか？
確であるべきか？

・オフィス内でもうるさくない・アウトドアでも音が聞こえる

条件通りに動作すること不明点は、デザ

インレビューなどで事前に確認／指摘する
22

21

セオリーパターン早覚え

テストのセオリーパターンとは？

同値分割「左手の法則」

 テスト設計で、よく使われる発想観点をパターン化したもの。
正常系「願望」や「制約」など、通常利用する上での要求・要件を検討する

異常系

そうではないケース、誤操作の結果など、エラー発生時の動作を検討する。
（数値にNullなど）

境界系「不具合は境界値に潜む」という格言があるように、ゼロの値、プラスマイナス１の値での動作を検討する

限界系

どこまで耐えられるのか？どこまでの値を保証するのか？極限状態を検討する。（下限についても検討する）
初期状態から、イベント(ボタンONなど)による結果を、一連の流れで整理／検討する。

状態遷移
組合せ

複数の機能や状態の組合せを検討する。（表形式にすると、組合せの漏れや検討不足を見つけやすい）23

ペンをペンを持ちながら、ちながら、片手で片手で思い浮かべる
中指：中指：正常系、正常系、願望など願望など
親指：
親指：異常系、異常系、そうでないケース
そうでないケース
人差し
人差し指：境界/境界/限界条件

byかどやん演習1（１５分）

演習1:観点抽出演習のルール

健康管理腕時計の健康管理腕時計の仕様から仕様から、テスト観点からを抽出してください。

 テスト観点は、確認すべき「ねらいどころ」。
 グループ内で、一人一人１一人１つ以上は以上は出すこと。
 出した観点は、批判批判・否定しないしないこと。
批判・否定しない 奇抜なアイデアや、気付きは歓迎すること。
 観点は、「～「～であることであること」付箋紙へ「～であること」と、付箋紙付箋紙へ書き出すこと。
 仕様の不明点は、後で確認できるように記録すること。

演習内容「品質特性」
・「品質特性」と「セオリーパターン」
セオリーパターン」を用いてテスト
いてテスト観点テスト観点を観点を抽出する。
する。
・抽出したテスト観点は付箋に付箋に記入し、ワークシート1の対応するマスに貼っていく。

時間は１５分です。
それでは、よーい スタート！！
26

タイミングのタイミングの視点が視点が、Good（参考事例紹介）
他所のワークショップの成果物から、「これイイこれイイねイイね！」という事例を紹介します。

タイミングの視点は、Goodですね！
タイミングの視点は、Goodですね！
発生するイベントと、「競合・排他」の観発生するイベントと、「競合・排他」の観点を頭に入れておくと、不良の作りこ点を頭に入れておくと、不良の作りこみ防止にも効果があると思います。
み防止にも効果があると思います。
経験的に、こういうところでの盲点(検経験的に、こういうところでの盲点(検討不十分)や、BUGが多いですね。
討不十分)や、BUGが多いですね。

（プロジェクターに映します）

28

27

モレなく
モレなく、なく、ダブリなく
ダブリなく

テスト観点のワンポイント

品質特性に従い、モレなく！

要求機能は、ダブりなく！

無駄な重複なく、書き出せたところが、Goodです！
無駄な重複なく、書き出せたところが、Goodです！
ワークシートの列を「もれなく」、行を「ダブりなく」観点を抽出
ワークシートの列を「もれなく」、行を「ダブりなく」観点を抽出/整理することが大事。
/整理することが大事。
「この観点は、どの品質特性に分類されるのか？」という議「この観点は、どの品質特性に分類されるのか？」という議論はこの時点では不毛。まずは、書き出す！
論はこの時点では不毛。まずは、書き出す！
29

 基本は「「モレなくモレなく」「なく」「ダブリ」「ダブリなくダブリなく」なく」 視野・視野・視点を視点を変えて、検討しましょう
えて※犬です 似たようなものはグループたようなものはグループ化
グループ化や階層化しましょう
階層化 あまり多すぎず、細かすぎないこと
 ある程度
ある程度「程度「抽象化」抽象化」が必要
 「抽象化」とは、本質を抜き出すこと あいまいな部分が、明確であること
・あいまい
あいまい部分
あいまい部分は部分は記録した上で、後で明確化する
記録
30

中締め

本日の進め方テストのをテストの観点(テスト観点 テストのテストの狙い所)を予め検討する
検討する利点する利点
1. テスト設計
テスト設計の設計の充実
2. デザインレビューのデザインレビューの充実
3. 作業量見積もりの作業量見積もりの精度向上
もりの精度向上・はじめに・前準備（テスト観点抽出）・評価基準での優先度付けについて・状況変化への対応について（状況分析と柔軟な対応）
・まとめ
32

31

本ワークショップの目的

たくさんテスト
たくさんテスト観点
テスト観点がある
観点がある中がある中での気付での気付き
気付き

期間・コストが限られている中で、商品としての価値および製品品質を確保する采配を行うための「状況分析」方法を体験する。

• 「何からする？」「からする？」「どれからやればいいの？」「どれからやればいいの？」
どれからやればいいの？」→テストスキルがテストスキルが高いテスト担当者
テスト担当者は担当者は、テストのテストの実施順番が重要である意識している。
している。
重要である事である事を意識している• 「このテスト
このテスト観点
テスト観点は観点は必要なの必要なの？」
なの？」→テストスキルがテストスキルが高いテスト担当者
テスト担当者は担当者は、テスト観点テスト観点に観点に重要なも重要なものとそうでないものがある事意識している。
している。のとそうでないものがある事を意識している
34

つまり…
 抽出した段階では、テスト観点は優先順位付けされていない。
3

47614512736
ユーザーの製品品質に対する認
識領域

品質リスク(値が大きさを表す)

 品質リスクの大きなテスト観点から実施することにより、効率的に効率的にテストをテストを進められる。
不具合による工程への工程へのダメージへのダメージをダメージをコントロールできる。
実施順番
776654例）影響の大きい部分を優先

4

33

2

1

品質と品質リスク、テストの関係

テスト領域※今回のワークショップ前半で抽出したテスト観点から作成する。

1

途中段階でのリリース基準36

十分なテスト

不完全なテスト

ユーザーの製品品質に対する認識領域を全てテストした。

ユーザーの認識する製品品質領域を全てテストできていない。

ユーザーの製品品質に対する認識領域

テスト領域⊃品質リスク⊄

テスト領域

ユーザーの製品品質に対する認識領域

37

リスクに基づいたテスト

38

優先順位を決める方法の満たすべき条件

不具合による工程へのダメージをコントロールするために、重要なな部分から重要部分からテストからテストする。
テスト

「定量的」な基準を用いた方法であること
品質リスク

「広い視野に立った」方法であること

ユーザーの製品品質に対する認識領域⊃テスト領域3940

広い視野に立つとは…

定量的とは…
 定量的とは、対象の量的な側面に着目することであり、再現性があり、理論的に説明する事が出来る。
 当たり前品質を優先するか、魅力的品質を突き詰めるか、どのような観点でテスト項目の優先度を決めるにしても、

 例えば、えば、誰が重要な重要なテスト観点テスト観点と観点と判断するか判断するか？
するか？

 ユーザー：顧客の顧客の要求は要求は絶対。
絶対。
→利用者の利用者の要求分析から要求分析から、から、機能に機能に対する優先度する優先度を優先度を把握。
把握。

 プロジェクト：作るからには、るからには、魅力ある魅力ある製品ある製品を製品を作りたい。
りたい。
→この製品
この製品の製品のアピールポイントはここだ
アピールポイントはここだ！
はここだ！

関係者の関係者の意識あわせをするため意識あわせをするためには定量的な定量的な値であるべき。

 開発者：設計・設計・実装上、実装上、心配な心配な部分が部分が出てくる。。。てくる。。。
→この部分
この部分は部分は、バグのバグの影響が影響が大きいかも・・・
きいかも・・・→この部分
この部分は部分は、複雑だし複雑だしバグだしバグがあるかもバグがあるかも・・・があるかも・・・

 定性的であると、直感や個人的印象によるため、信頼性や信頼性や客観性に客観性に乏しいと判断されることが多い。
41

 プロダクト：商品の商品の性質上、性質上、この部分
この部分は部分は重要→ユーザにユーザに危害を危害を加える可能性える可能性あり可能性あり。
あり。

42

今回のワークショップでは“評価軸“に注目

Rick D.Craigらによる評価軸
ソフトウェアのリスク分析プロセスの概要①

BSチームを結成する⑤ 数値を割り当てる⑨ 「足切り線」を設定する「評価軸(評価基準)」を取り上げていきます。

②

機能の一覧を作成する⑥

リスク度を算出する軽減策を検⑩ 討する

次に示すのは、Rick D.Craigらの著書「体系的ソフトウェアテスト入門」に記載されているリスク分析を流用した方法です。

③

障害の可能性を判定

値をレビュー⑦ ／修正する④ 障害の影響を判定

機能に優先⑧ 度を付ける

今回のワークショップでは、優先順位優先順位を優先順位を決定する
決定する
方法として方法として、リスクベースドテストで使用される、としてリスクを優先順位を決定しています。
この方法では、リスクリスクを元に優先順位を決定
43

Rick D.Craigらによる評価軸

Rick D.Craigらによる評価軸

ソフトウェアのリスク分析プロセスの概要①

BSチームを結成する

ワークショップ
前半の内容
テスト観点の②

一覧を作成する⑤ 数値を割り当てる

ソフトウェアのリスク分析プロセスの概要：
テスト観点をテストしなかったことによるテストしなかったことによる「障害の可能性」と「障害の影響」の2つの評価軸で点数付けを行い、この点数よりリスク度を算出し、テスト優先度を決定する。

⑨ 「足切り線」
を設定する⑥

リスク度を算出する

44

軽減策を検⑩ 討する

値をレビュー
障害の可能
ワークショップ⑦ ／修正する
性を判定
後半の内容
⑧
テスト観点に④ 障害の影響を判定
優先度を付ける

高い場合③中程度の場合
低い場合
45

演習２（１５分）
提示した評価軸を用いて、テスト観点の優先順位を決めてください。
演習内容
付箋を
貼
・テスト観点は、付箋付箋をワークシート1からワークシート からワークシート２へ貼からり直して使用してください。
・テスト観点を、提示した評価軸（障害の可能性、障害の影優先順位を響）で評価し、優先順位優先順位を検討してください。
検討時間は１５分です。
それでは、よーい スタート！！

障害の障害の可能性 障害の障害の影響

３２
１

３
２
１

リスク度 = (障害の可能性) ＋ (障害の影響)

46

解答欄
テスト観点
テスト観点 障害の障害の可能性 障害の障害の影響 リスク度
リスク度 優先順位

付箋紙に書いた観点を、貼り直し。

※リスク度 = (障害の可能性) ＋ (障害の影響)

１～３

１～３48

優先順位の確認

本日の進め方 予想通りの優先順位となっていますか？

・はじめに・前準備（テスト観点抽出）

 これでテスト計画ができました。

・評価基準での優先度付けについて
・状況変化への対応について（状況分析と柔軟な対応）
・まとめ
49

50

ワークショップでの制約テストを進めるうちに・・・ 腕時計開発プロジェクトに対して、経営層から

 「テスト観点テスト観点、観点、たくさん出たくさん出しました。」
しました。」
 「あれもこれもテスト
あれもこれもテストしたいですね
テストしたいですね～」
したいですね～」 「開発側開発側、ここまで考えてるかな？」、ここまで考えてるかな？」• 実際には実際にはハードウェアにはハードウェアやハードウェアやドライバ周ドライバ周りなどの開発りなどの開発の遅れがあったりという“制約”が発生する発生するれがあったりという“制約”• このような場合プロジェクトの進行が進行がこのような場合においても場合においても、においても、プロジェクトの滞らないように状況必要となる
らないように状況に状況に合わせた采配
わせた采配が采配が必要となる

次のような要望があった。
 「２週間後の展示会に出して、マーケティングを有利に進めたい。」
 動くものを出さなければならない！
テスト開始後２週間で展示会へ出す。
期間が厳しい・・・
52

51

プロジェクトの現状と対応策

最適な采配を行うには 現状：「状況分析」状況分析」が必要。
現状＋制
約追加

采配

 制約： 「マーケティングを有利にする機能を優先。」という要望⇒状況はどう変化した？
⇒今回は、優先順位を用いた状況分析について体験頂きます。

・開発状況を把握すると、一部ハード/ソフトについて、残り2週間では、完全な動作が難しいと判明した。
・この展示会バージョンのための追加予算はなし。

 対応策：「機能限定展示会バージョン」を途中リリースすることになった→限定される機能はあって良いとする。
53

54

テストの現状と対応策

品質とテストの関係で表現すると・・・

 現状：

テスト領域を、減らさざるを得ない・テストは既に開始されている。
・この展示会バージョンのための追加予算はなし。

顧客の製品品質に対する認識領域

 制約： 「機能限定展示会バージョン」を途中リリースする→日常的に利用する視点で検討した、先ほどの優先順位では、展示会には間に合わない。

テスト領域
マーケット性の高い機能が重要と判断されている。

 対応策：
先にテストすべき観点と、後回しにできる観点の再検討
55

56

前回評価時からの変化点

品質とテストの関係(理想の対応)
重要部分にポイントを絞る！

顧客の製品品質に対する認識領域

日常的に利用する上で、何に障害があるとリスクが高いと言えるか？

テスト領域
ユーザーが特に重要部分は重点的に！
魅力的だとする領域

展示会で利用する上で、何に障害があるとリスクが高いと言えるか？
57

58

日常利用と展示会の状況の違い

演習３（１０分）

展示会では、専門のオペレータが全てを操機能限定展示会バージョンのための、テスト観点の優先順位を再度決定する。

作する つまり、操作の指定や教育が可能

展示会では、動作する時間が限られている
 つまり、日付をまたいだり、長時間の稼動は不要
59

演習内容
・リスクを再評価して、テスト観点の優先順位を決定する。

時間は１０分です。
それでは、よーい スタート！！

60

解答欄

優先順位の確認

テスト観点
テスト観点 障害の障害の可能性 障害の障害の影響 リスク度
リスク度 優先順位

 予想通りの優先順位となっていますか？
 展示会で使える状態になりそうでしょうか？

状況に合わせて優先順位を再検討※リスク度 = (障害の可能性) ＋ (障害の影響)
62

61

優先順位：的確な状況判断（参考事例紹介）
他所のワークショップの成果物から、「これイイこれイイねイイね！」という事例を紹介します。
（プロジェクターに映します）

63

優先順位：その根拠について

演習３では、展示会向けの機能を優先しました。
演習３では、展示会向けの機能を優先しました。
また、優先度を数値化することで、定量的な判断を関
また、優先度を数値化することで、定量的な判断を関連者にも示す事が可能です。
連者にも示す事が可能です。
※的確に状況を判断し、采配しましょう！
※的確に状況を判断し、采配しましょう！

「優先順位付け」のワンポイント
 定量的であること
 具体的な具体的な数値となっていること
数値
 視野を視野を広げて検討げて検討していること検討「体温の誤差は0.1℃以内であること」と、精度に関するテスト「体温の誤差は0.1℃以内であること」と、精度に関するテストの優先順位を高く設定されていました。の優先順位を高く設定されていました。
コンセプトを高精度であるコンセプト
コンセプト
グループ共有高精度であるコンセプト
コンセプトを
をグループ内グループ内内でで共有されており、共有されており、コンセプトをグループ内共有
うまく合意
うまく合意
できていた
うまく合意
合意できていたできていた点がGoodですね！
うまく合意できていた
合意できていた点がGoodですね！
できていた

発注元、プロマネ、開発者、、、
 複数人で、妥当性を確認していること
 思い込みや、みや、思考の思考の偏りがないこと
りがない※優先順位の根拠を明確にしておくと、現場で展開する際に※優先順位の根拠を明確にしておくと、現場で展開する際により良いのではないかと、経験的に考えています。
より良いのではないかと、経験的に考えています。
6566

本日の進め方

ワークショップの流れ

・はじめに・前準備（テスト観点抽出）

テスト観点
テスト観点の観点の抽出・品質特性・セオリーパターン

テスト観点
テスト観点の観点の優先順位のの決定
優先順位

・ Rick D.Craigの評価軸による優先順位付け

・評価基準での優先度付けについて
・状況変化への対応について（状況分析と柔軟な対応）

制約

・まとめ

テスト観点
テスト観点の観点の優先順位の順位の再決定

・ 状況に合わせて再度優先順位付けし采配した。

67

68

ワークショップのまとめ

ありがとうございました 製品開発では様々な制約がある。その中で、商 会場設営／運営にあたられました方、企画検討～準備にあたられました方、そして、、、参加いただいた皆さま、全てに感謝致します。

優先順位の品的価値を確保するためには、優先順位優先順位の高いテスト観点
テスト観点からから実施実施するする必要必要がある。
観点から実施する必要 今回のワークショップでは、、状況に状況に応じたテスト
じたテスト
評価軸を観点の状況分析)を、評価軸
評価軸観点の優先順位付け
優先順位付け(状況分析
状況分析用いて行った。
 的確な最善の的確な状況分析が、最善状況分析
最善の一手、一手、そして最善そして最善の采配につながる采配につながると考える。につながる

本日の資料で質問があれば、kansai-query@jasst.jp までお願いします。
70

69

スペシャルサンクス

参考文献１

 JaSST Kansai実行委員（順不同、敬称略）
 森崎 修司 (奈良先端科学技術大学院大学）
 武田 学 (JaSST Kansai 実行委員会）
 浅尾 義則 （アイエス情報システム） 宇井 宏樹 （JaSST Kansai 実行委員会）
 小川 哲生 （JSOL) 加澤 繁信 （NTTデータMSE)
 角口 勝隆 （ JaSST Kansai 実行委員会）
 亀井 浩気 （三洋電機）
 川嵜 仁美 （JaSST Kansai 実行委員会）
 近藤 成直 （三菱電機マイコン機器ソフトウエア）
 土井 滋貴 （奈良工業高等専門学校）
 新美 崇宏 （データプロセス） 入路 友明 （奈良工業高等専門学校）
 林田 平馬 （奈良工業高等専門学校）
 平野 誠太郎（NPO法人 組込みソフトウェア管理者・技術者育成研究会）
 前畑 佳史 （島津エス・ディー） レビューのなんでやねん!?”～
角口勝隆著)
レビューのコツは
コツは“なんでやねん
なんでやねん ～レビュー眼
レビュー眼～(角口勝隆著
角口勝隆著
http://jasst.jp/archives/jasst10e.html#project3
 テスト設計加藤大受著)
テスト設計のとっかかり設計のとっかかり (加藤大受著
加藤大受著
http://jasst.jp/archives/jasst07k/pdf/T1.pdf
 ソフトウェア品質保証入門
ソフトウェア品質保証入門（奈良隆正・保田勝通 著）
品質保証入門（奈良隆正・ 日経情報ストラテジー年9月号
月号 (日経日経BP社
日経情報ストラテジー 2006年
日経 社)
 日経SYSTEMS
日経2010年
年12月号
月号 (日経日経BP社
日経 社)

 西 康晴先生（国立大学法人 電気通信大学）
71

72

付録：制約の例

参考文献２

 テスト采配のために、考慮すべき事項
 プロジェクトの制約
 プロセスの制約
 プロダクトの制約

 Rick D.Craigらの著書「体系的ソフトウェアテスト入門」
 「基本から学ぶテストプロセス管理」Rex Black74

73

付録：プロジェクトの制約例1

付録：プロジェクトの制約例２

 発売時期の発売時期の制約：
制約：

 資源の資源の制約：
制約：

世界初、期間限定品→機能独自性
 修正時間の修正時間の制約：
制約：
開発メンバと設計メンバの距離、バグ表の共有→不具合発生の影響度
 テスト時間
テスト時間の時間の制約：
制約：
少ない工数、顧客との調整の遅れ→発生頻度、影響度
 他組織との他組織との連携
制約：との連携の連携の制約：→別組織、あるいは雇用形態が異なるテスト部隊と一緒に作業を分割してやらないといけない。

テスト対象が少ない、壊れるテスト項目がある、資金的問題、テスト環境(恒温槽) テスタのテスタの制約：
制約：

モチベーションの高さが不足？、スキルの適合？、人数が少ない？

75

76

付録：プロセスの制約例

付録：プロダクトの制約例

 開発プロセス
開発プロセスのプロセスの制約

 特別な特別なテスト環境
テスト環境が環境が必要となる
必要となる制約となる制約

ウォーターフォール、アジャイル
 承認手続きの承認手続きの制約
きの制約
ドキュメント志向、顧客承認がいる
 進捗の進捗の制約
前工程の遅れ、実機の納品がテスト後半になる
 仕様の仕様の正確性の正確性の制約：
制約：
仕様変更を連発する顧客、急な仕様変更

水深20mでも動作する、年度でミリ秒誤差のない精度の高い時計、電波時計、GPS時計、(美人時計)、100m先から見える時計

77

78