電源がない会場でメモを取るときは、ポメラを使っています

まつやまです。

先日のテスト酒場で「ポメラ使ってます！」というお話をしたところ、「それ良いかも！」というコメントをいただいたりしました。 誰かのお役に立つかもしれませんので、こちらに書いてみたいと思います。

ポメラとは？

www.kingjim.co.jp

テキストでメモを取ることに特化した端末です。

テキスト入力＆保存以外の機能としては、フォルダ作成機能・ファイル名編集機能・英和＆和英辞書機能などがあります。

どんなところが良いの？

  • 外部電源を必要としない＆それなりに長持ち

ノートPCに比べて圧倒的に長時間使えます(レッツノートとは良い勝負かも)。 僕が持っている機種(DM100)は、単三電池を使いますが、最新機種は内部バッテリーで動くようです。 勉強会の会場は、電源がない場合も多いと思いますので、そんなときに重宝します。

  • 軽くて薄い

(僕が持っている機種(DM100)の場合)重量が400g＆厚さ2.5cmなので、持ち運びがとても楽です。 ノートPCに加えてポメラを持っていったとしても、特に邪魔になりません。

微妙なところは？

  • 本体がお高い

最新機種を見てみたところ、¥49,800しますね。正直、お高い。 僕が持っている機種(DM100)は¥20,000くらいだったと思いますが、古い機種の取り扱いはなくなっているようですね。

  • ちょっとタイピングしづらい

ノートPCに比べるとキーの幅が狭いため、どうしてもタイピングはしづらいです。

まとめ

最新機種を買おうとするとさすがにハードルが高いかなという印象ですが、「電源の心配をしなくて良い」という安心感は案外大きいです。量販店だとデモ機が置いてあったりしますので(だいたい電子辞書のコーナーにいる)、ちょっと触ってみてはいかがでしょうか。

書きたいことの圧縮版

まつやまです。JaSSTで一気にお知り合いが増えまして、嬉しい悲鳴をあげております。 書きたいことが色々とありすぎて、ちゃんと書こうとするとずいぶんと先になってしまいそうですので、ざざっとダイジェスト的にまとめておこうと思います。

テストコミュニティのSlackを作っていただきました

yoshikiito.net

なんだかすごいことになっています。以下は伊藤さんのブログからの引用です。

Slackのほうの「はじめまして」用ルームでも出てきましたが、「テストについて、品質について、普段話せる人がいないので、社外で交流したい」という方が一定数いらっしゃるようです。Twitter上なんかだと、テストや品質について話をしている人が目立つこともあって、いたるところに居るような錯覚をしていました。

実際には、職場でもんもんとしたまま、同じ思いを持つ仲間を求めている人がいるということ。なら、場があったほうがいいなと。作ってから気づきました。

この感覚はまさに自分自身が抱え続けてきた悩みで、テストについてはもう何年も「ぼっち」で仲間を求めていました。 転職して、QAと呼ばれる方が世の中にいることを知って、少しずつ「分かり合える人」が身の回りに増えてきたように思います。 これは僕なりの越境だったのかもしれません(何となくいい言葉で締めたかった)。

インフラ勉強会

個人的に、いまものすごく注目しているコミュニティです。

· / インフラ勉強会 Wiki

とにかく参加者の方の熱気＆盛り上がりがすごいです。毎日でも参加したくなるくらいです。 いまも、インフラ勉強会にROMで参加しながらブログを書いています。

断片的に覚えていた知識が線になって繋がっていく感覚があって、とても楽しいです。

カイゼン・ジャーニー

たしかデブサミが開催された頃に買った本です。 2/27にワークショップが開催されたので参加してきたのですが、こちらも著者のお二人の熱気に圧倒されまして、何とか社内でも読書会を開けないか企画を考えています。

JaSST 1日目

  • 「NGTの記法を応用した不具合分析からのテストの補強」

フレームワークを用いてつながりの無い要素をつなげ、検知しづらい不具合を検知する手法のお話です。こちらも是非実践してみたい内容でした。

