記録用ブログ

個人的な記録のためのブログ。主にソフトウェアテストの話題。

エラー推測とリスクベースドテストについて調べてみる

エラー推測とリスクベースドテストって似てる気がします。共感してくれる人がどのくらいいるかは分かりませんが（とても自信がない）。

共通点としては、両方とも「こういうまずいことが起こりそう、起こるかも」ということをベースにしている点だと思っています。
少し脱線しますが、「悪さの知識」と言えるのかな？
「悪さの知識」は以下「ソフトウェア品質は“ユーザー主導”の時代へ」p30によると「そうやると上手くいかないよ、という知識」のこと。
https://qualab.jp/materials/mynavi130626.bw.pdf

例えば、起こりそうな欠陥を踏まえてテストを考えようとしている人がいるとき、それだけではエラー推測をしようとしているのかリスクベースドテストをしようとしているのか、いまいち判断できない気がしたんです。

で、少し調べてみましたという記事です。

先に結論

一言で言うと、リスクベースドテストでいう「リスク」の方が、より範囲が広いのだろうと理解しました。

SQuBOKガイドのリスクベースドテストの記載を見ると、SQuBOKガイドではリスクベースドテストを「テストマネジメントにおけるリスクベースドテスト」「テスト設計におけるリスクベースドテスト」の2つに分けられています。
前者の場合は、必ずしも具体的なエラー・故障・欠陥をベースにするのではなく、機能や非機能の属性などをベースに発生可能性と影響度を判定して進めるケースもあるのだろうと。これは、書籍「体系的ソフトウェアテスト入門」を読んで考えたことです。
後者は結構エラー推測と近いような気がしました。
エラー推測は、機能や属性（だけ）をベースにするのではなく、具体的なエラー・欠陥・故障に着目するのが原則だと理解しました。

また、リスクベースドテストの方が、全体的にプロセスややり方が文献で説明されているケースが多い印象を受けています。
一方のエラー推測は、書籍「ソフトウェアテストの技法」によると「非常に直観的であり，場あたり的なやりかた」と表現されているので、より属人的なのではないでしょうか。

結局、起こりそうな欠陥をリストアップしてテストを考えようとしている人がどちらをやろうとしているのか？は簡単には判定できないという結論です。
ただ、具体的なエラー・欠陥・故障をベースとしているか？　複数の文献で述べられているリスクベースドテストのプロセス・やり方（この記事ではほぼ触れていませんが）に沿ってやろうとしているか？は、判断材料になると思いました。

調べた結果

最初にソースを。後述の結果は、大体以下から、独断と偏見でここぞというところを引用しています。

  • JSTQBシラバス　
  • ISTQB用語集
  • 書籍『ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－』　…以下、「SQuBOKガイド」と呼ぶ
  • 上記以外は、以降で書籍等の名称を略さず記載しています。
エラー推測を調べた結果

  • JSTQB FLシラバス　4.4.1 エラー推測

    • 「エラー推測は、エラー、欠陥、故障の発生をテスト担当者の以下の知識に基づいて予測する技法である。」
    • エラー推測っていうくらいなのでエラーだけか、せいぜいプラス欠陥くらいに着目するのかな？と思いきや故障もスコープだという。謎が深まりました。

  • JSTQB ALTAシラバス　3.3.1 エラー推測

    • 「エラー推測技法を使用する場合、テストアナリストは経験を活かして、コードの設計および開発時に発生した可能性のある潜在的なエラーを推測する。テストアナリストは想定されるエラーを識別したら、そのエラーの結果として生じる欠陥を明らかにするために使用する最善の方法を決定する。例えば、テストアナリストが無効なパスワードを入力するとソフトウェアが故障を表示すると想定した場合、エラーが実際に発生し、そのエラーがテストの実行時に故障として認識される欠陥をもたらすかどうかを検証するために、様々に異なる値をパスワード欄に入力するようにテストを実行する。」
    • このシラバスではマイヤーズ氏の「ソフトウェアテストの技法」が紹介されていたので、そちらもみてみたのが次項。

  • 「ソフトウェアテストの技法」 (近代化学社, 2006 年) 　p85

    • 「ある特定のプログラムが与えられたとき，彼らは直観と経験からある種のおこりそうなエラーの型を推測して，これらのエラーを発見するためのテスト・ケースを書くのである．」
    • 「非常に直観的であり，場あたり的なやりかたなので，エラー推測技法としての手順をしめすことはむずかしい．基本的な考え方は、ありうるエラーまたはエラーを生みやすい状況のリストを列挙して，このリストにもとづいてテスト・ケースを書くことである．」

  • SQuBOKガイド　3.8.1.4

    • 「テスト対象プログラムに発生し得るエラーを推測し，そのエラーを見つけ出すための特別なテストケースを設計する技法である〔ISTQB-ALTA 2012〕〔Myers 2006〕。混入しそうなエラーや，エラーが顕在化しそうな状況のリストを作成し，このリストに基づいてテストケースを書く。ここでエラーとは障害の意味である。」
