タイトル未定

品質や趣味について語りたいブログ

探索的テストで やっていること・意識していること

 

どうも、halspringです。時というのは早いもので とうとう2年目になりました。 

こうして楽しく仕事したりテストについて考えたり発信できるのは読んでくださっているみなさまのおかげです。いつもありがとうございます。

 

selenium confが迫っているのに目が冴えてしまってこんなものを書いていますが、果して起きれるのでしょうか。

（追記 : 起きれました。）

 

さて、今回は探索的テストについて書いてみます。

Webサービスを扱う会社の経験しかないため、現場によってここで述べる内容に合う合わない等あるかもしれませんがご容赦下さい。

 

毎度の如く書いておりますが、

あくまで個人的な見解であり、独自の解釈や考えを述べておりますので、鵜呑みにせず 調べたり試したり自身の経験・考えと比較して見てください。

興味を持っていただき、テストを学ぶきっかけとなれれば幸いです。

 

 

 

探索的テストとは

 探索的テストとはテストのスタイルのひとつで、

テストケースを作らず、状況に応じて学習を繰り返し 頭の中でテスト設計をしながらテストを行います。(簡単なドキュメントは用意したりします。)

テストケースを起こさずに実施できるため、効率的にテストを行うことが可能です。

しかし、テストの再現性が低いことや、担当者によってテストの結果が変わること、マネジメントやスケジューリングが難しいといった特徴も挙げられます。

 

ここでの説明はこれくらいにしておきますが、

興味のある方、詳しく知りたい方のために 参考資料を置いておきます。

 

そして、ここだけは誤解せずに しっかりと使い分けてほしいのですが、

探索的テストはモンキーテストやアドホックテストではありません。

現場からは以上です。

 

どんな運用をしている？

「探索的テストはアジャイルに向いている」といった説明を目にします。

確かに効率的なテストでスピード感があり、その意見は正しいと感じています。

しかし、だからといってそれだけではダメで 個人的には他の基本的なテストプロセスに加えて実施するべきだと思っています。

 探索的テストは網羅性には乏しいですし、

先ほど挙げた『探索的テストってなんですか？ アジャイル時代のソフトウェアテスト』にも注意点として "探索的テストに100％頼らない" と述べられています。

 

 

どんな準備をしている？

自分が探索的テストを実施するときに準備するもの、あった方が良いと思うものは以下の通りです。

ディスプレイ

書くまでもないかもしれませんが、画面は多い方が良いです。

すぐにログを残せるようにしたり、仕様書を横で開いておいたりします。

 

バグの情報

ここまでのテストプロセスで見つかったバグのリストを用意して、事前に概要だけでもいいのですべて見ておきます。

件数が多い場合はざっと どの機能や画面にバグが多いかあたりをつけ、頭の片隅に入れておきます。

件数が少ない場合は拾える情報は可能な限り拾っておきます。

ここで軽くでも見ておくと、後々 テストをしているときに違和感に反応しやすくなると思います。

 

仕様書・テストオラクル

自分は用意したサブのディスプレイに表示させておきます。

手間をかけずに正しいかどうか比較できるもの（現行版の画面など）を用意しています。

違和感を感じたところや 仕様にそぐわない箇所、画面からはわかりにくい処理の多い箇所や複雑な箇所を確認しながらテストしています。

 

メモ

紙のメモをそばに置いています。

どこを見ようと思ったか、どんな違和感を感じたかのログ用です。

ログを残す方法として紙にこだわる必要はないので、残しやすい形で残せばよいと思います。

自分はちょっとしたリフレッシュがてらアナログを挟んでいます。

 

イヤホン

思考に集中するために、外部の音を遮断します。

音があると集中できない方はノイズキャンセリング機能だけを使うと良いと思います。自分はがっつり音楽をかけて精神を隔離しています。

また、イヤホンを着けていれば「あ、なんか話しかけるの忍びねぇな...」といった雰囲気が生まれるので急ぎの用事でない場合 話しかけられるリスクを軽減することができます。

 他にも思考を妨げる要因に通知が考えられますので、ブラウザのタブからslackを排除し、カレンダーには【BLOCK】とスケジュールを入れてしまいましょう。

 

お菓子・飲み物

テスト中、テスト後、疲れます。

また、「喉が渇いたな」という雑念で思考が止まることを避けるためにも、

そばに水分や糖分を確保しておきます。

 

 

どんな流れ？

探索的テストをどんな流れで行っているかを説明します。

自分の場合は、

事前にスケジュールに何か追加されないようにタスクをセットし、

調べたバグのリストとオラクルになる資料や情報を別のディスプレイに表示、

どんな箇所を見るか・どんな操作がしたいか 事前にまとめたメモをそばに置き、

イヤホンを装着、ガンガンに音楽を掛けたらようやく準備完了です。

 

探索的テストを開始してからは、

メモを基に試す内容をざっくりと決定し、操作をしていきます。

UIに違和感を感じたら大体はそこにバグが潜んでいるので、徹底的に叩きます。

オラクルと比較し、なにに違和感を感じたのか正体を探ります。

勘違いであってもメモに残し、その違和感は思い出せる状態にしておきます。(変だと感じた場所には仕様漏れがあったりするので)

 

基本的にはこの作業の繰り返しになるのですが、

「あ、今なんも考えてなかったな」とか「あれ、さっきと同じことやってるな」と思ったら一度中断しています。時間的・精神的・肉体的な限界を迎えています。

長時間ひたすらだらだらと続けていても効率的とは言えず むしろコスパが悪いので、

短期間しか持たなくても、その短期間を集中して成果を出せばいいんです。

 