JaSST 2日目

状態遷移図を用いて仕様を見やすくする手法のお話でした。数学的な抽象化を用いた記法や、独自言語のお話もあり、こちらもしっかり時間をとって復習しなければ、、、と思う内容でした。「ツールに読ませるためにデータ化する」というのは、やはり大事な考え方だなと感じました。

  • 「組織改善のためのPMOのあり方とPMOの育成に関して」

PMOの分類や育成についてのお話を伺うことができました。PMOってどうしても事務屋さんなイメージがつきまとうのですが、何だかなあ。。。と思います。本来もっと魅力的でリスペクトされるべき役割であるはず。

  • Clova Friends

まさかの抽選に当選してしまいまして、Clova Friendsをいただいてしまいました。Google Homeとはちょっと異なる特性を持っていて、特に、ちょっとした人間くささみたいなものを感じることがあります。意外な言葉に反応してくれると本当に面白いですね。マンガネタは結構刺さりました。

基調講演と同様、辛辣な正論を真正面からお話しいただいたという感想になりました。テストを書くということをきちんと学ばなければ、という思いをあらためて持ちました。

今回のJaSSTで最も「ついていくのに必死(というかお話についていけない)」セッションになりました。トップ企業のコンテキストを理解したうえで聴講しないとダメ。それでも、ハッシュタグの実況解説のおかげで、最後まで諦めずに聞くことができたと思います。

最後の山口さんのコメントは、とても印象的でした。

「他人の答えを借りる前に、自分たちで何をやるべきかをきちんと具体的に考えて、それをきちんとやりきることが大事でしょう。私たちが特別だとかそういうことじゃない(意訳)」。

他人から借りてきた答えは便利な道具ですが、その便利さに呑まれないよう自戒したいです。

技術的な活動いろいろ

そんなわけで、インフラ勉強会を聴講したり、コード書いたり、ターミナル触ったり、いろいろやっています。 もうちょっと時間配分を上げていきたいところです。あと、注力するものを絞ったほうが良さそう。

テスト観点を語る夕べ

kataruyube.connpass.com

2ヶ月ぶりの「語る夕べ」に参加してきました。会のコンセプトどおり、「ビジネスとしてどうすれば効率的か」とかそういった範疇を飛び越えて、「どうやったら気持ちいいか」「テスト観点を出す作業はアート」といった形で話が発散していきました。自分の常識が足元から崩れていく感覚がとても楽しかったです。いくつか質問もさせていただいて、自分の思考プロセスを知る良い機会になったと思います。立ち止まって振り返る(分析する)って、やっぱり面白いなと思います。

JaSST '18 Tokyo【C4】「探索的テストにおけるストーリーベースのアプローチ」聴講メモ

内容まとめ

  • 探索的テストに、ストーリー仕立てのガイドを設定することで、不具合検出率を上げられないか試してみた
  • 結果として有為な差異はなかったが、事前準備やサンプル数に不足を感じており、今後に繋げていきたい

感想

  • 人ごとに探索スキルに差異があることを前提として考えると、一律に誰にでも適用できそうなメソッドではないと感じた
  • ただ、単純に内容としてはものすごく面白い
  • 個人的にはまずチャーターの概念を習得することが先だが、チャーターの発展系をイメージするうえで、今回のセッションはとても刺激を受けた

聴講メモ

人間に着目した探索的テストの提案

  • 即効性はないよ
  • これの発展系をだれかが発表してくれることを期待
  • そもそも探索的テストって？
  • 探索的テストのモデル
  • 事前や最初に思いついたテストケースを流すだけではアドホックだと思う
  • テスト実行後のふるまいをよく観察して、そこからさらなるテストにつなげる

