駆け出しアジャイルQAエンジニアのみーにです。

「QAエンジニアってなあに？」という方向けにこっそりお教えしましょう。
「Quality Assurance Engineer（品質管理を行うエンジニア）」の略だそうですよ。

「エンジニア」と言われると、システムを作る人を想像する方が多いと思います。それに対し、QAエンジニアは「システムが一定の品質で稼働することを担保する人」だと思って良いでしょう。

つまり私は「アジャイル開発における、品質管理スペシャリストのたまご」といったところです。まずはそんな私の、先日のお話。

私には分かるのです！！探索的テスト初心者が、どこでつまずくのかが！！
なぜなら、私もつい先日まで「探索的テストって何？」という状態だったから。

探索的テスト初心者を脱して間もない、今の私だからこそ発信できる内容をお伝えするのが、今回のnote。

題して・・・

「探索的テストって何？どうやったらいいの？」と思っている、たまご仲間の皆様、「探索的テスト初心者に、何を教えたらいいかな？」と思っている、たまご育成中の皆様、ぜひお読みください！！！

0. 目次

1. 探索的テストとは？調べてみました
2. 探索的テスト初心者を脱却したての筆者から、初心者に捧ぐ！
「何をしていいか分からない探索的テスト初心者！まずはコレやってみよう！」
3. まとめ

1. 探索的テストとは？調べてみました

まずは、探索的テストの定義を確認してみます。

ここから読み取れる、探索的テストの重要な特徴として、
① テストを実施する過程で、テストの実施内容を考える
② テスト実施情報を活用しながら、テストの実施内容を考える
という2点が挙げられることが分かります。

これらの特徴を、スーパーやわらかモードで説明し直すと、
① どんなテストをするかは、テストをしながら考えよー！
② テストした結果をもとに、どんなテストをするか考えよー！
といった感じでしょうか。

それぞれの特徴について、もう少し掘り下げてみましょう。

① どんなテストをするかは、テストをしながら考えよー！

「テストをしながら考えよー！」は、「テストをする前に考えよー！」と対比すると分かりやすいです。

後者は「記述式テスト」「スクリプトテスト」などと呼ばれている手法です。テストを始める前に、「ここは確認しなければ」というポイントを洗い出し、文章として書き落としておき、それに従ってテストを実施する手法ですね。

それに対して探索的テストは、事前に文章に書き落としておくことはありません。テストを進める中で、「ここも確認したほうが良いのでは？」と感じた部分を、どんどんテストしていく手法です。

② テストした結果をもとに、どんなテストをするか考えよー！

「この機能で、こういった原因の不具合が出た。ということは、あの機能も似た原因の不具合が出るのではないか？」と考えて、不具合が出そうな箇所を的確に突いていく。これが探索的テストです。

がむしゃらに「えいえい！これでどうだ！」と全身にパンチ・・・もとい、テストするのは、探索的テストらしいとは言えません。（これは「モンキーテスト」と呼ばれる、別のテスト手法の特徴です。）

以上が、探索的テストについて調べた結果です。
では早速やっていきましょう。いざ、探索的テスト！

2. 探索的テスト初心者を脱却したての筆者から、初心者に捧ぐ！「何をしていいか分からない探索的テスト初心者！まずはコレやってみよう！」

「探索的テストが、どういうものかは分かった。でも、何から手をつけていいか分からない・・・」

探索的テストが初めての人は、この壁にぶつかる確率がかなり高いはずです。

でも大丈夫です。この記事は「たまごの、たまごによる、たまごのための探索的テスト」ですから！初心者の気持ちに寄り添って、何をしていいか分からない探索的テスト初心者！まずはコレやってみよう！というアクションを3つお伝えします。
※「これができれば探索的テストは完璧！」というものではありません。あくまで初心者向けのとっかかりと考えてください。

① 既存のチャーターを使ってみる。

探索的テストを進める1つの方法として、「テストチャーター」を用いる方法があります。

「テストチャーター」とは、テストを実施する目的や方針を記したものです。「テストケース」には、具体的に手順や期待値が書いてあるのに比べ、「テストチャーター」には、確認すべきポイントが抽象的に記載されています。これをとっかかりに探索的テストを始めることはできるでしょう。

・社内に既に探索的テストのチャーターが存在していないか、詳しそうな人に聞いてみる。
・インターネットで発信されているチャーターを拾ってくる。

といった方法で、チャーターを探してみてはいかがでしょうか。
ネットで先人の知恵を手軽に借りることができるなんて、本当にいい時代だぁ・・・。

② 過去に出た不具合を確認してみる。

探索的テストを行う観点が、探索的テスト特有の観点である必要はありません。過去に発覚した不具合を漁ってみましょう。当時の事象や原因を見ていたら、「あれっ、今テスト対象になっている機能でも、似たようなことが起こるのでは・・・？」というアイデアを得られるかもしれません。

③ よく使われる機能/不具合があると困る機能から触ってみる。

「チャーターを使って、考えられる範囲はもうテストした！」
「新しいシステムだから、過去の不具合なんてほぼ存在しない！」
そういう場合もあるかもしれません。

そんな時は、「ユーザがよく使う機能」「不具合があるとユーザが困る機能」を考えてみてはいかがでしょう？理由は単純です。その場所以外に不具合があるより、その場所に不具合があるほうが、ユーザが困るから。

もちろん、「システムに慣れていないから、何がよく使われていて、どこに不具合があると困るのかが分からない。」という方もいらっしゃるでしょう。まずは、テスト対象のシステムに慣れている方が身近にいるならば、その方に相談してみてください。

【おまけ】相談できそうな相手もいない、という方のために「どのシステムであっても、ココに不具合があるのは確実にヤバイでしょ！ランキングトップ3　※筆者調べ」の機能を書き残しておきます。

「個人情報を扱う機能」「カネが絡む機能」「法律を守るための機能」です！探索的テストのヒントになれば幸いです。

3. まとめ

探索的テストとは
① どんなテストをするかは、テストをしながら考えよー！
② テストした結果をもとに、どんなテストをするか考えよー！
というテスト手法である。

初心者卒業したての筆者が考える！探索的テストのとっかかり
① 既存のチャーターを使ってみる。
② 過去に出た不具合を確認してみる。
③ よく使われる機能/不具合があると困る機能から触ってみる。

読者の皆様に伝えたいこと
今回、探索的テストについて調べていく中で、強く感じたことがあります。それは「探索的テストは奥が深すぎる」ということです。このnoteに記載しているのは、探索的テストのごく一部の情報にすぎません。なので、この記事を読んで終わりにするのではなく、ぜひご自身で、探索的テストについての情報収集と、実践を繰り返してください。筆者も、探索的テストの勉強と実践を続けていこうと思います！


お知らせ
SHIFTは、システムの品質保証に強みのある（でも実はシステム周辺何でもできる）会社です。そんなSHIFTに所属する人々が発信している技術ブログが、この公式SHIFT Group note。筆者のようなQAエンジニアのたまごだけではなく、あらゆる技術のプロフェッショナルが書いた記事が、続々と掲載されていきます！ あなたが知りたかった、あんなことについて書いている記事があるかも・・・？ ぜひ他の記事も見ていってくださいね！

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/