テスト観点のとらえ方

19
前へ 1 ・・ 6 7 次へ
しんすく(け) さん。 @snsk

@YasuharuNishi @mkoszk 回帰テストのサイクル???どの周期で回すか、とかでしょうか??

2013-02-14 15:03:32
Yasuharu NISHI @YasuharuNishi

例えば回帰テストの1サイクル目では何をテストするのか、みたいな。 RT @snsk: @mkoszk 回帰テストのサイクル???どの周期で回すか、とかでしょうか??

2013-02-14 15:37:47
しんすく(け) さん。 @snsk

@YasuharuNishi @mkoszk なーるー。詳細設計の時に考えるのですね。

2013-02-14 15:39:23
Yasuharu NISHI @YasuharuNishi

バスケットはアーキテクチャ設計だよ。 RT @snsk: @mkoszk なーるー。詳細設計の時に考えるのですね。

2013-02-14 15:43:58
鈴木三紀夫 @mkoszk

@snsk @YasuharuNishi うん。智美塾では使っていない。

2013-02-14 19:58:29
鈴木三紀夫 @mkoszk

智美塾の定義によると、境界や接点というのは、テスト対象でもテスト目的でも無いので、テスト観点にならない。でも、一般の人に「テスト観点って何?」と問うと、真っ先に挙がるのが境界だ。

2013-02-14 23:10:06
鈴木三紀夫 @mkoszk

少し勉強すると、「境界は技法だよね」と言うようになる。確かに境界値テスト、境界値分析というテスト技法はある。でも、この技法と一つ前のツイートで取り上げた「境界」や「接点」とは少し違う。テスト技法の方が見ているところが狭いのだ。

2013-02-14 23:13:12
鈴木三紀夫 @mkoszk

@kyon_mm そうなんだよね。確かに智美塾の定義とは異なるのだけど、何かを見ているんだよね。システムアーキテクチャ構築の原理にあるビューポイントとパースペクティブのように、見ているし関心事でもあるけれど、異なるものとして定義される何かのような気がしてならないんだ。

2013-02-14 23:18:28
鈴木三紀夫 @mkoszk

境界以外にもある。例えば、エンプラ系などでは、「ロジック(論理)を確認したい」ということがよくある。この場合のロジックとは、ビジネスロジックのことでビジネスルールから導き出されたものである。

2013-02-14 23:21:30
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@mkoszk 「対象の挙動を変える」というビューポイントなんだと理解しています。現実としてプロダクトの仕様書は「どのときにどう動く」が多いので、それを確認するためにはかなり直感的だと思います。

2013-02-14 23:23:39
鈴木三紀夫 @mkoszk

ロジックを見るのだから、テスト技法の種類である「論理テスト」のことを言っていると早合点してはいけない。確かにテストケースを導出するには、DTやCFDといった技法を使うが、「ロジックを見たい」がCFDを使うという意味ではないことは明白である。この「見る」はいったい何を見ているのか。

2013-02-14 23:23:58
鈴木三紀夫 @mkoszk

@kyon_mm パラメータの値や属性値に紐付けられる境界値の場合はそうですね。でも、一般の人が言う場合の「境界」というのは広い意味を持っているようで、「接点」や「共有」も境界の一種として扱っていたりして、なかなか面白いというか、人の認識の不思議さを感じたりします。

2013-02-14 23:27:49
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@mkoszk それも挙動が変わる部分だと思ってるんですけど違うんですかねぇ。

2013-02-14 23:33:06
鈴木三紀夫 @mkoszk

@kyon_mm あ~、言われてみるとそうかもしれませんね。

2013-02-14 23:33:39
鈴木三紀夫 @mkoszk

Qbookのテスト観点を改めてみてみると、悪い意味ではなく、一般の人の言うテスト観点なんだよね。例として挙げられているのは、表示内容、入力チェック、画面遷移。これらのテスト観点の特徴は、ルールを適用すれば比較的初心者でもテストケースを導けること。

2013-02-14 23:49:04
鈴木三紀夫 @mkoszk

僕もこれらの観点をたくさん集め、テストケースの自動生成を目指したこともあったので、意図していることはよく分かります。この取り組みはJaSST東京で発表したこともあるので、知っている人もいるでしょう。でもね。行き詰まるんだな。

2013-02-14 23:53:45
鈴木三紀夫 @mkoszk

まぁ、上手くいかなかったのはSIビジネスだったからかもしれず、第三者検証会社のビジネスモデルならば成功したのかもしれないけど。何が上手くいかないかというと、にしさんが言う良いテストの条件を思い出してもらえれば分かると思うんだ。

2013-02-14 23:55:37
鈴木三紀夫 @mkoszk

少ないテストケースでバグをたくさん見つけるのが良いテストでしょう。これが出来ないんだな。だから方向転換して現在も模索中なんだけどね。

2013-02-14 23:56:17
鈴木三紀夫 @mkoszk

2006年のにしさんの資料。 /テスト観点に着目したソフトウェアテスト設計プロセス [pdf] http://t.co/XKsfHhTc

2013-02-16 01:05:40
鈴木三紀夫 @mkoszk

この資料には、「テストの『観点』とは何だろう? - テスト対象のモデリング」として4つ挙げられている。 1.テスト対象の持つ、テストすべき側面 2.テスト対象が達成すべき性質 3.テスト対象(及び含む世界)を、テストの立場からモデリングしたもの 4.抽象的で、階層構造を持つ

2013-02-16 01:06:35
鈴木三紀夫 @mkoszk

「1.テスト対象の持つ、テストすべき側面」は、智美塾で「テスト対象」と言われているもの。 「2.テスト対象が達成すべき性質」は、智美塾で「テスト目的」と言われているもの。 ここまでは良いのだけど、3と4はちょっと難しい。3はモデリング結果をテスト観点と呼んでいるように読める。

2013-02-16 01:12:02
鈴木三紀夫 @mkoszk

4はおそらくテスト観点が書かれたモデルの性質のことを指しているので、テスト観点と言えるのかどうか。いや、この資料では、「テストの観点とはテスト対象のモデリングである」と言っているので、これでもよいのか。う~む。

2013-02-16 01:15:00
鈴木三紀夫 @mkoszk

品質特性からテストタイプを導くことはよく行われている。ただし、上手くいかない場合もある。

2013-02-16 01:28:35
前へ 1 ・・ 6 7 次へ