問題定義

  • いかに、テスト実行者の直感・感情・知識・経験を引き出すか
  • 指針
  • テストチャーターを工夫する
  • ツアーのメタファー
    • ガイドブックツアー
    • ランドマークツアー
    • など＞行動の指針
    • が、イメージしづらい
  • ツアー形式をやってみてのインタビュー
    • チャーター作成者の思い
    • テスターの考えや実施範囲
  • 探索しているうちに機能を飛び越えてしまうことがある
    • チャーター適合率を報告してもらっている
    • やったことを指摘するような言い方はダメ
    • チャーターに従う必要はない、としておく
  • テスト管理者の負荷がすごい

課題感

  • テストの意図が伝わりづらい
  • スコープを逸脱する
  • テスト実行者のノウハウを引き出せていない

対策

  • 三幕構成でプロット＝チャーターを書く
    • 設定
    • 伏線
    • 解決
  • 伏線の例
    • XX画面には、最近仕様変更が発生していた
    • 前日に特殊な運用をしていた

やってみてどうだったか

  • 有意な差はなかった (>_<)
  • マインドマップの差
    • ツアーのほうが、幅広く思考できていたようだ
    • 提案手法のほうが、深く思考できていたようだ
  • アンケートの結果としては、ツアーよりは提案手法のほうがわかりやすいという意見が多かった
    • 反省：実験前にテスト実行者の属性を調べていなかった
    • アプローチとしては面白いと感じた

今後試してみたいこと

おわりに

  • もっと人間に着目してみるとよいのかも

質問

  • なにを抽出するための探索的テストなのか
    • テストチャーター作成者による
  • 思考を縛りすぎなのかも
    • いい塩梅はこれから探りたい
  • 質はどうだったのか
    • ほぼツアーと差がない
  • モブテストペアテストをやってみて片方黙っている

JaSST '18 Tokyo【A3】「テスト会社のテストリード達はどのようにテストを成功に導いているのか？」聴講メモ

聴講メモ

「テストってどんなところが面白い？」

  • 狙ったところで不具合を見つけたとき
  • 不具合を見つけたときはうれしい
  • 出る前につぶせたときはうれしい
    • どこにアンテナをたてている？
    • ユーザがどう使うか、開発者ならどう作るか　を気をつける
    • 開発者が作るような分析成果物と同じものを作っても効率はよくない
  • 考えて発想して工夫するところ

「みなさんにとって良いテストとはどんなテストですか？」

  • テスト目的がはっきりしているテスト
    • 形骸化はダメ
  • 再現性が保たれているテスト　目的がはっきりしている
  • 期待値がはっきりしている
  • テスト戦略とのトレースができている
    • 説明できるテスト　他人がみてわかるテスト
  • 編集者
  • 第一条件として「楽しそうにやっている」
  • 開発のこともわかっている
  • 状況を客観的に見ることができる
  • 不具合が残っていたとしても、ユーザーの問合せ対応が迅速であれば、顧客満足はあがるはず そういう価値もあるはず

「自分はこう成長してきた！チームメンバーをどう育てるか？」

  • 独学でがんばって、社内にできますよアピールした
  • それを他の人に強いるのは難しい
  • 10人に1人でも引っかかれば。
  • マネジメント的にいうと、ひとりひとりに得手不得手がある
  • 新しいことが始まるときによくアサインされる
    • 課題が多かった
    • テスト設計コンテストに出た
    • テスト観点って何なんだろう、といったことを考えた
  • 育成は難しいと感じる

「20年後 (先輩がいない、自分が第一人者のとき)テストの世界にいる自分は？」

  • 自分なりの答えを出せるエンジニアになりたい
  • 製品価値を高めることができるようになりたい
  • もともとのオーダーが100として、それが現実としてマイナスになって、それをどう100に戻すことを目指し、さらに付加価値を高めていきたい
  • ユーザーの立場で　UXも大事
  • テストはなくならない　テストはしないといけない
  • テストの手段にあった組織作りが大事
  • テストエンジニアがフリーになるかも
  • アジアのエンジニアで一緒にやろうぜみたいなことも今後起こってくる

感想

  • 欲を言えば場外乱闘的な何かを見たかったです

JaSST '18 Tokyo【E2】「やってみよう！探索的テスト ～ハイクオリティな妄想の高速ループ～」聴講メモ

