VSTePとHAYST法におけるテストアーキテクチャのタイミングの話
- NoriyukiMizuno
- 3861
- 8
- 2
- 7
@NoriyukiMizuno テスト観点出しとテストアーキテクチャーの順番についての話をしているのにどちらが先でも駄目と(秋山が)いうのは変ですよね。
2016-10-25 20:21:49その場合、先にテストアーキテクチャを組み切るのではなく、通ってきた道を振り返ったら良いテストアーキテクチャができていた、という感じになります。でも最初に何も無かったわけでもないんですよね…。
2016-10-25 20:22:20@NoriyukiMizuno 結論から言うと、HAYST法ではテストアーキテクチャーは作らず、テスト観点出しは2回に分けています。
2016-10-25 20:23:27ともあれ、色んな進め方があってよいのだと思います。VSTePと呼ぶ必要はないので、皆さんの思う「よい進め方」を教えてください。どんどん皆で共有しましょう! (^_^)
2016-10-25 20:23:48まだまだVSTePも僕も発展途上なので、皆さんに色々教えて欲しい!HAYST法は2回… _φ(・_・
2016-10-25 20:26:34@NoriyukiMizuno HAYST 法のプロセスは、 1. 6W2H で因子を粗くだす 2.FV 表でテスト対象を小さく分解する 3. ラルフチャートで因子を細かくだす (4. FL表で水準を確定する) です。
2016-10-25 20:26:36@akiyama924 1.で因子を粗く出した段階か、2の作業後にモデル整理すると、テストアーキテクチャ相当のものになるのではないでしょうか?
2016-10-25 20:35:58@NoriyukiMizuno どうして因子(テスト観点でも良い)の抽出を2段階にしたかと言いますと、実際のバグの発生条件を調べるとシステム全体の6W2Hのツリーにはその条件が出ていなかったからなのです。 出ていないのだから6W2Hをさらに分解するアプローチもあったのだけれど。
2016-10-25 20:41:14@NoriyukiMizuno あったのだけれど、その時、すでにかなりたくさんのノードがあるツリーだったのです。 また、バグを発生させる条件にはドメイン知識や内部設計情報が不可欠で、もう、一人が6W2Hを描くのは無理と諦めたのです。
2016-10-25 20:43:50@NoriyukiMizuno なので、ドメイン知識を持つ人にテスト開発作業を分担する必要がありました。 で、目的機能単位にリストを作ろうと。それがFV表です。
2016-10-25 20:45:57@NoriyukiMizuno 目的機能単位、今で言うユーザーストーリー単位に開発物を分けられたらテスト開発作業も分担できると言うわけです。
2016-10-25 20:47:23@NoriyukiMizuno 分担後にFV表にある検証列の因子を見てテストが書けたらそれでよいし、書けない場合は、ドメイン知識と内部設計情報を使ってラルフチャートを作れと。 HAYST 法はそういう手法です。
2016-10-25 20:49:18@NoriyukiMizuno VSTePもどきを何度かしたのですが、一人で済むようなソフトウェアの場合は、全く問題ないのですが、一人で済まないときにテスト観点の分解をどこまでしようか?もう、たいした知見もないのに分解しているなあとか、アーキテクチャーの正しさとかわかんねーと。
2016-10-25 20:53:46@NoriyukiMizuno うん。それは、VSTePの問題ではなく、私の悩みであって、だから、悩みという書き込みに反応したのでした。 おしまい。
2016-10-25 20:54:53@NoriyukiMizuno テストアーキテクチャーの必要性を感じないのです。 だから単なるリストなのです。 FV 表で小さいテスト対象となっているので。
2016-10-25 20:57:19@Kiz_Sugiyama 操作のパターンもそうです。たとえばプリンターのテストとしたときに、そういう操作のパターンまでツリーには描いていなかったのです。
2016-10-25 20:59:48@akiyama924 状態遷移図にエラー処理を盛り込もうとすると、途端に図が多次元化(あるいはテンソル化)してしまうことがあるのですよね。
2016-10-25 21:02:06@akiyama924 必要ならリスクなりで優先順位が判断できるようにするリストで十分で、アーキテクチャのような図にはする必要が無いんですね。 図で構造を考えるメリットがある程度ないと必要ないかもですね。。
2016-10-25 21:04:05