休憩ついでに実施した内容や見つけたものをログにまとめ、頭を整理するとより良いと思います。

探索的テストは学習をしながら進めていくテストなので、このサイクルが大事だと思っています。

(ノリノリの状態が続いていればそのまま続けても良いと思いますが、キリがないので時間で終了のタイミングを決めておくと良いです。)

 

 

具体的にはどんなことしてる？

ログ

見つけたバグの内容は紙に書いています。

特別に理由があるわけではありません。

デスクにガラスペンだとか良いペンを置いているのですが、使うとモチベーション上がるからです。(紙のほうが関係性など書きやすいということもありますが)

  

XSS、SQLインジェクション、ファイルアップロードなどを簡単に

セキュリティを考慮して実装していたり、ツールなどを使って脆弱性診断を行ったりすることが一般的だと思いますが、万が一があったら嫌なので確認しています。

画像ファイルに偽装してスクリプトファイルをアップしようとしてみたりすると結構楽しいです。

 

異常値

変な文字列を入力できないかをよく見てます。

仕様書に書いてある内容はテストケースでカバーしているのですが、仕様書に書かれていないけれど必要なバリデーションがあるといったことは良くあることだと思います。

 

他にもフロントで制御するバリデーションだけでは怖いので、異常値を無理矢理POSTしたりもします。

漏れを見つけられる可能性があるほかにも、フロント側とサーバー側でバリデーションが違ったりすることもあるので、そのへんも見ちゃいます。

主に、どんな実装をしてるのか、自分ならどの辺の実装が面倒だと感じるかを考え、ミスをしそうな機能を狙います。

 

一度の文字列に大量の変な文字混ぜ過ぎると結果から分析しにくかったりもしますが、ひとつひとつやっても効率悪いですし 網羅的な内容はテストケースで見れば良いと思うので異常がないかだけ確認できればいいと思います。

 

ただ、どの文字列がダメだったか程度ならともかく、

一斉に送ってしまってどのフォームでエラー吐いたのかわからないくらいのやり過ぎは良くないです。基本は忘れずに。

 

連打

連続でPOSTリクエストが飛ぶと大体ろくなことになりません。

しっかりと制御されていることを確認しています。

裏でたくさん処理してそうなところも連打して意地悪したりもしますが、環境によってはほどほどにしましょう。

JSで実装されている部分なんかも連打のねらい目です。

 

矛盾する組み合わせとか

結構 意地悪です。

工数や優先度から多くの場合に実装されないであろう選択の組み合わせの制御部分を見ています。

これは正直「仕様です」の返事はわかっている上での行動で、

そうなることはわかっていて、それでも「この選択肢が選べちゃうのってあまり好ましくないのでは？」「ユーザーにとって親切ではないのでは？」と今後の検討リストに追加されたらいいなぁと想いを込めてやっています。

もちろん、自分はユーザビリティの専門家でも企画のプロフェッショナルでもありません。

フィードバックを送れる位置にいることを利用して個人の意見をぶつけているだけなので、ほどほどにしておきましょう。

 

paramをいじる

URLにparamが見えたら触ってみます。

検索用のクエリが入ることが多いと思いますが、変な文字入れるとなんらかの処理を失敗させたり 攻撃できたりすることもあるので、念入りに確かめています。 

 

その他

マインド

ゲームをしている感覚でテストしています。

 

ただ、ゲームにも色んなプレイスタイルがあると思います。

自分は開発者の作品への愛やこだわりを感じながら隅々まで見たいタイプです。

具体的には「村人とは台詞がループするまで会話する」「ループしても会話するキャラや内容によっては3回くらい粘る」「装備してって言われた装備をすぐ外す」「使ってって言われたアイテムをくれた人に使ってあげる」「装備全部外してパラメータ上 全裸の状態にしてみる」「ステージの最初は必ず後ろから見る」などなど

 

「こんなことしてもなにもないだろうなぁー...お？ おおおぉぉっ！！」ってなる楽しみ方です。

 

世界観を重視してるゲームに対してよくやっています。

ゲーム性を重視してるゲームに対しては、ルールをひとつ無視できたらどうなるのか考えて「バランスの取り方うまいなぁ」と考え込まれた仕様を感じるのが好きです。

 

といった具合に、開発者がどんなところまで考慮しているかを意識するようにしています。

プロダクトに込めた想いを感じ取りましょう。

 

この手の作りこみをゲームで体験したい方は、

  • undertale, deltarune
  • Doki Doki Literature Club!
  • OCTOPATH TRAVELER
  • シルフェイド幻想譚
  • The Stanley Parable

あたりをオススメします。

※かなり個人的な趣味嗜好が入っています

 

ログどこまで書くのか問題

自分の考えとしては、どんな意図でどんなテストをしたのか説明できなきゃいけないと思っています。

これは探索的テストに限った話でなく、すべてのテストにおいてです。

 

説明ができないなら、それは探索的テストの「頭の中でテスト設計をしながら」に反しています。

説明のできないテストをしてもほとんど意味はないと思いますし、その場で偶然バグが見つかっても 今後も同じようなバグを見つけられる可能性は低いと思います。

個人の裁量が大きいテストなので、誰にでもわかるように書く必要まではないと思いますが、自分で振り返れる程度のログは残すべきだと思います。

  

 

 

 

 おしまいおしまい

と、自分が思っている・意識している探索的テストについてを述べてみました。

長々と書いてしましましたが、ここまでお読みいただきありがとうございました。

みなさんの何かしらのきっかけになれれば幸いです。

 

気になる部分、異なるご意見があればコメントなりtwitterなりで反応を頂ければと思います。

それではselenium confに備えて寝る必要があるので、このあたりで失礼いたします。