内容のまとめ

  • 実際にアプリケーションを操作して探索的テストを体験できるセッション
  • 状況によって、スクリプトテストの実装よりも短時間で高い効果が得られる
  • 「アプリケーションの挙動」という学びをインプットに、「ユーザーが現実的にどう行動するか」を想像して、次のアクション(≒テスト設計)を考えると良い
  • 時間を区切らないと費用対効果が悪くなってくるので、タイムボックスで切るのがおすすめ

感想

  • バグ出しを始めると一種の「ハイ」になってしまい、「ユーザーが現実的にどう行動するか」の想像が後回しになってしまった(なので、チャーターなどを使った舵取りが必要ということに納得)
  • 今回のセッションでは体験しきれなかったが、テストキックオフ〜テスト振り返りのサイクル＋チャーターというフォーマットを実際に回してみたい

聴講メモ

  • 燻製をつくる人と食べる人のペアで探索的テスト
  • 似た言葉 探索、散策、冒険、探検、徘徊
  • ただ何となく徘徊するのは薄い ハードウェア壊すような冒険はやりすぎ
  • 探索的テストとは問診に近いイメージ
  • 今回のセッションは、自由度が真ん中から下寄りの探索的テスト
  • チャーターは手順ではなく指針
  • 探索的テストは、テスト設計はするけどテスト手順のドキュメント化はしない
  • 探索的テストとスクリプトテストをどう組み合わせるか
  • チビファ○ヤー○リオ
  • 探索的テストは「おもしろい！」
  • 手がかり＞ユーザーが実際にどう使うか想像する＞動かす
  • 「テスト実施」だけの状態(アドホック的)＞「テストキックオフ」＆「テスト実施」＆「テスト振り返り」のサイクル
  • 今回のセッションでは、探索的テストは「トレーニングを十分受けたテスト担当者」によってなされる、と定義している。ドメイン知識やテスト技法があると効果的

JaSST '18 Tokyo 「Advances in Continuous Integration Testing at Google」聴講メモ

内容のまとめ

  • Googleではすべてのテストを自動化している(UXに関するテストは例外)
  • CIのスケジューリングに対する取り組み&(効果は維持したまま)コストを削減するための取り組み
    • 変更の影響を受けない機能はテストしない
    • 過去のテスト結果を蓄積する
    • テスト結果を「状態」として時系列で記録し、変化がないものはテストしない
    • マイルストーンの設置頻度を減らす
  • 「Flakyなテスト」への対処
    • コード自体の変更が行われていないのに、テスト結果が変化したものを抽出→開発者にフィードバック

上記を支えるための文化

  • テストは書いて当たり前
  • テストを書きやすい設計を考えるのは当たり前
  • 再利用性のないテストだろうが自動テストを書くのは当たり前

感想

  • Googleは、良いプラクティスと言われていることをただ愚直に現実世界に持ち込んでいるだけ、という印象を受けた
  • 取り組みを評価するための数値化を、真摯に行っているという印象
  • ただそれだけのことがどうしてこんなにも難しいと感じるのか

