勝手にゆもつよ勉強会に参加した時のメモです。
※自分の関心がテストカテゴリに偏っていたので、そこに関することが多いです。
今日ミッキーさんが言われていたことをメインで書いています。
- テストカテゴリは、テストタイプを具体的にしたものである
- ドメイン特有のものになることもある
- 対してテストタイプは、実施するテストの種類であり、汎用的なものである
- テストカテゴリを作る目的は、テスト条件を出すためである
- テスト分析マトリクスを作ることで、テスト全体を俯瞰的に見ることができ、偏りや抜けを発見しやすくなる
- 論理的機能構造のような参照モデルは、テストの抜け漏れを防ぐために使う
- １つのフィーチャーに対して、参照モデルが紐づけられる（Twitterで討論中→参照モデルはフィーチャーにではなく、テスト対象に結びつく）
- 参照モデルはドメインによって変えて良い。（みっきーさんの意見。変えればゆもつよメソッドではなくなる）内部的な構造やアーキテクチャがわかるようならそれを使ってもいい。ただしそのまま使うのではなく、テストしやすい形に"翻訳"すると良い
- テストカテゴリは「テストしたら欠陥がありそうな分類」である→ちょっと違う。テストしたら見つかると思われるインシデントで分類の意味を合意する。参照モデルをテストしやすい形に"翻訳"した分類
- テストカテゴリとしてちょうどいい抽象度がどの程度かわからないのは、リバースエンジニアリングをした経験がないから
- 参照モデルの各要素を元に、どんな欠陥があるだろうか？と考えてテストカテゴリに落とし込む。逆に言えば、テストしても欠陥が全くでなさそうな分類はテストカテゴリには出てこない→そうとも限らない、とのこと。
- テストカテゴリはテスト観点なのか？→テストしたいところ＝テスト観点と定義するならば、テスト観点の一部がテストカテゴリであると言える。
- テスト観点と一口に言っても色々あって、テストカテゴリの一部になり得るものもあれば、それこそパラメータレベルのものもある
- テストカテゴリを作る時にハマりやすいのが、非機能系のテストカテゴリを作ろうとしてパラメータレベルのものを出してしまうこと。（ex. 大量のユーザー、など）この場合は、一つ上の抽象度に引き上げるようにするとうまくいく。もう一つは、フィーチャーを参照モデルの各要素（湯本さんは"小機能"という言葉を使っていたが、飲みの席だったので不本意な表現かもしれない）に分解したものがテストカテゴリになることを理解する必要がある。フィーチャー（マトリクスの縦軸）に出てくるものと横軸（テストカテゴリに出てくるもの）がごっちゃになるとうまくいかない
- テストカテゴリは「テストしたいことを列挙」した結果出てくるもの
- 参照モデルを使って抜け漏れを防ぎつつ、フィーチャーのテストすべき側面はどこなのか、もしくは欠陥がありそうなところはどこなのかを考えてテストカテゴリを出す。これに対してメンバーで話し合い合意を形成する。正解があるものではない
何か違っていたらご意見ください。
※ちょっとメモにしても見辛すぎるのであとで整理します...
→このほうが勉強会帰ってからすぐ書いた感あるのでこのままにしておきます。
