0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

よし、「並べよう」!

Last updated at Posted at 2023-10-22
1 / 2

目次

前回の振り返り

前回の投稿「テストすべき対象は、「モノの集め方」によって決まる 〜TM技術を使ってモデルベースドテストの可能性を考える(第1回)〜」にて、テスト対象の集め方、もとい「モノの集め方」について、T字書式にてまとめる方法を投稿しました。

今回はその集めたものを、「並べる」ことについて書いていきます。

参照元は前回と同様、事業分析・データ設計のためのモデル作成技術入門から学んだことから書いていきます。

本編に行く前に

前回の「テストすべき対象は、「モノの集め方」によって決まる 〜TM技術を使ってモデルベースドテストの可能性を考える(第1回)〜」で、一つ書き忘れたことがありますので、それを書きます!
※書き忘れて、すみません🙇  

「モノを集める」の追加工程

T字書式で集めた後に、さらに以下の作業を実行します。

追加する作業

  • 1つの個体指定子について、1つのT字書式を作ってその他の項目(attribute)を"分ける"

左側に記載した個体指定子から、更に1つの個体指定子ごとに1つのT字書式を作って、その他項目(attribute)を、対応する個体指定子ごとに分ける作業を実行します。こうすることで、モノを並べるときに「それがどういうモノなのか」を分かりやすくすることにより、並べやすくなると思います。

また、「現実的事態を写像する構造物」において、作成するモデルは、品質が保たれるとも考えます。

  • 論理的に構築することによる、完全性または信頼性
  • カスタマイズしやすいことによる、拡張性
  • 修正や追加しやすいことによる、保守性
  • モデルを継続して使用できることによる、可用性
  • テスト対象・観点などを導出しやすくなることによる、使用性
  • AのテストプロジェクトとBのテストプロジェクトで、名前が変わっても種別が同じテストプロジェクトで、作成したモデルの一部または全てを再利用することができることによる、互換性
  • 別の環境・領域に変わっても容易に移行することができることによる、移植性

ここまで記載して、お気づきかと思いますがこのTM技術によるモデルは所謂「品質特性である「非機能要件が満たされる」※」ことに繋がると考えます。
※「拡張性」を除いた品質特性

それらを、これからの投稿で示して行く予定です。

テスト対象を並べる

本筋に戻りまして、ここから集めたモノの「並べ方」について述べたいと思います。

まずは、T字書式で分けたモノを以下のカテゴリーに分類します。

  • Event:その他の項目(attribute)に日付が入っているもの
  • ResourceEvent以外のもの

Eventは、日付が入っているモノを指します。例えば、以下のような日付が入っているものです。

  • 保存した日
  • 作成した日
  • 更新した日 など

Resourceは、Event以外のモノで日付が入っていないものになります。

これらの2つのカテゴリに、Eventには「E」、そしてResourceには「R」というラベルをつけて分類します。

分類し終わったら、Event時系列に従って左から順に並べていきます。
例えば、ファイルを生成するシステムの場合、以下のEvent持っていると仮定します。

ファイル生成のシステム(EventのT字書式で作成したモノと想定)
⚫︎新規作成
⚫︎保存
⚫︎更新

これらを「新規作成→保存→更新」の順に、各Eventの集まりを左から右に並べていきます。

Eventが並べられたら、Resourceの集まりEventが配置している周り(上下)に配置していきます。

これだけです。

並べてみて判明すること

この「並べる」工程により、テストするシステム・プロダクトが「変化に強いシステム・またはプロダクトかどうか判断できる」とのことです。
Resourceの数 > Eventの数(Resourceの数が、Eventの数より多い)になっていれば、変化に強いものになっているとのことです。

ここから、テストするシステム・プロダクトに対して「そのシステム・プロダクトの仕様に対して、不足・欠損していることから起因する不具合の要否」が分かると考えます。
つまり、仕様の不具合がある程度そこで判明できるです。

課題

時系列にEventを並べる」について、ここは開発側と一緒に確認しながら並べていく必要があると思いました。

具体的な機能処理を並べる訳なので、関連する領域ごとのシステムやプロダクトの処理の流れが分かっている場合、ある程度並べた後で開発チームに見てもらうといったことが有益でしょう。

逆に、処理の流れが分からなかったときは、開発側のエンジニア・プログラマーの方と一緒に、共通の理解を得ながら作業していくことが必要です。

おわりに

今回は、「モノを並べる」について書いていきました。

今週は、内容を凝縮して書いていきましたが、文章の適切なバランスをとるのって難しいですね😓

次は、「関係するモノを線で引く」について複数回に分けて投稿しようかと思います。

今回も、貴重なお時間を割いて本記事を読んでいただき、ありがとうございます。

では、また!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?