リスクベースドテスト

  • JSTQB FLシラバス　5.2

    • 「リスク分析とリスクコントロールに基づいてテスト活動を選択し、優先順位を付け、マネジメントして いくテストアプローチをリスクベースドテストという。」

  • JSTQB ALTAシラバス　2.1

    • 「テストアナリストは、次のリスクベースドテストのタスクに積極的に関わるべきである。
      ・リスク識別
      ・リスクアセスメント
      ・リスク軽減」

  • ISTQB用語集　https://glossary.istqb.org/ja_JP/term/risk-based-testing-2-1

    • 「対応するリスクのタイプとリスクのレベルに基づき、テストの活動とリソースの利用をマネジメントし、選択し、優先順位付けするテスト。」

  • SQuBOKガイド 3.8.1.5

    • 「テストマネジメントにおけるリスクベースドテスト」…「プログラムの機能や特性ごとに問題（品質リスク）が発生する可能性（確率）と影響度を分析して，テスト範囲や優先度，リソースの割り当てといったテスト計画を立案し，それらをマネジメントする技法である。分析にはFMEA技法が用いられる〔Craig 2004〕。」
    • 「テスト設計におけるリスクベースドテスト」…「プログラムが障害を起こしそうな状況（リスク）を想定し，それらの障害が実際に検出されるか否かを確認するためのテストケースを設計する技法である。」

  • 「体系的ソフトウェアテスト入門」 (日経BP出版センター, 2004年)　第2章

    • リスク分析にて、機能・属性（パフォーマンスなど）に対して「障害が発生する相対的な可能性の指標」（p24）や影響の判定結果を割り当てている記載があります。

Kano Model（狩野モデル）を参考に品質のライフサイクルを想像してみる

先日、ソフトウェア品質シンポジウムの予習のために狩野モデル（Kano Model）に関係しそうな文献を読んだブログを書きました。

mejiro8.hatenablog.com

その後、X（旧Twitter）の他の方の投稿を見ているうちに、品質のライフサイクルに興味が湧いてきて、文献から得た内容のまとめと、自分の想像を書いてみたという記事です。

※「魅力的品質」「魅力品質」、両方の表記が考えられますが、ここでは「魅力的品質」で統一します。


----- 2023/08/29追記 　ここから -----
X（旧Twitter）で、素晴らしい記事を教えていただきました。
「品質のライフサイクル」について知りたい方は、以下の、狩野紀昭さんへのインタビュー記事をご覧いただくのがよいと思います。 「品質のライフサイクル」についても触れられています。
atmarkit.itmedia.co.jp ----- 2023/08/29追記 　ここまで -----

文献にはどのように書かれているか

『Viewpoint this month(第112回)米国で「狩野モデル」の着想を得る ベースはお客とメーカーが対話できる「品質要素」』より（アイソス = ISOS : マネジメントシステムと国際標準化の専門月刊誌 26(7)=284:2021.7 p.8-13）

まずは、狩野 紀昭さんが書かれた文献。ライフサイクルと思われる記述が一部あり、以下のような話が書かれています。

  • 魅力的品質が、時間の経過とともに、当たり前になっていく
  • 当たり前になった後、もう一度、魅力的品質にできないか？

書籍「ソフトウェア・ファースト」より（ 及川卓也著, 日経BP社, 2019年）

上記文献の2章　IT・ネットの“20年戦争”に負けた日本の課題と光明　要因3：サービス設計〜運用面での誤解に、次のような話が書かれていました。

かつては当たり前品質だったものが要求レベルが下がる例として、ローカライズの例が載っています。直感的に操作できるデバイスの普及、といった話が挙げられており、興味深いです。

具体例を想像してみる

他に、どんなライフサイクルが考えられるか？　想像してみました。

前述のローカライズの例と似ているのですが、ちょっと違う視点かも？と思って、自分なりに挙げてみます。 翻訳機能がなかった頃や、あっても精度が低かった頃は、海外のサービスで日本語マニュアルやヘルプページがあるのは有り難く、なくても仕方ないがあれば満足感に繋がりました。
一方、最近はWEBブラウザなどを使ってまずまず読みやすい翻訳結果が入手できるので、有り難みが薄まったような。更に翻訳の精度が上がれば、ほぼ無関心品質になると予想。

  • 無関心品質→（ユーザーの住環境や使い方の変化）→魅力的品質
    • 例：電気ポットの、電源コードを抜いても給湯できる機能

台所にあるコンセントの数が少ない家に引っ越した場合など、お湯を沸かした後は給湯を気にせず電源コードを抜けると嬉しい場合はありそうです。

  • 無関心品質→（ユーザーの高齢化）→魅力的品質
    • 例：テレビなどの家電のディスプレイに表示される文字の拡大機能

