探索的テストについて
ご無沙汰しています、halspringです。
本記事は『ソフトウェアテスト Advent Calendar 2020』5日目の記事です。
登録したものの書くことが思い浮かばなかったので、自分の中の理解をまとめてみようと思います。
探索的テストとは
定義
まずはじめに探索的テスト（Exploratory Testing）とはなんでしょう。 JSTQB FL シラバスを参照してみます。
『4.4 経験ベースのテスト技法』として説明されています。
探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する
次に、JSQTB ALTA シラバスを参照してみます。 『3.4 経験ベースの技法』として説明されています。
探索的テストには、テスト担当者がプロダクトとその欠陥の学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を同時に行うという特徴がある。テスト担当者は、テスト実行時にテスト目標を動的に調整し、軽量のドキュメントのみを準備する[Whittaker09]。
JSTQB によると探索的テストは技法のひとつのようですね。
『知識ゼロから学ぶソフトウェアテスト』やその著者の高橋寿一さんの発表資料では、技法ではなく"スタイル"と説明されていたりもします（厳密には Cem Kaner による定義）。
定義ややり方は人によって幅があるように見えますね。
定義が異なったり同じ人物でもアップデートされていたりしますが、共通しているのは「動的にテストの設計,実行を並行して行い、学習を含んでいる」ことのようです。
ちなみに個人的には探索的テストといちいち書いたり口にするのが面倒なので ET （Exploratory Testing）と呼んでいることが多いです。 twitter 等でテストの文脈から急にスピルバーグ作品名が出てくる確率は低いと思いますので、自分が ET と言っていたら探索的テストのことを指しています。 会社でも頻繁に使うため皆が ET と呼んでいるので、ついポロっと出てしまいます。許して。
特徴
次に探索的テストはどのような要素を持っているでしょう。 自分が認識しているのはおおよそ以下の通りです。
- 学習, 設計, 実行, 報告のサイクルが存在する
- 再現性に乏しい
- 網羅性に乏しい
- 具体的なテストケースを用いない
- テストマネジメントが難しい
- （相対的に）短時間で不具合を見つけることができる
- （相対的に）複雑な操作による不具合を検出しやすい
- ドキュメントが不足していても実施することができる
テストケースとして手順が記述されたようなテスト（以下、スクリプトテスト）と比べてメリットだけが存在するわけではありません。 「探索的テストをするからスクリプトテストをしなくていい」ということにはならず、あくまで使い分けが必要です。
実施について後述するので、各特徴についてはそちらをお読み頂けばある程度は納得できるかと思います。
探索的テストの実施
探索的テストでは前述の通り基本的にテストケースを用いません。 では、どのように探索的テストを実施するのでしょう。
様々なのは定義だけではなく、実施の方法にも幅があります。 ここでは大きく３つの方法を取り上げます。
しっかりと系譜を知った上で語るわけではないため自分の認識になります、というカッコ悪い大きな保険を掛けておきます。誤りがあれば有識者の方にはぜひご指摘をお願いします。
ここではフリーな探索、ツアー、チャーターを紹介します。 フリーで実施する探索的テストでは著しく個人差が大きくなり、かつ網羅性や再現性が乏しくなります。 さらに「どこでテストをやめるのか」といった判断も難しくなります。
ツアーや後述のチャーターを用いることで、これらの要素を抑制することができます。 ただし、代償としてテスト実施者の自由を制限することになります。 もちろん制限も絶対的なものではなく脱線してはいけないわけではありません。
ツアー、チャーターは探索的テストに方向を与えます。 完全にフリーダムな探索では実施者による差が大きくなりますが、方向が揃うことでこの差を小さくします。 加えて、用意したツアー、チャーターをすべて実施したらテスト終了のような基準として用いたり、タイムボックスを用意してそれらを割り当てることでマネジメントをしやすくする効果もあります（別に推奨するとは言ってません）。
フリーで探索する
ひとつめは特に準備をせずフリーで探索を行う方法です。 方法と呼んでいいのか怪しいかもしれませんが、無計画にただプロダクトを触るわけではありません。
ただ彷徨うだけではなく探索をします。 上述の探索的テストの定義で共通しているものとして「動的にテストの設計,実行を並行して行い、学習を含んでいる」と述べました。 何かを考えながら、プロダクトを触っています。
では、その考えている「何か」とはなにか。 フリーな探索の場合、本当に個人差が激しくなりますので、自分個人の場合をご紹介します。 自分の場合はプロダクトに対して、
- どんな動きをするのか/して欲しいか
- どんな設計/実装になっているか
- 開発中、どの部分に時間が掛かっていたか
といったことを考えていることが多いです。 ざっくりとひとつずつ説明をします。
どんな動きをするのか/して欲しいか
主にプロダクトがどんな動きをするのかを知るためのものです。 自分の場合は要件定義書や仕様書にさっと目を通すことが多いですが、文字列で読んだ挙動と実際に自分で操作するのとでは理解度に違いがあります。
プロダクトに詳しくない実施直後はこれを考えていることが多いです。 先入観が薄い状態で探索できるため、「直感的にわかりにくい機能」や「勘違いしやすい表現」なども発見しやすいです。
JaSST Online Bergamot で、探索的テストが実施される様子を見るセッションがありました。 そのセッションでも後述するチャーターは用いずにフリーの探索でプロダクトと向き合うことから始めていました（参加報告のブログや togetter をご参考ください）。
どんな設計/実装になっているか
ふたつめはどんな設計/実装になっているか、です。 自分ならどう設計/実装するかを想像しながらプロダクトを触り、不具合を探します。
たとえば単純な CRUD 機能であれば、
- データは論理削除か物理削除なのか
- 削除後にデータ更新をするとどうなるか
- フォームの入力内容は表示時にエスケープされているか
- Create の連打（複数生成）は防止されているか
- 検索時のクエリで悪さできるか
といったことを考えながら、どんなバグが作り込まれるかを想像します。そして、そのバグはどう操作すれば見つかるかを考えて操作を行います。 見つからなかった場合も、プロダクトがどんな挙動をしたかを観察し、実装を想像しながら次に繋げます。
開発中、どの部分に時間が掛かっていたか
みっつめは、どこに時間が掛かっていたか、言い換えると、開発中にどの機能/画面に仕様変更/遅延があったかです。 プロダクトの開発過程を知ることができる状態であれば、進捗報告等に参加して様子をメモしておきます。
経験上、仕様変更が度々起こる場所は修正漏れがあったり、修正に伴い新しくバグを作り込んでいることが多く、 遅延しているところは実装が複雑になっておりパラメータの組み合わせ等で誤りや考慮漏れが潜んでいることが多いです。
ただし、自分の場合はプロダクトのことや開発者のことを知っている前提があります。 誰が過去にどんなプロジェクトに参加していて、どの機能に詳しいかを踏まえて怪しいポイントを探っています。 そういった意味では、ドキュメントの準備が少ないことが探索的テストの特徴ですが、時間を掛けて人のことを知ることも重要かもしれません。
ツアーを用いて探索する
続いてツアーを用いた探索です。 ツアーとは探索的テストを旅行に例えたものです。 いくつか例を見たほうがわかりやすいと思います。 『Exploratory Software Testing』では以下のような例をあげています。
- ガイドブックツアー
- ユーザーマニュアルをガイドとして利用し、ユーザーがソフトウェアに期待する主要な機能を辿る
- ランドマークツアー
- 主要な機能をランドマークに見立て、ランドマークを網羅するように辿る
- 博物館ツアー
- レガシーコードという骨董品をめぐるように開発者が中身や存在を忘れいているところをテストする
- 雨天中止ツアー
- 実行中の処理を途中でキャンセルする
このように、一回の探索に目的を与えてくれるのがツアーです。 書籍の中では他にもツアーが紹介されていますし、検索すれば解説が出てくると思います。 注意事項として、これらはツアー例であり、書籍に載っているツアーをすべて実施すれば良いわけではありません。 旅を比喩として用いることで探索的テストに応用するといったエッセンスですので、実施する際にはもちろん書籍を参考にしながら必要なツアーを考えてみてください。
チャーターを用いて探索する
最後はチャーターを用いる方法です。 チャーターも冒険家や旅から着想を得ているものだった気がします。 由来は忘れました。
チャーターを利用することでツアーと同様、探索的テストに目的という方向が与えられます。 ツアーとどう違うかですが、自分はおおよそ粒度の違いだと理解しています。 どちらも決まったフォーマットはないものの、ツアーは複数箇所をめぐるようなもので、チャーターは一箇所（ないし関連の強い箇所）に対して行うようなもののイメージです。違ったらごめんなさい。
『Explore it!』では "Explore {target} with {resources} to discover {information}" のフォーマットが紹介されています。
「{information}を探索するために{resources}を用いて{target}を探索」です。 target には機能や要件、information には見つけたい情報、resources にはツールやデータセットなどを入れます。
これを事前に用意することで、実施者で分担することができるようになり、かつ時間が経ってからも用いたチャーターを見ることである程度同じバグを再現できる可能性が高くなります。
おわりに
探索的テストの特徴や実施方法を紹介しました。 ツアーやチャーターを用いても再現性や網羅性が比較的乏しいことは理解して頂けたかと思います。
特徴を理解した上で、既存のスクリプトテストと併用したり一部置き換えたりしながら用法用量を守って実施をしていただければと思います。 そして得た知見はネットの海に放って共有してくださると自分も助かります。
あとしつこいようですが、誤りがあればご指摘をお願いしますm(_ _)m
メモ : 「問題」についてちょっと考えた
これはなに？
ずっとデスクの横に積んだままになっていた『ライト、ついてますか』の第一部を読んで床に就こうとしていたとき考えていたことのメモです （多少きれいにしてますが、本当にiPhoneのメモに書き残していたメモです）。
結論だとか主張のようなものは特に含んでおりません。あしからず。
なんかいっぱい文章できてるし、せっかくだから投稿しておこうと思っただけです。
まとまりのない文章でどこに向かっているかもわからない内容ですので、 潰すだけの暇があればお付き合いください。
「問題」とは
書籍に書かれていた「問題」とは、
望まれた事柄と認識された事柄の相違
であった。
まず表現として「欲求」を使っていることについて。 他に類似する言葉として「理想」ではなくてなぜ「欲求」なのか。
完全に主観ではあるが、「理想」の場合は妥協があり得る気がする。 なんとなくmustとwantが混ざっているのが「理想」で、mustが「欲求」なのでは、と。
厳密にそうでなくても重みの比率としては「理想」はwantが大きくて、 「欲求」にはmustが大きい気がする。きっとそう。 狩野モデルの当たり前品質が「欲求」で、魅力品質が「利用」のような。
いや、この例えはわからんけど。
だとすれば、「理想」ではなく「欲求」を使っていることは正しいっぽい。 正しいとする(少なくとも現状別のよい定義は浮かばない)。
顕在化している問題としていない問題
なぜ顕在化しない？
問題は顕在化していないことも多い。 なんなら重要な問題は顕在化していないことの方が多いと思う。
顕在化していない、つまり認識できていない問題とはどういうことか。
認識できていないということは、欲求が弱いもしくは暗黙的になっている？
まずはこの「弱い」について考える。
弱い、すなわちmustではなくwantに近い？ なんだか違う気がする。
ちなみに「弱い」ではなく、極端に考えて欲求が存在しない問題はありえるか？ また、欲求を満たしているのに問題が起こることはないか？
欲求が存在しないとき、これについては欲求が存在しない状況が存在するかを考えねばならない。
生活の中でなんの欲求も持たない瞬間はあるか。
うーん、無心で座っていたり横になっていることはある。
では、その状態で問題は起こり得るか。
たとえば座り心地、寝心地の悪さや室温、騒音は問題となるか。
ならない。
無心でその条件のまま「ただ在る」とき、 すなわち快適に過ごしたいという欲求がないとき、これらは問題にならないだろう。 耳が聴こえない状態のときに近くで騒ぎ声が鳴り響いていても問題にはならないと思う。
やはり問題たりえるためには欲求が必要だ。
しかしこの「弱い」に関しては、認識できていないから欲求が弱いのかもしれない。 因果関係が逆かも。
次に「暗黙的」について。 暗黙的だとすると、認識できていないだけで確かに欲求が存在しているはず。 前提となっている？
生存を続けるためにエネルギーが必要だけど、 「生存するためにエネルギーがほしい」という欲求は前提となり、それによって空腹と感じる。空腹を感じたことでそれを満たすために「食べたい」という欲求が生まれるように。
事実、「エネルギーがほしい」を認識して食料を摂取している人は少ないと思う。 それこそ雪山で遭難でもしなければ、少しでも多くのエネルギーを摂取しようとは自分なら思わない。
これを踏まえると、認識が「弱い」のは「暗黙的」になっているためで、「暗黙的」であるとは欲求が「連続的」で「間接的」になっていることかもしれない。
欲求が認識できていない状態で起こる問題はあるか？
欲求が暗黙的な前提となっていたり間接的で認識できない状態で問題は発生するか？
おそらく発生するだろう。
たとえば、 プロジェクトを順調に進めたい、という欲求があったとする。 これに対して発生し得る問題は「プロジェクトが遅延する」となる。
「プロジェクトが遅延する」ためには、原因が必要である。 そしてその原因に対して、暗黙的な欲求が存在するのではないか。
- バグが多い → バグが出ないで欲しい
- 見積もりに無理がある → 時間的余裕を持って作業したい
- 頻繁に仕様や要件が変わる → 作り直したくない
といったように。
さらにこれらの原因は、原因であると同時に結果でもあるだろう。 なにが言いたいかと言うと、原因があって結果がある、すなわちこれら原因が結果であってその原因があるということ。
先程の「プロジェクトが遅延する」に対する原因として「バグが多い」を挙げたが、その「バグが多い」に対する原因として「レビューしていない」「テストが不十分」「ドキュメントが整備されていない」、てな具合に。 （このままrootまでに辿り着けるのかは知らない。「人間だから」になりそう。）
そして、また同様にこれら原因の原因にも欲求が存在しているはず。 これが暗黙的、間接的で認識できない問題に対する欲求だろう。
顕在化していない問題を解決する意味
顕在化していない問題があるとして、多くの顕在化していない問題を解決する意味はあるのか。
暗黙的で認識の弱い問題と、認識できている欲求に対する問題とではどっちを解く方が効果的か、または解きやすいか。
直感的に考えても前提となっている欲求に対する問題を解決した方が効果的だろう。
勇者は町外れ低級モンスターを倒すより、城で偉そうに鎮座している魔王を倒す方が効果は大きいはずだ。 魔王だと根本原因過ぎるので地域を任されている中間管理職のデーモンやオーガくらいでもいい。
ただここで大きな壁がある。魔王を倒すのは難易度が高い。
その難易度とは能力的な強さかもしれないし、到達するまでの道のりかもしれない。
姫から光の矢をもらってからじゃないと橋が架からない城とか、セーブポイントなしで広大なダンジョンの四方にあるクリスタル壊さないと会えないとか。
すなわち自分(たち)の力で解決できる問題のスコープを超えていたり、原因となる事象がムカデ人間のように何重にも連なっていることがあるということ。
このファンタジー世界のたとえが適切かわからないが、 魔王や中間管理職ボスを倒すのは効果的だが難易度が高いというのは、根本的な問題ほど解決が難しいと言い換えられる。
事実、プロジェクトで発生している困りごとの中には組織的都合や契約的都合で力の及ばない領域があるだろう。
また、無理に根本から解決しようとしてその方法を誤ると新たな問題が発生する。 ボスを失って統率のとれていた魔物達が好き勝手暴れ出し新たな勢力を築くかもしれないし、 弱いモンスターを倒して銭を稼いでいた戦士は職を失い賊になるかもしれない。
よく話が脱線するが、 ここまでを踏まえると顕在化していない問題を解決することには意味があり、またそれは顕在化しているものよりも効果が大きいと言える。
しかし、原因を辿るほど問題を解く難易度は高くなっていくだろうことも推測できる。
RPGよろしく、はじめは町外れの草原から着手し、徐々にレベルを上げて魔王に挑むのがよいのだろう。
また、スライムも倒せないのに魔王に挑むのは無理があるが、 魔王に挑めるレベルで洞窟のゴブリンを倒しても（すくなくとも勇者の周りでは）さほど効果はないだろう。
問題を解決するときは、自身の力で解決可能な領域で、 手が届くギリギリの範囲をせめることで効率的な経験値稼ぎができる。
すなわち改善効果が望めのではなかろうか。
※ でも多分、大量の経験値を抱えていてかつ倒しやすいレアなモンスターも存在するだろうから、こいつへの注意を怠ってはいけない。
ということを考えていた
はい。そんなこと考えてました。
3時くらいまで悶々としていましたが、ちゃんと翌日起きれました。ちゃんと出勤できてえらい。でも体調管理の観点ではえらくない。
第一部を読んだ時点で考えたことなので、もしかしたら似た話をするのかもしれないし、全く見当違いかもしれないので読み終えるまで震えて寝ます。
お付き合いありがとうございました。
WACATEで分科会オーナーをやってきた 〜その２〜
独りアドベントカレンダー10日目です。
ご存知でしたか、年度内ならまだアドベントカレンダーなのです。
（色々忙しかったり体調が不安定だったりでこんなことに）
前回の記事はこちらから。
前回の記事が「分科会オーナーやってきた」の表側、
今回の記事がそのコンテンツを作るときにどう考えていたかの裏側だと思っていただければ。
考えていたこと
「きっかけ」をつくる
探索的テストに触れたことない人も少なくなさそうなので、まず「知る」「触れる」機会をつくれればと思っていました。
組織によっては探索的テストにまったく触れることがないこともあると思います。
別にそれが悪いこととは思いませんが、「知る」に至らないことには選択することもできないのでこちらは良くないと思っています。
観点の違いを知る
次に、触れたことのある人にはどんなことを感じて学んで欲しいかを考えていました。
単純ですが、観点の違いです。
経験ベースのテスト故に、人によって よく見る観点は異なり、偏ります。
探索的テストをしている人が10人集まれば、10人がそれぞれ異なる流れで、異なることを気にしながらテストをするでしょう。
ましてや年齢も経験も異なれば、webや組み込みなど業界も異なる集まりです。
普段はあまり出会えない観点に出会って刺激になれば、というのが経験者に対しての狙いでした。
「モブ」テスト
2つ目と少々被りますが、WACATEにはテスト専門ではなく普段は開発専門な方も参加しています。
モブでテストの中で、同じものを見ていても「テストの人」「開発の人」がそれぞれ異なることに着目したり、異なる経験からバグを探し出すでしょう。
これを体験して、互いに歩み寄るための好奇心を少しでも生み出せればと思っていました。
どんな狙いでどんなバグを仕込んだのか
壮大なネタバレですが、正直時間もなくテストアイテムとしてそこまで優秀とも思えないのでいいでしょう。
ここに挙げたもの以外にも仕込んであるので、楽しむ分には差し支えないかと思います。
また機会があればちゃんと作ると思います。
ボタンを連打すると○○系
コッテコテのバグです。
お気に入り/お気に入り解除、フォロー/フォロー解除用のボタンを連打することで意図していないであろう操作ができます。
まずひとつを見つけ、残りを予測して見つけて欲しいという狙いがありました。
開発知識のある人に「伝われ...ｯ！！」の想いで「トグル処理になっていないので連打するとお気に入り数を爆上げできます」と一言ざっくり解説を添えました。
「過剰にお気に入り数を増やせる」ということは、リレーションが重複して作られてしまう（トグルでない）つくりになっているので、解除はリレーションを削除しているものと予測できます。
試してみるとひとつずつお気に入り数を減らせるので、推測が合っていそうなことがわかります。
では、解除ボタンを連打してリレーションが0個になったときにボタンが押されたらどうなるでしょう。
存在しないリレーションを削除しようとして500エラーを吐きます。
また、これらはお気に入りで発生した、つまり1対Nの関係にあるもの、リレーションテーブルを使っているであろう機能で起きている可能性があります。
なぜならこの機能を実装した人はトグル処理ではなく「リレーションがなければリレーションの作成、ひとつでもあれば削除」のロジックで実装をする人だからです。
同じような機能は同じように作っている可能性が高いですよね。
（欠陥の偏在？）
予期せぬタイミングでフォロワーが増える
元々は単純に実装時に作り込んでしまったバグなのですが、おもしろかったので残しました。
「こんな状態でテストに回すな」レベルの違和感バリバリのもので、TOP画面からマイページに飛ぶだけでフォロー数が勝手に増えています。
案の定、好評（？）で大盛り上がりでした。
お酒を飲んでいて楽しくなってしまっていたので仕方ないのですが、これはあまり構ってはいけないタイプのバグでした。
明らかにおかしいバグがあると楽しくてそこばかり深掘りしたくなるのですが、
先程の連打バグとは異なり、こちらは異常なことが明らかで容易に見つけられるものです。
このあたりは感覚な気がしますが、自分であればあまり深掘りはしません。
基本的な機能の明らかな異常がパッと見て見つかるのであれば、まず基本的な操作を一通り行います。
実装時及びマージする前によくレビューされていない可能性も考えられますし、こういった場合は回帰テストも不十分な可能性が高いです。
広く浅く探索し、まずはアプリケーションが落としたくない要件、致命的なバグを早く見つける方針です。
また、バグから派生して発生しているバグであれば根本の一箇所を直すと連鎖的に解決することがあるので、あまり派生バグを探すとバグ票の数が膨れ上がるする可能性もあり、対応の優先度を誤る二次被害も起こり得ます。
中枢を成すような機能に露骨なバグがあるときは別の機能に取り掛かる方が建設的であることも多いです。（感覚ですが。）
スマートフォンで閲覧
bootstrapを使ったのでスマホサイズでも致命的なことにはなりませんが、いい感じに表示が崩れるように確認を非常に雑に済ませました。
Webアプリケーションなので、ユーザーがどう利用するかを考えると気にしなければいけません。
スマホからのアクセスも当然、想定されます。
Webの業界にいればパッと思いつくかもしれませんが、例えば組み込みにしか触れていなければ出てきにくいかもしれません。
（自分も組み込みの観点はおそらくパッと出てこないです。）
そして、ここで気にしてほしかったところがUI/UX部分です。
PCを中心に使っているので、スマホからの操作性はむちゃくちゃなはずです。
何をバグとして報告するのか、その基準や感覚も人によってバラついていると思います。
自分は気にしないけどあの人はここを気にする、またその逆など、様々な人の意見にふれることができればと思っていました。
UI周りで余談ですが、タイムゾーンをUSにしておいたのですが誰もそこにはツッコミを入れてくれなかったので自分からツッコんでしまいました。
参加者の方々からは「そういうものだと思っていた」との声もありました。
つまりは言いたかったのはそういうことです。おもしろいですよね。
おわりに
当日は寝不足とアルコールの影響もあって、このあたりまで全体にお伝えできなかったことをここにお詫びします...。
大勢の方にご参加頂いたり、実行委員の方🥦に拙い自分の進行をサポートして頂いたりと、この場で感謝の気持ちもお伝えできればと思います。
バグを意図的に仕込む作業はなかなか楽しいものでした( WACATE 前夜 AM4:00でなければ... )。
チームや組織の中でテストの教育等にこのようなものを使ってみてもおもしろいかもしれません。
12月も過ぎ去りアドベントカレンダーでありながらアドベントカレンダーではなくなっているので、好き勝手書いていこうと思います。
気が向いたら その３ として、頂いた声のご紹介記事にでもしてしまおうかなと思います。
用語を定義するということ 〜ユニットテストってなに？自動テストってなに？パフォーマンステストってなに？〜
こんばんみ、halspringです。
ソフトウェアテストの小ネタ Advent Calendar 2019 の22日目です。
伝達の不具合
この記事のメインです。
「考えていることを伝える」ということは、思っている以上に難しいといった話です。
まず、我々は自分の考えを人に伝えるときに、主に言語を用います。
「考え」を「言葉」にコンバートするわけです。
既にタイミングで、
- 選択する言葉の誤り
- 情報の欠落
- そもそもの「考え」の誤り
の不具合が発生している可能性があります。
そして、言葉を伝えるときに、
- 伝達情報の欠落
- 伝達順序の誤り
- 言い間違い
などの可能性がありますね。
さらにはそれを受け取る相手がいるわけで、
- 聞き逃し
- 聞き間違い
- 認識の錯誤
- 知らない用語の補完ミス
などの要因で伝達ミスが起こり得ます。
防ぎたい不具合
例として口頭でのやり取りを挙げましたが、
これらは文章でもあり得ますし、絵でもあり得ます。
手段によって細かな部分のポイントは異なると思いますが、
考えや意思を伝達する上で大事なことは、「認識を揃えること」だと思います。
知らないことを想像するのは難しく、
曖昧なものは曖昧なまま補完され、
認識のズレたものは誤解を生みます。
そして、もう一度先程の混入し得る不具合を見ると、
防ぐことが難しいものと、防ぎやすいものがあると思います。
言い間違いや聞き間違いについては、注意していても防ぎきれません。
当人達以外に環境に影響されることもあります。
また、起こってしまっても言い直す聞き直すことが対応できるので、大きな問題にはなりません。
防ぎやすいのに大きな問題になりやすいのが、
「選択する言葉の誤り」「認識の錯誤」「知らない用語の補完ミス」
です。
ここをなるべく防ぎたい。
不具合の例
たとえば、「ユニットテストって大事だよね」と言われて何を思うでしょう。
それは、
テストレベルの文脈におけるユニットテストなのか、
TDDの文脈におけるユニットテストなのか、
はたまたそれ以外のユニットテストなのか、絞り込むことができません。
「自動テスト」はどうでしょう。
e2eのシナリオのようなテストなのか( その場合、e2eとはなんなのか )、
APIの返り値を見ているのか、
手動でないテストすべてを指しているのか、わかりません。
また、「パフォーマンステスト」と言われても、
想定されるリクエストより多くのリクエストを送って落ちないことを見るのか、
1リクエストあたりのレスポンス速度を見たいのか、
DBへのIOやバッチ処理に異常がないことを確認したいのか、
負荷がかかったときにスケーリングされることを確認したいのか、わかりませんよね。
取り組もう
特にソフトウェアテストに関しては、個人/組織/現場で特にこれらの認識がバラついているように思えます。
業界・組織レベルでこれらをうまく揃えることは難しいかもしれません。
ですが、プロジェクト単位であればどうでしょう、数人のチーム内ではどうでしょう。
規模の小さいところから、ガラパゴスな使い方になってしまっても良いので、
まずは用語を定義して認識を揃えることで、伝達時の不具合による不幸が減るかもしれません。
もちろん、ガラパゴスを推奨しているわけではありませんが、
所謂 公式（or のようなもの）にこだわり過ぎず、わかりやすい言葉を作ってみても良いと思います。
説明できない引用されただけの言葉より、説明できる非公式な言葉の方が健全です。
おわりに
はい、偉そうなことを言いました。
ですが 自分が思っていることで、大事にしていることなので、
自分の考えていることが少しでも何かのお役に立てばと思います。
ちなみに言葉の引用を否定しているわけではありません。
公式なものは共通して認識されている可能性が高いので、知っていることはとても大事です。
しかし、みんなが知っている可能性が高い故に疑いにくいです。
相手なくして「伝える」ことはできないので、
相手のことも考え、どの言葉なら錯誤が起きにくいか、曖昧な言葉はないかと考えてみると、
より「伝える」ことが楽しくなるかもしれません。
WACATEで分科会オーナーをやってきた 〜その１〜
独りアドベントカレンダー、日が空きすぎて何日目かわかりません。
執筆時点で20日ですが9日目です。時間軸が地球と同じと思うなよ。
そしてタイトルからわかるように、２本立て以上にする気満々です。
今回は分科会でやったことを、次はその感想や反省などを。
頂いたお題
wacateで分科会オーナーをやった感想をブログに書いて！
お題のご提供ありがとうございます。
ストイックなので、ちゃんと頂いたお題に答えるべくWACATEに参加し、分科会のオーナーに立候補してきました。
(WACATEについてはすみません、ググってください)
もともと「やってみたいかも」とは思っていたのですが、
なにせ人前は苦手でコミュ障なもので、こういった後押しがなければ実行できなかったと思います。ありがとうございます。
『モブ・探索的テスト』
はい、モブで探索的テストをしました。
自分がディスプレイに画面を映して操作を行い、参加者のみなさんにやってほしいことを挙げてもらいました。
目的
考えていたのは次のような感じです。
探索的テストをしたことがない人に楽しさ知ってもらいたい
参加者の多くが20代〜30代前半で、
なかには初めての勉強会としてWACATEに参加している方もいらっしゃいます。
業界によっても会社によっても仕事によっても、経験している業務は様々で 探索的テストを知らない方もいると思い、この楽しさを知ってほしいという思いがありました。
多様な観点を感じてもらいたい
WACATEの参加者はWeb系や組み込み系、toBやtoC、自社や客先、テストエンジニアやアプリケーションエンジニアなど多様性に富んでいます。
参加者にとって共通するような視点もあれば、知らなかった視点もあったと思います。
せっかく多様性にあふれているので、普段出会えない視点を知って何かを持ち帰ってもらえればいいなぁと思ったりもしていました。
（本当はバグ票まで書いてもらおうと思ったのですが、
20人近く参加してくださっていた気がしており、確実にグダるので控えました。）
テストアイテム
では、なにをテストするか。
結構悩んだのですよ、変にWebのサービス選んで関係者がいても気まずいですし。
そして不具合らしきものが見つかるのかも怪しいので、次の結論に至りました。
「自分で作ったろ」
「作りました。」
久々に家のPCでrails newしようとしたら環境構築で色々とつまずき、
サーバーもどうしようかと悩んだりして先延ばしにした結果、
前日の夜、仕事から帰ってから着手して当日の朝５時まで開発をする羽目に。
ご利用は計画的に。
そしてそれがこちらになります。名付けてwacatterです。
ご利用前に、注意点として、
- email は実在するものを入れる必要はありません。
- むしろ個人情報扱いたくないのでそのへんは適当に入れてください。
- パスワードはちゃんとハッシュ化していますが使いまわしにはご注意ください。
- 一応、XSSやSQLインジェクションなど本当にヤバいやつは防いでいるつもりです。
- 個人情報の投稿なども控えてください。
- なにかあっても責任取れません。
- 負荷を掛けるのも控えてください。無料枠なので普通に落ちて1日使えなくなります。
基本的にはtwitterみたいなものなので、なんとなくで使えると思います。
前述の通り 急ぎで深夜に作ったため、生々しいバグをたくさん残してあります。
わざと仕込んだものもあれば、作り込んでしまったけど直さず残しているバグもあります。
なにがサービスにとって深刻なバグで、
リリース後の修正でも問題のないバグはどういったものでしょう。
そんなことを考えながら遊んで見てください。
データが残りっぱなしだときったねぇので、一定時間でデータを全部消すようにしようかなとも思ってます。
面倒だったらそのまま残っていることでしょう。
せっかく作ったので、参加者のみなさんもブログを読んでいる方も、
探索的テスト以外にもテスト設計の演習だったり、技法の当てはめ方を考えたりするのに使ってみてください。
ただし、本当にひでぇバグを残したままなので「こんなの持ってくるなよ、テストできるレベルじゃねぇぞ」という意見はお控えください。傷付きます。
時間がなかったので一部コピペエンジニアリングもしたので、そういった情報もネタにしながらテストするといい感じにバグが出せるかもしれません。
オーナーの感想、反省は次回に続きます。
テスト以外でQAが貢献できる活動
独りアドベントカレンダーの8日目です。
誰がなんと言おうと8日目です。投稿日は見ちゃダメ。
お題
アジャイル開発に関わるQAエンジニアが、テスト計画、テスト設計、テスト実行、不具合報告などメジャーなテスト作業以外でプロジェクトに貢献できる「活動」としてはどんなものが考えられますか？
DMにて頂きました、お題の提供ありがとうございます！
前日の記事でQAエンジニアとしてのお仕事について書きましたので、そことは少しズラした観点でどんなことが考えられるのか書いていきます。
テスト以外の関わり
参拝
冗談のようなものから...
はい、お参りに行ったりします。
考えるだけ考えて、尽くすだけ尽くして、
「あとは祈るだけだ...！！」ってときありますよね？
なのでちゃんと全力で祈ります。
アジャイル関係ないので、ちゃんとした内容書きますね。
ツールの導入支援
テストツールに限る必要はないですが、自分達の得意分野で合ったほうが良いと思います。
より開発しやすくなるのなら、より効率良くなるのならツールの導入支援もQAエンジニアの活動に入ると思います。
ただし、むやみにツールを入れればいいわけではなく、チーム内の課題を解決するために適しているものがあれば程度にしたほうが良いと思います。
あまりちゃんとしたツールでなくとも、例えばbotでも良いです。
自分はよくチーム内で面倒事や忘れがちなものがあればすぐbot化してslackで通知させたりしています。
スクラムマスターではないですが、チームが気にしなくてもよいことはチームが気にすることのないようにしてあげた方が良いですよね。
ペアテスト
(メジャーなテスト活動ではないのでおそらくセーフ)
開発者とペアになって探索的テストをするなどいかがでしょう。
ペアでなく、モブでも構いません。
テスト側がどう考えているのかを開発側が知ることもできますし、開発者の目線をテスト側が知ることもできます。
仕様を確認するときも知っている人が隣にいるのですぐ聞けます。
雑談
プロジェクトに直接関係のない話もできますね。
「最近調子どうですか？」「ちゃんと寝れてます？」など体調の話が特に自分は好きです。
プロジェクトに対して不安なことを聞くときに、個人的(プライベートでも)に悩んでいることを差し支えない範囲で質問しています。
体調が悪いときはパフォーマンスが下がりますよね。
もちろん、急にお休みしてしまう可能性もあります。
機械と一緒に仕事をしているわけではないので、そのあたりも考えてケアしてあげるくらいの気持ちでいたほうが良いでしょう。
言い方はアレですが、立派なプロジェクトリスクです。
（もちろんそんな冷たく「仕事だから」みたいなものではなく、本心から心配なのできいていますよ。念の為。つらい思いをして欲しくないのです。）
いること
これは我々の組織の関わり方だからかもしれませんが、
いるだけでも違うらしいです。
定例に混ざってプロジェクトを見てくれている、
テスト仕様書のレビューに入ってくれている、
探索的テストでQA側も見てくれている、
それだけで「心強く、安心してプロジェクトを進められた」と言ってくださります。
ありがたい...
チームが精神的に安心できるように、より快適になるためにできることは、
できる限り叶えてあげることも（やり過ぎではあるかもしれませんが）大事だと思っています。
自分は、良いプロダクトが不幸な現場から生まれるとは思いません。
良いプロダクトは、良いチーム、良い環境からこそ生まれるものだと思います。
ですので、自分は品質を良くするためにこれらの活動をとても大切に思っています。