聴講メモ

  • 1件あたり35回のテスト
  • 分散化してテスト
  • マニュアルQAは一切ない
  • 非常に高速
  • 非常に頻繁にプロダクトをリリース
  • テストの99％は合格
  • かなりお金をかけている
  • テストの文化を根付かせる
  • トイレに貼っている　ヒント　結構有効
  • テスティングブログ
  • 新規採用　一日目からテストを書いてもらう
  • QAを別部門としていない
  • 1チーム8人に1人か2人がテスト担当
  • テストのフレームワークを作る
  • 新しいシステムテストというものを追加するためにテストを整える
  • ST　という役割の人間が土台づくりをしている
  • 手作りの自動テストが主流
  • どうやってテストを選ぶのか　450万のテストをすべてするのか
  • 依存性関係を示したグラフ　図　を使って選定している
  • 影響を受けるテスト
  • バックエンドで同時並行
  • 変更リスト　IDをつけて2年間保管　パターンなどが見えてくる
  • キャパシティがあいたら　マイルストーンを区切って　その時点までの変更がテスト対象になる
  • 結果が出る
  • どの変更で緑から赤に変わったのか
  • パスからフェイルに移行した変更を見つける
  • 回帰テスト
  • 少数の変更ですべてに影響してしまう　すべてがそれに依存しているから
  • 実行しないテスト　ほとんどの問題は0.2%の箇所で起きる
  • リソースを節約するために、分析をする
  • 変更の半分は38のテストに影響する
  • 100％で400万のテスト
  • このテストが安心か否かをどう見極めるか
  • 赤い　フレーキー
  • 黒い　ビルド失敗
  • 現在のシステムは非常にコンサバです
  • マイルストーンの間の時間がある
  • いちマイルストーンは40分くらい
  • グリーンライクなサービス
  • インコンクルーシブ
  • 100％グリーンでなくても確信レベルに近ければリリースする
  • 新しいスケジューリングのアルゴリズム
  • 不合格を見落とすリスクはある
  • 少ないリソースでトランジションを見つける
  • テストをやめればよい
  • スキップするのが安全であるとはどういう意味か
  • パスという状態とフェイルという状態の遷移
  • フェイル＞フェイルもスキップして「よい」対象
  • パス＞フェイルは「安全でない」
  • パス＞スキップ＞フェイルの場合は「チェンジ2かチェンジ3が問題」
  • マイルストーンを少なくする
  • スマートスケジューラが悪い状態遷移を検知する
  • テスト戦略　テストコストを低くしたい
  • 遷移を見逃すリスクをおさえる
  • 遷移がなければテストは安全
  • どれだけの遷移を見逃すのか
  • 新しい戦略の評価
  • 2年間のデータ
  • インターンの方が作成した図
  • 3本の線
  • 横軸はスキップレート
  • 100％スキップしても0にならない
  • 90％以上の場合、テストをしなくても遷移は見つからない
  • オプティミスティック
  • 遷移がわかっているものはスキップする
  • 0.2％のみ実行する
  • 失敗するのがわかっていてもスキップしない
  • 中央の線は無作為
  • 直線にならない
  • 確率分布によるもの
  • フレーキーなテスト
  • 同じコードなのに、テストのパス/フェイルが両方出る
  • フレークの不合格は、リリースの支障となる
  • デベロッパーはフレーキーを無視する
  • 1ヶ月分のデータ
  • パスからフェイルの遷移の84％がフレーク
  • コードの変更が問題ではない
  • ブレークが起こっているのは非常に少ない
  • ペアプロのエビデンスが出た
  • 1人よりも2人のほうがいい
  • ジョーがボブよりもフレーキーを起こす可能性が高い
  • 言語によってはブレークが起こりやすい　C++とJava　Goはもっといい
  • 是非結果を記録してください
  • こんなものがフレーク
  • WEBドライバーのテスト
  • マルチスレッドのテスト
  • 環境の差異
  • 継続的に1.5％がフレーク
  • デベロッパーにプレッシャーはかけているものの
  • ある程度のフレークさは許容しなければならない
  • ほとんどのデベロッパーは、うまくいくまでサブミットし続ける
  • どれだけ頻繁に失敗するか
  • このテスト自身が、最近フレーキーだったかどうかのフラグを持っている
  • フレーキーデータベース
  • 明日のチュートリアル

  • データセット

  • 質問

  • マニュアルテストは一切やってない
  • ハードウェア含めた自動化のアイディアはあるか
    • どれだけデジタル化が進んでいるかによる
    • 信号機の制御アルゴリズムだけをテストすれば足りるはず
  • カバレッジをどの程度達成しているのか
    • 測定はしているが、チームの成熟度によって差がある
  • テストの設計の話を知りたい
    • コードレビュー　ほとんどピアによってコントロールされる
  • 小さな変更を非常に大事にしている
    • フレーキーという言葉の由来
    • 語原はミッコさんも知らない　どちらかというと見下げたことば
    • 一貫性に欠ける人　不安定　などというニュアンスがある
  • グリーンをトップダウンで導入したのかボトムアップで導入したのか
    • ボトムから、費用対効果のトレードオフをトップに説明した
    • お金がかかるというのが課題感だった
  • 3名以上　相関関係が見えてきた
    • 3人以上になると規模が大きくなるので、3人がすべてのエキスパートになるのは難しい
    • 1人よりは2人のほうがいい　他の人の目があるほうがいい　気づき
  • 新規サービスのマニュアルテストもないのか
    • 自動化できている　自動化できるということは、イレテーションが短いということ
    • 多少問題があってもクリティカルな問題にはならないサービスだから
  • UXテストも自動化できるのか
    • ユーザビリティテストは人がラボでやっている　エスクペリエンスの確認
    • 実験も含めている　それはある程度自動化といっていいのではないか　ライブのテスト　実験的なテスト
    • UIテストは自動化している
  • テストの記録には個人名が入っているのか　個人に注目してどこまでやっていいのか
    • よい質問です　アメリカでは、従業員の情報は取ることができる　すべて匿名化されている　マシンラーニングのほうでそれは対処してくれる
  • 開発者へのフィードバックについて
    • 依存関係は精度が高い　テストのグラフ　ご関心があればベーゼルをご検討ください
  • 開発者以外にフレーキー以外にフィードバックすること
    • 様々な分析結果　
  • (不具合を)見逃してリリースしてしまったことはないか
    • 何かを見逃すリスクは低い　見逃さないと思っている　トレードオフをみている
  • 組み込みのCIに興味がある　想定されるリスクなどあるか
    • 少し考えさせていただきたい　興味深い分野だと思います
  • グリーンにする社内共通基準のようなものがあるか　チームごとに違うのか
    • チームごとにテストの内用は決めている　でも、ある程度チーム間で合意は取れているとは思う
  • 再利用性が低いテストを自動化しているのは何故か
    • マニュアルテストしているのは翻訳のみ　迅速にリリースするため　36時間以内にライブに出すというルールがある　レアなテストでも、テストを書くということにコミットしている　文化的に組み込まれている
  • 自動化にはまらないコードはどうしているのか
    • もはやそういった問題はない　2006年に文化を変え始めた　2006年以降のコードは96％程度
    • どんなベストプラクティスでもコードに組み込んでいく
  • カオスエンジニアリングのような新しいテスト手法をやっているか
    • インテグレーションは根づいている
    • 実験的　ファジング　ランダムテスト　つかっているが　いまは根幹にはなっていない
  • 全体としてのテスト計画を誰が考えるのか
    • 各プロジェクトチームが、全体的なテストプランを考えている　Googleでは、少数のユーザに使ってもらって、フィードバックを得ている　各チーム自律的に動いている　チームが個々に決断できる
  • テスト変更の適切さをどう担保しているか
    • レビューをしている
  • テストの変更で失敗することはないか
    • コミットする前に動かして確認している
  • AIの活用
    • AIは使うもの　テストの選定　スケジューリング　機会学習のテストは難しい　テスターとしてそこは心配している　数学をわかる必要がある　もし壊れても気付けないおそれがある　業界全体が直面する問題
  • 人数について
    • 強い相関関係がある　複数に人が同じファイルを扱うとテストに影響する　3人以上は影響が起きやすい　3人より2人　2名が最適という判断　なぜなのかはまだわからない　ルールまでは設けていない
  • 特別なレビューはあるのか　レビュアーに必要なスキルセット
    • リーダビリティ　言語の可読性　コーディングスタイルをよく知っている　その言語をよく知っている　チームではテックリードの役割　直接同じプロジェクトに関わっていなくても、ピアプレッシャーによってうまくいっている
  • トライビュー？というフレームワーク　静的な分析　コードレビューの自動化　使えないボタン　すべてに対して修正をかけるより効率的