製品や外部環境が変わるだけではなく、主要ユーザー自身の変化によるライフサイクルもあるのかな？と。例えば、購入当初は標準サイズの文字で十分見えていたものの、視力が弱くなると、拡大機能があることが満足に繋がる場合もありそう、と考えました。

  • 当たり前品質→（価値観の変化）→一元的品質
    • 例：モノクロ撮影機能、モノクロ専用のデジカメ

私自身が写真が好きなので、カメラの例を。
昨今、カラー写真が撮れるデジカメでもモノクロのモードがついているのは珍しくないと思っています。私にとってはモノクロのモードがないと不満、あって当たり前、という感覚です。編集ソフトで白黒に仕上げてもいいんですけど、撮影時点でこれは白黒の方がカッコ良さそう、という場合はモノクロで撮れた方が嬉しい。

が、最近、モノクロ専用デジカメが発売されたと聞きました。カラー写真が多い中で敢えてモノクロ専用を選びたい人が相当数いるのだとすると、モノクロ写真を撮影できることが当たり前にとどまらずに満足に繋がることがあるのかなあ、と考えた次第です。

モノクロ専用デジカメについて参考：https://kakakumag.com/camera/?id=19457

このパターンはきっとありそう、何か例はないものか、と捻り出したのがコレ。
現代のデジカメにはオートフォーカスはあって当たり前の機能ですが、それでも被写体や環境によっては、フォーカスが迷ったり間違ったりします。難しい場面は経験則で予想できるので、普段はフォーカスが間違っても仕方なし…と思って終わりなのですが、条件が悪くてもきっちりフォーカスを合わせてくれると感動しますし非常に魅力に感じます。
うーん、もっと良い例がありそうで、悔しいなー。

想像してみて何を考えたか

今回あげた具体例は、私自身の想像の産物であり、異論反論はあると思います。

今回は自分一人で考えましたが、同じソフトウェアを開発している関係者同士で「何が魅力的品質か」「自分たちの製品の品質のライフサイクルはどうなるか」といった考えを持ち寄って議論すると面白そうだし価値観の可視化と共有にも繋がりそう、と思いました。
また、製品自体や関連するデバイス等の進化のほか、ユーザーの価値観や、競合・外部ツールなどとりまく環境の変化にも、ライフサイクルは影響を受けるのではないかと、感じました。

Kano Modelに関係しそうな文献を読んだメモ（魅力的品質要素など）

今年もソフトウェア品質シンポジウム （SQiPシンポジウム）の季節がもうすぐ。今年2023年の基調講演は「Kano Modelから品質について学ぶ！」。
開催概要・申込み | ソフトウェア品質シンポジウム 2023

せっかくなので予備知識をつけて聞きたいと思い、狩野モデル（Kano Model）に関係しそうな文献を読んで、少し予習をしてみました。
読んだ文献→気づいたこと・考えたこと、の順序でメモしてみます。

読んだ文献

昔読んで、再度読み直したものも入っています。
一部例外はありますが、ほとんどが、狩野 紀昭さんの論文・雑誌記事です。

  • 魅力的品質と当り前品質
    • 狩野 紀昭, 瀬楽 信彦, 高橋 文夫, 辻 新一（著）
    • 品質　1984 年 14 巻 2 号
  • Viewpoint this month(第112回)米国で「狩野モデル」の着想を得る ベースはお客とメーカーが対話できる「品質要素」
    • アイソス = ISOS : マネジメントシステムと国際標準化の専門月刊誌 26(7)=284:2021.7 p.8-13
  • 私が伝えたいTQMのDNA (特集 TQMのDNA)
    • 品質 = Quality : journal of the Japanese Society for Quality Control 36(4) (通号 141) 2006 p.413～417
  • 特別寄稿 日本が直面する品質危機
    • 大和レビュー (9) 2003.新春 p.4～13
  • ジュラン博士の日本の品質革新へのご貢献を振り返る (追悼 ジュラン博士)
    • クオリティマネジメント = Quality management 59(5) (通号 762) 2008.5 p.52～57
  • 追想録　ミスターQC　米山高範　　第3部　米山高範さんの素顔と語録「米山哲学」　　第４章 米山モデル

ほかに数件、この機に目を通しました。興味深い話は多かったのですが、この投稿に直結していないものは割愛します。

また、著者が狩野 紀昭さん以外の文献で確認したものは、以下。いずれも書籍。

  • ソフトウェア・ファースト, 及川卓也著, 日経BP社, 2019年
    • 2章　IT・ネットの“20年戦争”に負けた日本の課題と光明
      • 要因3：サービス設計〜運用面での誤解
  • 【新版】動機づける力―モチベーションの理論と実践 (Harvard Business Review Anthology),　DIAMOND ハーバード・ビジネス・レビュー編集部 (著), ダイヤモンド社,　2009年
    • 第1章◎モチベーションとは何か

気づいたこと、考えたこと

