VSTePとHAYST法におけるテストアーキテクチャのタイミングの話

VSTePのテストアーキテクチャについて悩ましく感じていたところに、VSTePとHAYST法の両方からの意見を頂きました。
5
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno テスト観点出しとテストアーキテクチャーの順番についての話をしているのにどちらが先でも駄目と(秋山が)いうのは変ですよね。

2016-10-25 20:21:49
Yasuharu NISHI @YasuharuNishi

その場合、先にテストアーキテクチャを組み切るのではなく、通ってきた道を振り返ったら良いテストアーキテクチャができていた、という感じになります。でも最初に何も無かったわけでもないんですよね…。

2016-10-25 20:22:20
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno 実はHAYST法でかなり悩んだところなのです。

2016-10-25 20:22:33
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno 結論から言うと、HAYST法ではテストアーキテクチャーは作らず、テスト観点出しは2回に分けています。

2016-10-25 20:23:27
みずのり:jack of all trades @NoriyukiMizuno

あ、とても濃い感じになってきたー

2016-10-25 20:23:40
Yasuharu NISHI @YasuharuNishi

ともあれ、色んな進め方があってよいのだと思います。VSTePと呼ぶ必要はないので、皆さんの思う「よい進め方」を教えてください。どんどん皆で共有しましょう! (^_^)

2016-10-25 20:23:48
Yasuharu NISHI @YasuharuNishi

まだまだVSTePも僕も発展途上なので、皆さんに色々教えて欲しい!HAYST法は2回… _φ(・_・

2016-10-25 20:26:34
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno HAYST 法のプロセスは、 1. 6W2H で因子を粗くだす 2.FV 表でテスト対象を小さく分解する 3. ラルフチャートで因子を細かくだす (4. FL表で水準を確定する) です。

2016-10-25 20:26:36
みずのり:jack of all trades @NoriyukiMizuno

(これはツイートまとめておいた方が良い流れっぽい)

2016-10-25 20:28:18
Yasuharu NISHI @YasuharuNishi

…cont) ラルフチャートで因子を細かくだす (4. FL表で水準を確定する) です。

2016-10-25 20:31:24
みずのり:jack of all trades @NoriyukiMizuno

@akiyama924 1.で因子を粗く出した段階か、2の作業後にモデル整理すると、テストアーキテクチャ相当のものになるのではないでしょうか?

2016-10-25 20:35:58
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno どうして因子(テスト観点でも良い)の抽出を2段階にしたかと言いますと、実際のバグの発生条件を調べるとシステム全体の6W2Hのツリーにはその条件が出ていなかったからなのです。 出ていないのだから6W2Hをさらに分解するアプローチもあったのだけれど。

2016-10-25 20:41:14
杉山 兆 @Kiz_Sugiyama

@akiyama924 ボク達の職場で頻発する、「考えが及ばなかった操作のパターン」というヤツなんでしょうか…

2016-10-25 20:43:17
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno あったのだけれど、その時、すでにかなりたくさんのノードがあるツリーだったのです。 また、バグを発生させる条件にはドメイン知識や内部設計情報が不可欠で、もう、一人が6W2Hを描くのは無理と諦めたのです。

2016-10-25 20:43:50
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno なので、ドメイン知識を持つ人にテスト開発作業を分担する必要がありました。 で、目的機能単位にリストを作ろうと。それがFV表です。

2016-10-25 20:45:57
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno 目的機能単位、今で言うユーザーストーリー単位に開発物を分けられたらテスト開発作業も分担できると言うわけです。

2016-10-25 20:47:23
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno 分担後にFV表にある検証列の因子を見てテストが書けたらそれでよいし、書けない場合は、ドメイン知識と内部設計情報を使ってラルフチャートを作れと。 HAYST 法はそういう手法です。

2016-10-25 20:49:18
みずのり:jack of all trades @NoriyukiMizuno

(イメージ出来た。自分のやり方とあってる部分も結構あるかも)

2016-10-25 20:52:38
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno VSTePもどきを何度かしたのですが、一人で済むようなソフトウェアの場合は、全く問題ないのですが、一人で済まないときにテスト観点の分解をどこまでしようか?もう、たいした知見もないのに分解しているなあとか、アーキテクチャーの正しさとかわかんねーと。

2016-10-25 20:53:46
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno うん。それは、VSTePの問題ではなく、私の悩みであって、だから、悩みという書き込みに反応したのでした。 おしまい。

2016-10-25 20:54:53
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@NoriyukiMizuno テストアーキテクチャーの必要性を感じないのです。 だから単なるリストなのです。 FV 表で小さいテスト対象となっているので。

2016-10-25 20:57:19
あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@Kiz_Sugiyama 操作のパターンもそうです。たとえばプリンターのテストとしたときに、そういう操作のパターンまでツリーには描いていなかったのです。

2016-10-25 20:59:48
杉山 兆 @Kiz_Sugiyama

@akiyama924 状態遷移図にエラー処理を盛り込もうとすると、途端に図が多次元化(あるいはテンソル化)してしまうことがあるのですよね。

2016-10-25 21:02:06
みずのり:jack of all trades @NoriyukiMizuno

@akiyama924 必要ならリスクなりで優先順位が判断できるようにするリストで十分で、アーキテクチャのような図にはする必要が無いんですね。 図で構造を考えるメリットがある程度ないと必要ないかもですね。。

2016-10-25 21:04:05
みずのり:jack of all trades @NoriyukiMizuno

いろいろ参考となった感。背景含めて考えると繋がりますよね。

2016-10-25 21:07:11