テストすべき対象は、「モノの集め方」によって決まる 〜TM技術を使ってモデルベースドテストの可能性を考える(第1回)〜
目次
はじめに
今日は、テスト計画やテスト分析、またテスト設計といった「テスト活動」において、「効果的にテスト対象を見つける方法」についてお話ししたいと思います。
基となっているのは、事業分析・データ設計で長く活用されている「モデル作成技術」です。
やり方をざっくり言うと、「モノを集めて、並べて、関係するモノを線で引き、クラス使ってセット(集合)に整える」になります。
背景にあるのは、以下の3つ。 - システムやプロダクトが複雑になればなるほど、全てを把握するのに時間がかかる。 - ドキュメントに書き起こす際に冗長的になりやすく、作るのに時間がかかる。 - 情報が整理しずらく、抽出漏れや観点の抜けといったことが起きやすくなる。
上記の3つにより、「高い品質のシステムやプロダクト」が作り辛くなってしまいます。
今までのやり方と、どう違うのか
今まで、様々な領域のテスト業務(システム開発では、通信系・銀行系・官公庁など。その他に、ゲーム開発や組み込み)をしてきた中で感じたのは 「インプットのドキュメントの書式、特に内容に対する書き方が、プロジェクトや領域・会社ごと・書く人によってバラバラで、読み解くのに時間がかかる」です。
前回の投稿「テスト業務である困りごとを「TM技術を使った、MBT(モデルベースドテスト)」で解決出来ないか？」にて、「困りごと3つ」を挙げました。
前回は長々と書いてしまい、根本的な問題について記事で言えなかったのですが、中でも一番言いたいのは、「書き分ける事により、時間がとられてしまい、テストに関わるドキュメントに対して、観点漏れや抜け漏れが多くなっていく」。
それによって最終的には、担保すべき品質が基準のレベルに達することが出来ない。システムやプロダクトの価値が下がってしまう、という事です。
なぜ時間がとられてしまうのか。これについては、前回の繰り返しになるので詳細は省きます。
「紙っぺら一枚でまとめられて、プロジェクトに関わる人たち、ひいてはユーザー含めてみんなが、仕様や機能がパッと見て理解できるようなモノってないだろうか。というか、欲しいっ！」
そんな中で出会ったのが、佐藤正美さんの著書でした。
「モデル作成技術」とはなにか
ここで言う「モデル作成技術」とは、TM(Theory of Models)技術を考案した佐藤正美さんの著書「事業分析・データ設計のためのモデル作成技術入門 技術評論社」から、事業分析やデータ設計で使われているモデル作成技術「TM」(T字型ER図を使ったモデル作成技術)のことを言います。
「モノを集めて、並べて、関係するモノを線で引き、クラス使ってセット(集合)に整える」。そのように作った一枚のモデル図から、事業を分析することにより、関わるすべての人と共通の認識を持ち、変化に強いシステムを構築することができる。
自分が思ってたこと、悩んでたこと、考えていたことに対する「答え」がそこにありました。
「そっか、モデルを作れば良いのか」
テストに導入出来そうなところはあるか？
作成したモデルには次の2点が現れると言います。
①事業構造が内包している強み・弱み ②事業構造が内包している環境適応力 出典：佐藤正美 著 事業分析・データ設計のためのモデル作成技術入門 技術評論社
「弱み」という部分を、テストに置き換えると以下のように捉えることができそうです。
- 欠陥(バグ)の原因となる
- •不足している部分
- •不明確な部分
- •不明瞭な部分
- 機能テスト(目的3つ)
- 機能完全性
- 機能正確性
- 機能適応性
- 非機能テスト(品質特性7つ)
- 性能効率性
- 互換性
- 移植性
- 使用性
- 信頼性
- セキュリティ
- 保守性
- 画面上に表示される情報名
- データ(各種ファイル、バイナリデータなど)に含まれる情報名
- 情報名
- 個体指定子("番号"や"数字のコード"が記述しているモノ。「xx番号」とか「〇〇コード」といった番号が付与されている)
- その他の項目("attribute"：属性のこと。個体指定子に付随している項目)
- ポイント：その他の項目を一意であるか(ユニークか)どうか、モノを集める段階では考えなくてOK
- 注意：管理対象となる「個体指定子」や「その他の項目」を、「勝手に変えて書いたりしない(変形しない)」。オリジナルのまま、そのまま書く
- システムやプロダクトを作る人が、問題解決やコミュニケーションの分野で使う思考法「具体↔︎抽象」
- 「モデルベースドテスト」で使われているモデル
この段階で、不具合(バグ)を発見することが可能。
また、システムやプロダクトの全体を俯瞰的に見た時に「テストすべき対象の要素」を導くことが出来る。 ※この点においては、後日「どのように導出するか」を述べたいと思います。
「環境適応力」についても、以下のテストタイプごとの目的や品質特性から「何を、どこで、どのようにテストするのか」を導出することも可能ではないかと思います。
ブラックボックステストやホワイトボックステストについても、それぞれのテスト技法やテスト手法からも、同じように導出することも可能だと考えます。
モノを集める
では、TM技術によるモデル作成の最初の工程「モノを集める」は、どのような方法なのか。どのようにして、集めるのか。
では、さっそく見てみましょう。
モノを集める→「情報」を集める
「モノを集めるとは、何か？」。もっというと、「集める"モノ"とは、一体どういうのを指すのか」。場所はどこ？何を見るの？
それは、「情報」です。
皆様から、「当たり前の事を言うなっ！」と、突っ込まれそうですが、そうなのです。「情報」です。
具体的にいうと、以下の二つになると考えます。
そして、その情報の集合は、
そう、「画面」や「データ」に集められていますよね。
とすれば、仕様書が仮になくても「システムやプロダクトに表示している情報」や「出力、参照しているデータの中身」から、テストに必要な情報を集めれば良い。
これで、場所や何を見れば良いのかわかりました。
あとは、「どう集めるか」です。
テスト対象の集め方
お待たせしました。ここから、技術的な本文に入ります。 ※待たせ過ぎかも、しれません。
ここから、 事業分析・データ設計のためのモデル作成技術入門について学んだことから、テスト対象の集め方について書いて行きます。
情報が集合している場所はわかったので、今度は「T字書式」に集めていきます。
T字書式については、上記書籍にてご確認ください。 ※図に出来なくて心苦しいのですが、すみません。もし、図にできるようになったら更新して載せる予定です。
そのT字書記の中に、
を、T字書式の「上側」「左側」「右側」の順で書いていきます。
ここでポイントと注意点が、各1つづつあります。
モノを集める段階では文脈、つまりは「構造」が判明していないので、とりあえず対応している個体指定子の箱に書いておく、とのことです。
今の「モノを集める」段階では、そのシステムやプロダクトが「どういう動きをするのか」「いつ、どこで動くのか」といった「How?」や「When?」「Where?」はわからないので、今はひたすら「What?」の部分を集めていくことになります。
この後の工程で整形するので、ひとまず「これは、ここでしょう！」というところに、その他の項目を置いておきます。
これから作るモデル図は、「システム、プロダクトを写像したもの」(写像ついては、後日書きます)になります。
いうなら、システムやプロダクトに関与している人たちが、認知している対象になるので、その場のフィーリングや勝手な解釈、また略すなどをしてはいけないです。
QAエンジニアやテスト設計者が、テスト分析や設計するときに「テスト対象の文言を変えない」のと同じように、もし文言を変えてしまうと、コミュニケーションがままならず、テスト対象が定まらなくなったり、レビューなどで「これ、何？」などと突っ込まれ、修正するために手戻りが発生したりと、効率が悪くなってしまいます。
そうなると、「モデル図としての機能」が果たせなり、モデルベースドテストの意味がなくなってしまいます。
なので、テスト対象は「そのまま書く」です。
Q.個体指定子には、「番号やコードがない」個体指定子ってあるの？
A.あります。というより、できます。
個体指定子は、「番号やコードがなくても、使うこと」が可能です。
なので「名称」しかない場合でも、それを個体指定子として使うことも出来ます。 テストの現場では、扱う領域のシステムやプロダクトによってまちまちだと思いますが、「名称」を個体指定子にできるのは、助かります。
課題
個体指定子は、基本的に「番号やコードが付与されている」というのが、もしかしたら今後テスト対象を集める際に、領域やプロジェクトごとに関係者同士の合意のもと、定義しておく必要があると思いました。
ある基幹系のシステムでは、個体指定子によるモノの集め方は適用できても、それ以外の領域では適用できないとなった場合の対応が必要ではないかと考えます。
また「名称自身を個体指定子にできる」について、参考にしている書籍上では「ごく稀である」と掲載があるように、多用するのは難しいのかなと思いました。
暫定的な案の一つとして、「商集合」の考え方を使ってはどうか？と思いました。
参考: 数学の基礎 齋藤 正彦著
「商集合」とは、以下の関係全体の集合のことを指します。
A/R : 関係Rが、集合A上の同値関係のときの、\\関係Rの同値類全部の集合
ここで、同値関係の条件3つを下記に掲載します。
同値関係の条件
1.反射律：
ならば、
2.対称律：
ならば、
3.推移律：
ならば、
…何のことなん？って、思いますよね。
ぶっちゃけ、私自身も数学基礎論(ここは現在勉強中)を勉強してく中で、この数式に出会い「？？？」と思った次第でして。
端的に言うと、「"同じ仲間だよなっ！"と言い切れる関係の集まり」で集めてもいいのではないか？と思った次第でして。
例えば、「恋人」とか「家族」とか「友達」っていう関係性があるように、「自分とこの人(もしくは、Aっていう人とBっていう人)とは、〇〇の仲と言い切れるよね」と、自分から見ても相手から見ても(Aから見ても、Bから見ても)、同じ関係性だと言い切れるのであれば、その関係性からなる集合として集めることが出来るのでは、と。
ならば「個体指定子に付随する」や「名称も個体指定子にできる」というルールに、「その集合の中で、商集合を作って(元同士が関係性を持つように、同じグループの仲間同士)集める」やり方も出来そうだなと。 そうすれば、番号やコード・名称というのに「機能ごと」にも集めることが出来そうだ、と考えてます。
とりあえず、「暫定的な案」なのでもう少し勉強してからこの課題に対する答えを出して行こうと思います。
方向性としては、一旦この方向での解決も視野に入れてみようとも思いました。
おわりに
後半に続くにつれて、濃い内容に差し掛かってきたましたが、そこは読者の方々に「沼」に入らぬよう、扱う言葉には注意したつもりです。
集め方については、一旦ここら辺で切り上げておきます。 更新があったら、随時更新してきます。
さて、次は「モノを並べる」です！ お楽しみに！
今後、以下のことも盛り込んで、新しいモデルベースドテストの可能性について記事にしたいと思います。
こちらは、追々書いていきます。
貴重なお時間を使って本記事をここまで読んでいただき、ありがとうございます！
では、また！