オチはないです。気づいたこと、考えたことを挙げていきます。

  • 論文「魅力的品質と当り前品」で提唱されている品質要素は魅力的品質要素・当り前品質要素・一元的品質要素だけではありません。充足度合いが満足にも不満にも繋がらない無関心品質要素、充足が不満を引き起こし不充足が満足を引き起こす逆品質要素も挙げられています。

    • 魅力的・当り前・一元的品質要素の使い勝手が良い（？）せいか、この3つしか扱っていない資料も見たことがあります。
    • 個人的には、充足していることが不満につながる「逆品質要素」は面白い考え方だと思います。ただ、たとえば多機能であることは充足しているように見えるがシンプルさという側面ではマイナスになると考えると、一言的品質要素とはっきり区別するのは難しいような気もしてモヤモヤ。

  • 魅力的だと思われているものが、やがて当り前になってしまうことがあるように、品質にはライフサイクルがあります。

    • 品質要素が時とともに変わっていく話は、書籍「ソフトウェア・ファースト」の2章の要因3に、具体例を交え分かりやすく説明されています。

  • 複数の文献から、扱われている「品質」がモジュール単位、統合テストをする単位、というよりは、製品あるいはサービス全体の品質であるように感じました。

    • つまり、プロダクト組織全体や、その周りも含んだ活動で支えられているようなカバー範囲の広い品質を対象にしているように見えます。　　
      • 例えば、品質危機を起こすものとしてコスト重視や教育予算削減を取り上げられており、品質危機の克服に経営者のリーダーシップを求めています。企業文化の話なども考慮されていそう。
      • 論文「魅力的品質と当り前品質」にテレビの品質の話が登場しますが、品質要素のひとつに「使用説明書」が登場することからも、製品やサービス全体を対象にした考えなのだろうと思います。

  • ハーズバーグの動機付け衛生理論（M-H理論）を参考にしている模様。

    • ハーズバーグの動機付け衛生理論は、仕事への満足を生む要因と、仕事への不満足をうむ要因は別、という説です。まさに魅力品質・当たり前品質にも当てはまる話。
      • 更に、そもそも欲求も、成長や昇進といった動機付け要因（motivator、満足の要因）と、給与や人間関係といった衛生要因（hygiene factors、不満足の要因）の2種類に分けられるとされます。
    • ハーズバーグの動機付け衛生理論は入手しやすい資料がなかなか見つけられなかったのですが、書籍「【新版】動機づける力―モチベーションの理論と実践 (Harvard Business Review Anthology)　」の第1章「モチベーションとは何か」に出ていました。
      • 同書から、気になった部分を引用。「人間は、衛生要因が満たされなければ不幸になるとはいえ、鎮痛剤のように一時的な苦痛から解放してくれるだけで、より深い満足感が得られなければ、一時的な効き目もすぐに消えしまう。」（35ページ）…品質でも同じようなことが言えるんでしょうかね？
      • この理論はもう少し知りたいので、資料を探してみようかなと思っています。

  • 米山高範さんによるカメラの新商品開発の話に影響を受けているようです。

    • あるカメラメーカーにて、カメラの開発にあたり、カメラを使う目的である撮影そのものに注目。顧客が撮影した写真のプリントを見てまわり（当時はデジカメではなくフィルム）、実際に起きている撮影不良の内容を調査した上で顧客の潜在要求を汲んだ新しいカメラを開発、ヒット商品を生んだという。製品自体だけではなく、ユーザーの使用目的にも注目して成功をおさめた話。
    • 米山さんご自身がこのカメラ開発に直接関与されたわけではないが、この開発の話をもとに商品企画のモデルを示されたそう。そして、このモデルの話が、魅力品質の話に繋がっているそうで。

  • ほか、TQMで有名なジュラン博士にも影響を受けているようです。

    • 本題から外れますが、ジュラン博士については寡聞にしてよく知らず、パレート図の考案者であることや、日本の品質に与えた影響が知れたのは面白かったです

  • 新製品から成熟製品へ移行する際の競合優位性に影響する品質について、3つのレベルに分類されていました。（「私が伝えたいTQMのDNA (特集 TQMのDNA)」より）

    • 基本的な要求や規格への適合を達成した上で、更に明示された要求を満足するところに顧客満足があり、更に潜在的要求を実現して顧客歓喜へ、…という話らしい。面白い。

テスト観点検討時に参考になりそうな一般的な情報

テストの分析・設計時、テスト観点を検討するときに参考になりそうな、一般的かつまとまった情報について、手の届く範囲でまとめました。

N番煎じネタのうえに残念ながらあまり新しい情報は見つけられなかったのですが、個人的に必要になったのでメモ兼ねて。

テスト観点の定義は以下と同様です。

テスト設計チュートリアル/Test Design Tutorial - Speaker Deck

　