探索的テストとそうでないテストのJSTQB的まとめ

JSTQB 方言

きっかけ

Feedlyを設定している途中、showさんのエントリを拝見しました。

surumegohan.hatenablog.com

「探索的テストはベテランがやるものだと思ってた」というのは私もよく耳にする言葉で、「そのソフトウェアについてのドメイン知識をそれなりに有している人が、テストケースとは無関係に動くソフトウェアを使用し、ソフトウェアに対するフィードバック(主として欠陥=defectの検出)を行うこと」という行為を指して「探索的テスト」という言葉が使われることが多い印象を持っています。さらに、まったく同じ文脈で「アドホックテスト」「モンキーテスト」「ランダムテスト」という言葉が使われていることも多いと感じています。

(テスト方言あるある)

「探索的テストっぽいグループのテスト」が持つ要素

要素を箇条書きにすると、以下の2点が特徴になるかと思います。

  • 有識者だけが実施可能である
  • テストケースは書かない

ちょっと整理してみたかった

上記の捉え方には個人的にいろいろ疑問を感じているので、それを整理してみたいと思いました。 物差しとしては、JSTQBの用語を使います。

JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-

探索的テスト

まず、「探索的テスト」は以下のように定義されています。

用語 定義
探索的テスト（exploratory testing） 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。

