探索的テストの難しさに関する議論

鈴木三紀夫 @mkoszk

意地悪テストと探索型テストは違うと思う。意地悪テストとエラー推測は近いと思う。　僕だけ？

しんすく(け) さん。 @snsk

@mkoszk あ。私も意地悪テストはエラー推測(の子？)に近いのかなという印象を持ちました。探索的テストは機能の確認も保証範囲だと私は思ってますので、違うと思います。

しんすく(け) さん。 @snsk

@mkoszk 探索的テストの対象はソフトウェアの実現したい機能全体に及ぶと考えます。下準備なしでそのモデルの分析を行うのでオニのような製品知識と分析結果を妥当なテストのアプローチに落とす実力が必要になる、から、誰でも出来るわけではない、と認識しています。

鈴木三紀夫 @mkoszk

@snsk うん。僕の理解と似ています。なかなか言葉にできない探索的テストを、上手に説明していますね。見事です。

しんすく(け) さん。 @snsk

@mkoszk わー。ありがとうございます。@mkoszk さんにそう言っていただけると嬉しいです！精進します。

かわにし @tosikawa

探索的テストが難しい理由を、誰か分かりやすく説明してくれないかなー。多くの人はイメージで話しているような気がして。

コヤマン @koyaman2

@tosikawa うーん。公式にあまり認められていないため実施すると言いにくいから実践できないところと、対象についての知識が必要なところ、ですかね。@tosikawaさんはどうお考えです？

しんすく(け) さん。 @snsk

@tosikawa 昨夜そんな話を。> 探索的テストの対象はソフトウェアの実現したい機能全体に及ぶと考えます。下準備なしでそのモデルの分析を行うのでオニのような製品知識と分析結果を妥当なテストのアプローチに落とす実力が必要になる、から、誰でも出来るわけではない、と認識しています。

かわにし @tosikawa

@snsk 昨晩の議論で仰ってることはすごく納得しています。でも探索的テストだけをやるわけじゃないですよね。探索的テストでやるべきところを絞ってもダメですか？目的を絞っても全体に関する知識が必要？逆に他の手法だと、製品知識がなくてもテストできるという事でしょうか？

かわにし @tosikawa

@koyaman2 質問返しで申し訳ないのですが、非公式というのは、何的に非公式なのでしょうか？日本であまり採用実績がないということ？JSTQBシラバスとかには載っていますよね。その辺が分かってないんです。なぜか探索的テストというと、過敏な反応が返ってくるような気がしていまして。

しんすく(け) さん。 @snsk

@tosikawa 探索的テスト自体が他のテストベースに基づく設計技法と根本から異なるアプローチなので、比べるのが難しいと思いますが、他の設計技法であれば、テスト分析や設計を行う時点で製品知識は身に付くと思います。テストの実行だけなら、うまく設計されていれば製品知識不要かもです。

かわにし @tosikawa

@snsk なるほど、事前に分析、設計をおこなうと、製品知識に関する学習機会が自然と発生するということですね。それはとても納得です。（つづく......）

かわにし @tosikawa

@snsk ただ、それって探索的テストでは学べないことでしょうか？やり方の問題だったりしません？ペアでテストセッションしたり、セッションを繰り返しおこなって、その合間に作戦会議したりして、徐々に学べたりしませんかね？

しんすく(け) さん。 @snsk

@tosikawa 探索的テストは「テスト技術」は間違いなく前提にしているのですが、「製品知識」まで前提とするかは不明です。新製品の場合成り立ちませんしね。その場合は @tosikawa さんのおっしゃるように、セッションを繰り返して習得していく事になると思います(つづく

しんすく(け) さん。 @snsk

@tosikawa しかし、その場合探索的テストの大きな特徴である「速度」が発揮できない可能性があるので、時間を使えるなら事前にしっかり学んでちゃんとテスト設計したほうが結果的に妥当だったりするかもです。そうなると探索的テストでも出来るけど、メリットが薄い、になるかと。

しんすく(け) さん。 @snsk

@tosikawa 昨夜からここに至るまでのすべての私の発言に言えますが、「探索的テスト」の理解がそもそも私的なものです。メリットは、「早い」、「安い」。デメリットは、「難しい」、「網羅しにくい」、「終わらない」、です。

かわにし @tosikawa

@snsk なるほど！そういう場合も多いでしょうね。ただ、実際に動かすことで得られる情報も多いと思いますがどうですか？テストの対象によっては、実際に動かして得られる情報がインパクト大きかったりしますよね。結局ケースバイケースってことでしょうか。(私的な件了解。自分も私的理解。)

かわにし @tosikawa

皆さんのおかげで自分が何が知りたいか分かってきた。探索的テスト自体について知りたいと言うよりも、何で、探索的テストだけが特別に難しいと言われるのかが知りたいんですよね。事前に分析、設計というアプローチも充分に難しくないですかね。

しんすく(け) さん。 @snsk

@tosikawa ええ、実際に動かして製品を知るというのはすさまじくあると思います。まったくAgreeです。で、実際に触りながら(テストしながら)製品知識を得て、それに基づいて即興でテスト設計→実行というのは探索的テストの基本的なアプローチだと思います。

しんすく(け) さん。 @snsk

@tosikawa 少し前に戻りますが、(他の設計技法であれば、テスト分析や設計を行う時点で製品知識は身に付くと思います)。テストしながら身に着ける、はまさに探索的、な感じですin私の理解。

しんすく(け) さん。 @snsk

@tosikawa 事前にやるのも充分難しいと思います。即興で設計、実装、実行する所、がより難しい部分に思えます。3つお題貰ってその場で落語作る名人芸みたいなイメージ。

あきやま🍠 @akiyama924

@tosikawa 何で、探索的テストだけが特別に難しいと言われるのかというと、「自身の経験から似たパターンの兆候を探索する」からじゃないでしょうか。経験が少ないと探索しようにも何もないというか、そんな感じでは。

鈴木三紀夫 @mkoszk

@tosikawa　探索的テストだけが特別に難しいと言われるのは、他のテストとの比較で「難しい」と説明するという理由もあると思っています。テスト設計をしないでテストするわけですから、アドホックテストと見た目は違いがありません。そのため、探索型テストをより難しく解説しているのでは。

コヤマン @koyaman2

@tosikawa 私も基本的には明示的に探索的テストをやっていないので私的理解を話しています。公式/非公式はレビューのそれと同じようなイメージです。事前準備、ドキュメント、プロセス。(つづく)

コヤマン @koyaman2

@tosikawa で、日本での実績というのもあると思いますが、まず探索的テストやりますと言った時にアドホックなテストと誤解を受け、拒絶反応を起こしやすい(文化的問題かも)。説明も難しいです。(つづく)