テストタイプっぽいもの

  • ISO25000シリーズの品質特性
  • 「Ostrandの4つのビュー」と呼ばれる4要素「ユーザビュー、仕様ビュー、設計・実装ビュー、バグビュー」
  • 書籍「ソフトウェア・テストの技法　第2版」（マイヤーズ J. (著), バジェット T. (著), トーマス M. (著), サンドラー C. (著), 長尾 真 (翻訳), 松尾 正信 (翻訳) 　2006年、 近代科学社）　「第6章　上級テスト」に掲載の以下
    • 機能テスト
    • システム・テスト
      • 機能部分テスト、大容量テスト、ストレス・テスト、有用度テスト、秘密保護テスト、効率テスト、記憶域テスト、構成テスト、互換性／構成／変換テスト、設置テスト、信頼性テスト、回復テスト、サービス性テスト、文書テスト、手続きテスト
    • 認可テスト
    • 導入テスト　　　　

テストタイプっぽくないもの

ぼんやりと、こういうのは大体テストタイプっぽいんだろうなと思っていましたが、そうでないものもありました。

  • 意地悪漢字

  • 書籍「基本から学ぶソフトウェアテスト」（Cem Kaner (著), Hung Quoc Nguyen (著), Jack Falk (著), テスト技術者交流会 (翻訳) 　2001年、日経BP）

    • 例えば「終了不可能な状態」（380ページより引用）といった不具合例が、60ページ以上に渡って書かれている
    • 付録として「よくあるソフトウェア不具合」が掲載されている。ただ、プロセスの話も含めいろんなカテゴリのものが一箇所にまとまっており、また使っている技術要素や対象システムの思想によっては参考にしにくい・できない部分がある（私見）。どれにも言えることだが、特にこれは取捨選択が必要そう
    • テストタイプっぽくないに分類したが、掲載の不具合を分類すればテストタイプが見えてきそう

　　　　　　

こうしてみると結構前からある資料ばかりだなあ。

探し方が良くないのかもしれませんが、テスト観点まわりの論文や資料は最近でも出ているものの、テスト観点ひと揃いを公開している論文や資料はない・少ない印象です。

欠陥モデリングの記法で日常トラブルを表現してみた

先日、洗い物中に包丁で手のひらを切って怪我をしました。
傷は小さいのですが、当たりどころが悪かったのか血がすぐには止まらず。病院で診てもらって、治療中です。

そんな中、レビューをテーマにした勉強会に参加しました。
その勉強会で欠陥モデリングのワークがあったのですが、勉強会後ふと、怪我もモデリングで表現できるのではないかと思いました。

欠陥モデリングの記法は、以下の資料「 JaSST 2013 Tokyo – Project Fabre　 過失に着目した欠陥のモデリング」の20ページ目に説明されています。
https://www.jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf
この資料はこれまでも何度も拝見しているのですが、レビューの勉強会で手を動かして書くことができ、改めて、面白いなあと。

ということで、欠陥モデリングの記法で今回の怪我についてふりかえってみました。

書いてみたモデル

矢印で繋がってフローになっている部分がモデル。
右下の雲の図形はモデリングの記法にはないけれど気になってメモしたこと、後述します。

包丁で手を切ったときのモデル

気づいたこと
  • 原因に関係する因子が誘発因子、増幅因子、過失因子と3つに分かれているため、適度に分解して考えやすい
    • 分解すると、対策が考えやすくなる
    • 日記のように文章で書くと、余程意識しない限りこの3つは混ぜて書いてしまいそう
  • 書いているうちに思いついた因子があった。今回でいうと「台所に物が多い」
    • 周りに物が多いと作業中に気配りしなくてはならないことが増える。結果、他のことに気を取られやすい状態を増幅してしまったように思う
  • 例えば「包丁を洗った（使った）」は過失因子になりえるが、これに手を打つのは自分の場合は非現実的なので書かなかった。ただ、システムの欠陥を扱う場合、特にチームで話し合う場合は他の人からアイディアが得られるかもしれないので、最初から間口を狭めずに非現実的でも一回考えてみる方が良いかもしれない
  • トラブルを軽減する因子はどう書くのだろう？　あるいは、モデリング対象外？
    • 今回でいうと、図中右下の雲の図形の通り、包丁は洗ったものだったので傷口に汚れが入り込む恐れが少なかったのは不幸中の幸い
    • システムの問題であれば、例えば、適切な監視をしていたから欠陥に早く気づけた、といったこと。障害対応のふりかえりや形式知化をするといった場合には、個人的には書きたい気がする

余談：モデルを見た上で、再発防止はどうするのか

まずは、台所の物を減らすこと、急いで料理しなくてもいいようにスケジューリングすることを考えようかと思っているところです。

ゆもつよメソッドによるテスト分析を学んでみた感想ー有益な仕組みと注意点

「ゆもつよメソッド」というテスト開発手法を学ぶ機会に恵まれたので、掲題のテーマで書き綴ってみる。

筆者がこの手法を、セミナー受講を通して学んだ結果として感じたことを書いたものであり、ゆもつよメソッドの体系的な説明ではないことに注意。

