10周年のSPコンテンツ!
2
Yasuharu NISHI @YasuharuNishi
テスト観点についていくつか分からないというご質問を頂いたので、まずは簡単に答えてしまいましょう。
Yasuharu NISHI @YasuharuNishi
質問1「テスト観点って何だか分からない」 回答:テストケースをテスト条件、テスト対象、期待結果などに分解して下さい。それらを抽象化したものがテスト観点です。具体的な値は含みません。
Yasuharu NISHI @YasuharuNishi
例えば三角形の種類を判定するプログラムのテストにおいて、(3,3,3)はテスト観点ではありません。具体的な値だからです。(3,3,3)を抽象化すると例えば「正三角形」になりますね。この「正三角形」はテスト観点です。それをさらに抽象化した「三角形の種類」もテスト観点です。
Yasuharu NISHI @YasuharuNishi
テスト観点って何だかよく分からないという方は、とりあえず「テストケースを分解して抽象化したもの」と考えて下さい。まずはそこから始めましょう。
Yasuharu NISHI @YasuharuNishi
一方、そのことは重々分かってるんだけどよく分からん、という、どちらかというとソフトウェアエンジニアリングを修めた(?)方からの疑問もあります。きょんくんさんとか太田さんなんかはこのタイプだと思います。
鈴木三紀夫 @mkoszk
@YasuharuNishi 2つある。 一つは、従来の仕様網羅+テスト技法適用型とは、まったく異なる考え方を必要とされているので、それに対する困惑。 もう一つは、「テスト観点」という言葉を戦略的に曖昧にしているために、厳密な設計への障壁になっているが故の困惑。
Yasuharu NISHI @YasuharuNishi
なぜなら、テスト要求分析(やテストアーキテクチャ設計)におけるテスト観点について議論しているからだと思います。クラスを構造体のようなものだと考えるレベルの人と、OOAで考えるレベルの人の、クラスに対する理解度の差だと私は認識しています。違うかもしれませんが。
Yasuharu NISHI @YasuharuNishi
TRA(テスト要求分析)でテスト観点をモデリングしようとすると、そもそもその時点でテストケースは考えてないわけですから、「抽象的なテスト条件など」という捉え方はできないわけです。思考がバックトラックになってしまいます。
Yasuharu NISHI @YasuharuNishi
するとTRAにおけるテスト観点は何ですか、という問いになるわけですが、そうすると「テストにおける関心事で、将来ブレークダウンするとテストケースになるやつです」みたいな言い方になってしまいます。でもこれでは全然分からないので、具体的な例示で曖昧な定義をカバーしようとしています。
Yasuharu NISHI @YasuharuNishi
例えば、負荷、構成、性能などはテスト観点であり、納期、エンジニアスキル、単価などはテスト観点ではありません。でもそうすると「テストタイプとどう違うの?」という問いが出てきます。
Yasuharu NISHI @YasuharuNishi
まぁテストタイプとどう違うの、という問いに対しては、テストタイプというものの定義が実はきちんとなされてないのよね、というこちらの困惑もあるわけなんですが、ともあれ。
Yasuharu NISHI @YasuharuNishi
テストタイプはテスト観点のグループで、シンプルなテスト設計の場合やテスト観点の抽象度が高い場合は、ひとつのテスト観点が一つのテストタイプを意味することもあります。でもこの回答って、違いに答えてないんですよね。
Yasuharu NISHI @YasuharuNishi
VSTePではこの問いに答えるために、テストコンテナという概念を準備していますが、それはまた今度ゆっくりどこかで。
Yasuharu NISHI @YasuharuNishi
TRAにおけるテスト観点の定義を厳密に行うことには功罪があります。厳密に行うと、ソフトウェアエンジニアリングを修めたタイプの方々にはスッキリして使いやすくなります。
Yasuharu NISHI @YasuharuNishi
しかしソフトウェアエンジニアリングを修めていない多くのテスト現場の方々には、厳密な定義は邪魔です。彼らが現場でテスト設計の際に考えていることを排除してしまったり、「これはテスト観点なのか」という形而上的な問答に無為に時間を取られてしまうからです。
Yasuharu NISHI @YasuharuNishi
そのトレードオフを考えた結果、テスト観点の定義は曖昧なままにしておいて、現場で様々なこと、もしかしたらテスト観点ではないかもしれないことも含めて、を考えている人たちに、自分たちがテスト設計の際に考えていることをモデルとして図示してもらう、という選択を私はしています。
Yasuharu NISHI @YasuharuNishi
誤解を怖れずに一言で言うと、テスト観点という言葉を厳密にすると間口が狭まり、TRAやTADをすべき現場のエンジニアを困った状態に取り残すことになります。
Yasuharu NISHI @YasuharuNishi
その一方で、妙な解釈やモデルが流通するという問題もありますね。この問題については、むしろ、TRAやTADのモデルがどんどん流通するようになるとエンジニアの目が肥えていき、ちょうどよい厳密さのテスト観点の定義に関する議論が起こるだろう、と予測(期待)しています。
Yasuharu NISHI @YasuharuNishi
その、テストエンジニアの目を肥やしたり、議論の材料を提供するプラットフォームの一つがテスト設計コンテストだったりもするわけです。
Yasuharu NISHI @YasuharuNishi
ただ、テスト観点の定義を曖昧にするだけでは、ロクでもないテスト設計しか生まれません。それでは困ります。そこで、テスト観点は色々あるのを許しておいて、よいTRAやTADのモデルをつくるための道具立てを用意する必要があります。
Yasuharu NISHI @YasuharuNishi
それが例えばVSTePでは、関連のステレオタイプ(分析)であり、MECE分析や確定であり、(ビューの)スタイルやパターンであり、TADの品質特性です。
Yasuharu NISHI @YasuharuNishi
というのが私のスタンスです。これをみっきーさんは「戦略的に曖昧にしてる」と仰いますね。
Yasuharu NISHI @YasuharuNishi
次にこのご指摘に答えますね。 RT @oota_ken: オブジェクト指向分析では正三角形がクラスだとしたら三角形の種類の定義はそのクラスのパワータイプです。抽象化という言葉で同じテスト観点としてまとめてしまっているのがわかりにくさを産んでいると思います
Yasuharu NISHI @YasuharuNishi
テスト設計をするときに「正三角形の種類はクラスかパワータイプか」という悩みに時間を費やして実りがあるほど、いまの(日本の)テスト設計者のモデリング能力は高くありません。
Yasuharu NISHI @YasuharuNishi
現在は、例えばその2つは区別せずにテスト観点として扱い、むしろ詳細化(抽象化)の種類をきちんと区別して理解することでMECE性を向上する方が、テスト設計にとっては実り多いと考えています。
残りを読む(23)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?

ログインして広告を非表示にする
ログインして広告を非表示にする