まえがき

前回の投稿から、だいぶ時間が経ってしまいました。
面目ない！
※この間に、JSTQBのALTM試験を受けて玉砕(不合格)しました。。。😢

本編のほうを書くべきなのですが、今日はリハビリがてらTM技術のモデル図を作ってみました！

第4回までの記事をお読みになった方で、「じゃぁ、そのモデル図って一体なんなのさ！」と突っ込んでいらっしゃると思い、ここでそのモデル図を書き出してみたいと思います！

急に思い立ったため、超アナログ(ノートに付箋をつけて作った)ですが、イメージだけ掴んでいただけたら幸いです！

参照元は引き続き、事業分析・データ設計のためのモデル作成技術入門から、サンプルを参照しながら書いていきます！

モデル図

参考にしている本から、「受注入力画面」「請求照会画面」の機能を抜き出してモデル図を作ると、こんな感じになります。
※手作り感満載で、すみません。

画面の遷移としては、「受注入力画面」→「請求照会画面」の順で遷移していく形になります。

このモデルでは、「受注」というEventに対して、「顧客」「商品」という2つのResourceが、1 ：多で結ばれています。
これによって、「1人の顧客から、複数の受注データを受ける」という見方が出来、入出力する(される)データの数がわかります。

またデータの数と共に、受注→請求という流れでEvent同士も同じように結ばれています。
これが、「処理の流れ = ユーザーストーリーの流れ」となります。

処理の流れを「先行→後続」のEventで表し、Eventが参照しているデータをそれぞれのResourceから引っ張っている状態。また、扱うデータの数の本数を表しているのが、このモデルが指し示しているものになります。
※結んでいる線の形や、その他の詳しいことは、後の記事にて掲載します。

このモデル図を作成して、以下のことを実現したいと考えています。

テスト計画の策定時に、テストすべき処理の流れや処理全体をパッと見てわかることにより、テスト範囲を分かりやすくする。
テスト分析や設計時に、Eventに紐ずくResourceの数で、参照するものが足りてる or 足りていない(充足 or 不足)を判断して、仕様バグがないか判別したい。
ドキュメントの数を減らして、全員共通のインプットとして使いたい。
障害発生時に、モデル図から「影響している範囲(どのEventの、どのResourceが不具合を生じているか)」を直ぐに判別できるようにしたい。
新しい機能を追加する際の、分析・設計用の図として使いたい。

他にも、いくつかありそうですが、大きくいうと上の5つとなるでしょう。

とにかく、プロダクトやシステムを作る時には「プロダクトやシステムの現在の状態を表して、テストを導出させたい」というのが目下の目標です。

これを行うことによって、「品質の本質を捉えたテストが可能」であると考えます。
その本質とは、「関わる人たち(ステークホルダー)との約束を守る、そしてその約束を守り続ける」ことです。

これが、QA歴10年目の私が思う「QAエンジニアが品質保証活動を行う理由・目的」です。

このことを胸に、TM技術によるモデルベースドテストの構築やこれからの品質保証活動を行っていく所存です。

さて、リハビリも終わったところで次回からは本編のほうに戻ります！第5回目です！

近日中には書く予定ですので、お見逃しなくっ！

では、また！