※この手法を体系的に知りたい方はJaSST'21 Tohokuのサイトに掲載の資料を見るか（無料）、有料のセミナーを受講する方法がある。2022年7月末現在、同年12月に、セミナーが開講される予定となっている（セミナーの回し者ではないが）。

　

ゆもつよメソッドの簡単な説明

ゆもつよメソッドは、以下のような手法である （https://www.jasst.jp/symposium/jasst21tohoku/report.html　より引用）。

ゆもつよメソッドとは、湯本剛氏によって提唱されるテスト開発手法です。 テスト開発するにあたり、ゆもつよメソッドではテスト分析を重要視しています。 テスト分析は、以下の3つの工程に段階的に行います。また、このテスト分析は、チームで実施することができます。

1.「何をテストするか」を考え、仕様書をテスト用に再構成します。

2.テスト用の機能一覧を作成します。

3.②の機能一覧を内部構成を意識しながら、再度「何をテストするか」を洗い出していきます。

テスト分析の全体像は、以下のJaSST'21 Tohokuの資料6ページ目に出ている。

https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-1-1.pdf

学んでみて、プロセスが体系だっているだけではなく、テストをうまく進めるための有益な仕組みを様々含んでいる手法だと感じた。

注意点とあわせて、自分なりに考えたことをまとめてみる。

有益な仕組み

段階的にテストを考えるための仕組み

テスト仕様書を読んでいきなりテストケース（スクリプト、手順）を書き始めると、大きな抜け漏れが発生しやすい。関連機能についての考慮が抜けていたとか。 また、具体的になればなるほど、他の開発案件やシステムでの経験が活かしにくくなる。

そのため、テストは段階的に考えた方がよい。が、段階的にテストを考えるというのは、案外難しい。段階を数段飛ばして、具体的なテスト内容や起こりそうな欠陥が頭にちらつくことはよくある。

ゆもつよメソッドに沿ってテスト分析を行えば、段階的にテストを考えるために次に何をすれば良いかガイドされる。 以下のような仕組みが、段階的な検討に不慣れな人の助けになる。

  • 仕様を深く理解するためにモデルを描くが、そのガイド（論理的機能構造）がある。この論理的機能構造は抽象度が絶妙（他の手法だとラルフチャートも同様だと思う）。
    • 自己流だとUMLで分析することがあるが、仕様の全体感を捉えたいのに、ついつい細かすぎることを考えてしまうことがある。
    • 論理的機能構造くらいの抽象度なら、「分析対象の機能の本質は何か」「分析対象の機能のIN/OUTは何か」に集中しやすい。
    • 論理的機能構造を知らない人に分析結果を見せたとしても、概ね理解してもらえそうなところも良い。
      • 「サポート」だけは分かりづらい気がするが、エラー処理や状態遷移などが分類されるとのことである。
  • 特に序盤でつくるモデルや機能一覧は、完璧を目指さなくてよい。
    • 最初から完璧にと言われると、あれもこれも細かく見たくなってしまうが、そうではない。
    • 機能一覧は継続して改善してテスト分析終了までに良いものにできれば良さそう。
  • テスト分析の段階では、テスト設計技法や具体的なテストパラメータの検討はしないことになっている。
    • 思いついたものをメモする程度。
    • この考え方のお陰で、テスト分析の段階では、テストのための仕様の理解と再構成、抽象的なテストしたいこと（仕様項目）の検討に集中できる。
テスト担当者が考えたこと、理解したことを解読しやすくするための仕組み

テスト分析の成果物は、作成直後だけでなく、後日でも参照されることがよくある。テストチームの人員追加がある場合や、類似案件で参考にする場合などだ。 他人のテストドキュメントを正しく読み解くのは、その書き方によっては、苦労する。

ゆもつよメソッドでテスト分析を行うことで、後から読む人に様々なヒントを残しやすくなる。

  • モデルや仕様書などを参考につくる「機能一覧」には対象システムの機能と、それに対応する仕様書の章番号を書く。機能だけでなく、仕様書との紐付きも記録しておけることで、後々テスト分析を参照したときに理解しやすくなる。
    • 機能という言葉は、ここでは対象のテストレベルにおけるインタフェースという意味のようだ。
    • 機能軸で考える。仕様書の構成と機能が一致していないこともあるので、仕様書の章番号を頭から書く作業ではない。
    • 開発のための仕様書の構成ではなく、テスト向けに考えられた仕様の構成をつくることができる。
  • テストする要素に、テストカテゴリとして自分たち自身で名前をつける。
    • モデルを描いて機能一覧を作成しテスト用の機能の分割を決定したら、次にテストカテゴリを作成する。
    • テストカテゴリとは、「論理的機能構造の各要素に対してテスト対象にふさわしい名前を与えたもの」である。 （引用元　https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-2.pdf　7ページ）
    • 自分たちで命名することで、意図を残しやすくなるのではないか。論理的機能構造の名称をそのまま使ったり、汎用的なテストカテゴリを指定したりするのではないところが良い。
    • テストカテゴリは同じプロダクトやシステムで使いまわせるため、資産にできる。
  • 最終的に、「テスト分析マトリクス」で仕様項目とテストカテゴリの組み合わせに対する網羅度合いを俯瞰できる。テスト分析に携わっていない人にとって、こういった俯瞰できる資料は全体を掴むための助けになるだろう。
    • マトリクスにするだけではなく、仕様項目がないテストカテゴリについてその背景も追記できれば、より理解に役立ちそうだと感じた。