探索的テストはあくまで「設計技法の一つ」として定義されており、「テストを設計しない」という考え方はされていません。「テストを実施する過程で、テスト担当者がテスト実施情報を活用」することがポイントで、ソフトウェアが動いた後に、動くソフトウェアを見ながらテスト設計を行うという段取りになっています。テスト実施情報は、ドメイン知識に基づく情報以外にも、一般的なソフトウェアの設計知識や、ソフトウェアが動作する環境に対する知識からも導くことができると思います。実際の現場ではドメイン知識を持っている人が圧倒的に強い(効率的に欠陥を検出できる)と思われますので、そこがフォーカスされるのは仕方ないと思います。

探索的テストと似ているが、別の言葉で定義されているテスト

次に、「探索的テスト」と同じような文脈で使われることが多いけれども、用語として分かれているものを以下に挙げます。

※他にもありましたら教えてください！

用語 定義
モンキーテスト（monkey testing） 製品の使用法については全く考慮せず、広範囲の入力からランダムに選択し、ボタンをランダムに押すことでテストを行なう方法。
アドホックテスト（ad hoc testing） 非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。
ランダムテスト（random testing） ブラックボックステスト設計技法の一つ。擬似ランダム生成アルゴリズム等を使い、運用プロファイルに合致するテストケースを設計する。信頼性、性能等、非機能属性のテストに利用できる。

モンキーテストは、「製品の使用法については全く考慮せず、広範囲の入力からランダムに選択」するところがポイントだと思っています。テスト設計もしませんし、テスト実施情報も見ません。場合によっては、「ふつうログインするときにはパスワード入れるでしょ。。。」みたいな固定概念が無い、ド素人の方が強かったりします。

アドホックテストは、「非公式に実施する」というところがポイントだと思います。公式に取り決めたプロセス以外で実施するテストですが、「実績のあるテスト設計技法を用いず、テスト結果も予測せず」というだけで、全くテスト設計をしないとは言っていません。頭の中にしかテスト設計がなかったとしても、現状に対してゼロベースで適切なテストを考えて実行する方法、というくらいのイメージです。

ランダムテストは、「設計技法の一つ」と書かれているとおり、テスト設計を行うというところがポイントです。ただ、そのアプローチとして「擬似ランダム生成アルゴリズム等」を使っているだけです。

表にまとめてみると

以下のようになりました。

用語 有識者が必要か テスト設計を行うか
探索的テスト NO(有識者がいるとベター) YES
モンキーテスト NO NO
アドホックテスト NO(有識者がいるとベター) NO寄りのYES
ランダムテスト NO YES

私が携わったプロジェクトでは、上記のうち「アドホックテスト」に該当するテストを、それ以外の呼称で呼んでいることが多かったかなと思います。