« パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai | トップページ | 日本のアジャイル開発の先人による話が良かった »

2023/07/02

テストアーキテクチャ設計モデルとJSTQB概念モデルの比較

平鍋さんのテストアーキテクチャ設計モデルと、自分が書いてみたJSTQB概念モデルを比較してみた。
気づきをラフなメモ。

【参考】
JaSSTで話題になったテスト設計をモデル化してみた - Qiita

JSTQBのテストプロセスの概念モデルを描いてみた: プログラマの思索


テストアーキテクチャ設計モデルはかなり抽象化されたモデルと思う。
テスト評価層、テストアーキテクチャ設計層、テスト種別層、テストケース層に分かれている。

テストアーキテクチャは、システムアーキテクチャに基づくテスト設計かな?
たとえば、システム特性ごとにテストアーキテクチャは全く異なる。
組み込みソフトウェアであれば生命に関わるようなリスクは極力避ける必要があるから、安全性の観点のテスト設計が多くなるだろう。
一方、マイナンバーカードシステムのようなBtoCの基幹系システムであれば、個人情報保護が非常に重要だから、セキュリティの観点のテスト設計が多くなるだろう。
つまり、テストアーキテクチャはシステム特性に大きく依存しているはず。

テストアーキテクチャはテスト評価層で評価される観点が興味深い。
テストアーキテクチャ記述とステークホルダーが結びついている。
つまり、マネージャ、利用ユーザ、プロダクトオーナー、品質保証部門などの観点でテストアーキテクチャ記述はレビューされて評価される。
ステークホルダーごとにレビュー観点は異なるから、そういう視点が反映されている。
この点は非常に重要だ。
「このテストは誰のためにあるのか」という問いにつながるからだ。

テストコンテナという概念でテスト種別を表す点も興味深い。
最初に見た時、テストコンテナとは何だろう?と思った。
テストコンテナは、コンテナ分割方針によってグループ化されており、コンテナ分割方針はテストレベル、テストサイクル、テストタイプなどがある。
つまり、テストコンテナは、工程や品質特性、テスト期間の観点で組み立てられたテスト方針のように思えた。
おそらく、システム特性に応じたテストアーキテクチャを具体的に実装する場合、具体的にどんなテストが必要になるのか、というテスト内容が含まれていると考える。
すなわち、システムやプロジェクトごとにテスト方針がテーラリングされていることを示しているのだろう。

テストタイプにソフトウェア品質特性が関連付けられているのもミソだ。
つまり、8つのソフトウェア品質特性の観点に対応付けられた非機能テストがあることを示している。
たとえば、性能テスト、負荷テスト、耐障害性テスト、セキュリティテスト、移植性テストなど。
この考え方は「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」にもあったから、自分のJSTQB概念モデルに取り入れさせてもらった。

テストケース層でテストスクリプトが中核にあるのは、自動テストを意識されているからだろうと思う。


一方、自分のJSTQB_テストプロセスの概念モデルはかなり具体的だ。
テストプロセス層とテスト成果物層で分けている。

テストプロセス層では、テストプロセスを中核として、テストプロセスを分析する観点が盛り込まれている。
テストプロセスとは、テスト計画~テスト完了までの一連のテスト活動から成り立つ。

そのテストプロセスは、テストレベルという工程ごとにコンポーネントテスト、統合テスト、システムテストなどで具体化される。
また、テストタイプというテスト種類ごとに、性能テスト、負荷テスト、使用性テストなどの品質特性ごとのテストプロセスもある。
一方、テストプロセスはテスト戦略で規定される。
テストアプローチはPJごとのテスト戦略のインスタンスとみなすから、テスト戦略とテストアプローチは継承関係にした。

テスト成果物層は、主にテスト項目書から成り立つテスト成果物だ。
テスト項目書、つまりテスト仕様書は、下記の観点で分解してみた。

テストアイテムとは何か?概要や定義、現場での使われ方について解説

テストケースを各要素ごとにばらす。
・テスト対象=対象画面・帳票
・テストアイテム=画面・帳票項目
・テストスイート=特定のテストサイクルで実行されるテストケースやテスト手順のセット
・テストサイクル=テストの開始日時、終了日時

ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」では細かい内容が多く、現場で使われる用語と違うので、概念モデルを書かないと理解しにくい。

たぶん、自分のJSTQB_テストプロセスの概念モデルをもっと抽象化して洗練させれば、テストアーキテクチャ設計モデルとマッピングできるだろうと直感している。
この辺りは気づきを残していく。

|

« パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai | トップページ | 日本のアジャイル開発の先人による話が良かった »

ソフトウェア工学」カテゴリの記事

astahによるUMLモデリング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai | トップページ | 日本のアジャイル開発の先人による話が良かった »