テスト設計でテストの意図（テストケースの意図）を見失わないための仕組み
  • テスト分析で洗い出した「テストで確認したいこと」が「仕様項目」として残るので、テスト設計のインプットになる。
    • 「仕様項目」を後のプロセスでも参照すれば、テスト技法の適用やテスト値のバリエーションを考えているうちに当初のテストの意図（目的や主旨）から外れてしまうことの予防に繋がるのではないか。
    • 「仕様項目」との整合性を確認することで、テスト設計の成果物がレビューしやすくなるだろう。

注意点

上述の通り、有益な手法ではあるが、適用にあたって注意したい点もあると感じた。

  • テストカテゴリは同じプロダクトやシステムで使いまわせるとのことだが、作った人がいなくなったら、その意味や使い分けは失われそうな気がする。 工夫が必要。
    • テストカテゴリを作成する際、「起こりうる不具合」を検討してチームで認識合わせをするプロセスになっているが、この「起こりうる不具合」をうまく保管できれば一定、理解の助けになるのではないか。
    • オンボーディングで社内用語のような形で教育するのもありかもしれない。
  • 体系的なプロセスと巧みな仕組みがあるとはいえ、それぞれのプロセスの成果物の抽象度は自分たちでコントロールする必要がある。
    • 例えば、テストカテゴリをやたら具体的にしてしまうと、仕様項目を出すときに苦労するし、他の開発案件で使いまわせなくなるだろう。
    • 先ほど述べたJaSST'21 Tohokuの資料を参考にする方法はありそう。
  • 機能一覧には、機能項目（機能の名称）の他、それに紐づく仕様書の章などを書く。仕様が全くドキュメント化されていない組織の場合、ここでつまずく。
    • 何かのドキュメントやシステムそのもの、あるいは、誰かの頭の中には一定の機能の情報があることがほとんどだろう。工数の捻出は必要になるが、事前にそれらを簡単にでもドキュメント化できれば解消できるように思う。

ゆもつよメソッドにおけるテスト分析の「仕掛け」を自分なりに整理する

「ゆもつよメソッド」というテスト開発手法を学ぶ機会に恵まれたので、掲題のテーマで書き綴ってみる。

筆者個人がこの手法を学んでみて感じたことを書いたものであり、ゆもつよメソッドの体系的な説明ではないことに注意。

※この手法を体系的に知りたい方はJaSST'21 Tohokuのサイトに掲載の資料を見るか（無料）、有料のセミナーを聞きにいくと良いだろう。2022年7月末現在、同年12月に、セミナーが開講される予定となっている。セミナーの回し者ではないが、この手法の提唱者である湯本さんから直接学べる貴重な機会だと感じたので書いておく。

　

ゆもつよメソッドの簡単な説明

ゆもつよメソッドは、以下のような手法である （https://www.jasst.jp/symposium/jasst21tohoku/report.html　より引用）。

ゆもつよメソッドとは、湯本剛氏によって提唱されるテスト開発手法です。 テスト開発するにあたり、ゆもつよメソッドではテスト分析を重要視しています。 テスト分析は、以下の3つの工程に段階的に行います。また、このテスト分析は、チームで実施することができます。 1.「何をテストするか」を考え、仕様書をテスト用に再構成します。 2.テスト用の機能一覧を作成します。 3.②の機能一覧を内部構成を意識しながら、再度「何をテストするか」を洗い出していきます。

テスト分析の全体像は、やはりJaSST'21 Tohokuの資料6ページ目に出ている。

https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-1-1.pdf

学んでみて、テストをうまく進めるために有益な仕掛けを様々含んでいる手法だと感じたので、注意点とあわせて、自分なりに考えたことをつらつら書いてみる。

有益な仕掛け

段階的にテストを考えるための仕掛け

テスト仕様書を読んでいきなりテストケース（スクリプト、手順）を書き始めると、大きな抜け漏れが発生しやすい。関連機能についての考慮が抜けていたとか。 また、具体的になればなるほど、他の開発案件やシステムでの経験が活かしにくくなる。

そのため、テストは段階的に考えた方がよい。が、段階的にテストを考えるというのは、案外難しい。どのような段階が必要か、各段階で何を分析するか、決定する必要がある。仕様書を見ていると、段階を数段飛ばして、具体的なテスト内容や起こりそうな欠陥が頭にちらつくことはよくある。

ゆもつよメソッドに沿ってテスト分析を行えば、段階的にテストを考えるために次に何をすれば良いかガイドされる。 以下のような仕掛けが、段階的な検討に不慣れな人の助けになる。

  • 仕様を深く理解するためにモデルを描くが、そのガイド（論理的機能構造）がある。この論理的機能構造は抽象度が絶妙（他の手法だとラルフチャートも同様だと思う）。
    • 自己流だとUMLで分析することがあるが、仕様の全体感を捉えたいのに、ついつい細かすぎることを考えてしまうことがある。
    • 論理的機能構造くらいの抽象度なら、「分析対象の機能の本質は何か」「分析対象の機能のIN/OUTは何か」に集中しやすい。
    • 論理的機能構造を知らない人に分析結果を見せたとしても、概ね理解してもらえそうなところも良い。
      • 「サポート」だけは分かりづらい気がするが、エラー処理や状態遷移などが分類されるとのことである。
  • 特に序盤でつくるモデルや機能一覧は、完璧を目指さなくてよいとのこと。
    • 機能一覧は継続して改善してテスト分析終了までに良いものにできれば良さそう。
  • テスト分析の段階では、テスト設計技法や具体的なテストパラメータの検討はしないことになっている。
    • 思いついたものをメモする程度。テストのための仕様の理解と再構成、抽象的なテストしたいこと（仕様項目）の検討に集中できる。
テスト担当者が考えたこと、理解したことを解読しやすくするための仕掛け

テスト分析の成果物は、作成直後だけでなく、後日でも参照されることがよくある。テストチームの人員追加がある場合や、類似案件で参考にする場合などだ。 他人のテストドキュメントを正しく読み解くのは、その書き方によっては、苦労する。 ゆもつよメソッドでテスト分析を行うことで、後から読む人に様々なヒントを残しやすくなる。

  • モデルや仕様書などを参考につくる「機能一覧」には対象システムの機能と、それに対応する仕様書の章番号を書く。機能だけでなく、仕様書との紐付きも記録しておけることで、後々テスト分析を参照したときに理解しやすくなる。
    • 開発のための仕様書の構成ではなく、テスト向けに考えられた仕様の構成をつくることができる。
    • あくまで機能軸で考えるので、仕様書の章番号を頭から書く作業ではない。
    • 機能という言葉自体が非常に広いが、ここでは対象のテストレベルにおけるインタフェースという意味のようだ。
  • テストする要素に、テストカテゴリとして自分たち自身で名前をつける。
    • モデルを描いて機能一覧を作成しテスト用の機能の分割を決定したら、次にテストカテゴリを作成する。
    • テストカテゴリとは、「論理的機能構造の各要素に対してテスト対象にふさわしい名前を与えたもの」である。 （引用元　https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-2.pdf　7ページ）
    • ここで、論理的機能構造の名称をそのまま使ったり、汎用的なテストカテゴリを指定したりするのではなく、自分たちで命名するために意図を残しやすくなるのではないか。
    • テストカテゴリは同じプロダクトやシステムで使いまわせるため、資産にできる。
  • 最終的に、「テスト分析マトリクス」で仕様項目とテストカテゴリの組み合わせに対する網羅度合いを俯瞰できる。テスト分析に携わっていない人にとって、こういった俯瞰できる資料は全体を掴むための助けになるだろう。
    • 個人的には、マトリクスにするだけではなく、仕様項目がないテストカテゴリについてその背景も追記できれば、より理解に役立ちそうだと感じた。

注意点

このように有益な手法ではあるが、適用にあたって注意したい点もあると感じた。

  • テストカテゴリは同じプロダクトやシステムで使いまわせるとのことだが、作った人がいなくなったら、その意味や使い分けは失われそうな気がする。 工夫が必要。
    • テストカテゴリを作成する際、「起こりうる不具合」を検討してチームで認識合わせをするプロセスになっているが、この「起こりうる不具合」をうまく保管できれば一定、理解の助けになるのではないか。
    • あるいは、本気で使いまわしたいのであれば、オンボーディングで社内用語のような形で教育するのもありかもしれない。
  • 体系的、かつ、巧みな仕掛けがあるとはいえ、それぞれのプロセスの成果物の抽象度は自分たちでコントロールする必要がある。
    • 例えば、テストカテゴリをやたら具体的にしてしまうと、仕様項目を出すときに苦労するし、他の開発案件で使いまわせなくなるだろう。
    • 先ほど述べたJaSST'21 Tohokuの資料を参考にする方法はありそう。
  • 機能一覧には、機能項目（機能の名称）の他、それに紐づく仕様書の章などを書く。仕様が全くドキュメント化されていない組織の場合、ここでつまずく。
    • 何かのドキュメントやシステムそのもの、あるいは、誰かの頭の中には一定の機能の情報があることがほとんどだろう。工数の捻出が必要になるが、事前にそれらを簡単にでもドキュメント化しておけば問題ないのではないか。