【探索的テスト】ウォーリーをちょっと探してみた

まつやまです。

探索的テストについて、「ウォーリーを探せ、をやりこむと分かるよ」というアドバイスをいただきましたので、まずはちょっとだけ探してきました。 図書館の児童書コーナーで。

赤いシマシマパターンを探す作業

まずはウォーリーの特徴である「赤いシマシマ」を探します。 ウォーリーはそれなりに簡単に見つかりました。

ウォーリーの特徴は「赤いシマシマ」だけではない

この絵本には、ウォーリー以外にも「似たようなキャラ」が登場します。ほぼ服装は似ていますが、ウォーリーは「男性」「メガネをかけている」などの特徴があり、場面内に本人はひとりしか登場しません。

いちどにメモリに残せる情報は少ない

これはぼくの頭の癖なのだと思いますが、ウォーリーを探す際、「ウォーリーの特徴をすべてインプットしてから探索する」のではなく、「最も特徴的な特徴をインプットして、手当たり次第探索する」「最も特徴的な特徴に合致した場合、次の条件を適用する」となりました。 探索の順序としては、「まず赤いシマシマを探す」「次に、ウォーリーか否かを判断する」となりました。

これは自分の思考を振り返ってみて、とても面白いなと感じたところです。

ウォーリーを探している間、他の情報は見えなくなる

ウォーリーを探せ！の世界では、だいたいあちこちでトラブルが起こっています。絵画が水を吹き出していたり、川に人魚がいたり、鉄道から牛が脱走したり。けれども、「赤いシマシマ」を探している間、これらの情報は全く頭に入ってきません。視界には入っていますが、認識できません。

ページ上部の本文で「ほふくぜんしんをしているひとをみたよ！」と言われない限り、匍匐前進をしている人にも気づけません。ところが、本文を読んだ瞬間、逆にそこが浮かび上がって見えるようになります。これがすごく面白い。

ウォーリーをちょっと探してみて学んだこと

身の回りで起きている様々な事象に対して、いちどに認識できる範囲は驚くほど狭く、また、何かしらのキーワードで意識を傾けないと、情報はそこに存在しているだけで、認識できないのだと体感しました。

探索的テストでチャーターを設定する意義が、ちょっとだけわかった気がします。

ということで

これからもウォーリーを探し続けてみたいと思います。ゴールは「やり込んだ」と思える程度で。

レビューを語る夕べ 第3回　簡易まとめ

先日参加した「レビューを語る夕べ 第3回」をまとめようと試みていますが、時間がかかりそうなため、簡易まとめを出してみようと思います。 登壇者の方の解釈と異なる可能性がございますが、ご了承ください。


レビューを語る夕べの狙い

レビューのスキル教育において、特に暗黙知の継承をどうしたら良いか考えたい


インプット資料

togetter.com


当日話されたこと

  • レビューをする際、成果物の一部を主観的に「怪しい」と感じることがある/感じる人がいる
  • 主観的な「怪しい」を感じ取るための(プロセスの精度を上げるための)オレオレ技法がある
  • 逆に、ゲーティングのレビューなどでは主観の影響をなくすためのオレオレ技法がある
  • 「魂」や「熱意」など、ロジカルに説明することが難しいと感じるものがある
  • 指摘事項を指摘するべきタイミングは、個人によって解釈が異なる
    • たとえば例外に関する指摘について、ソフトウェアの設計レビューで行うものだと考えているか、テスト設計のレビューで行うものだと考えているかといったことが個人によってまちまち(この認識がずれた状態でWモデルを採用すると失敗する)


感想

  • ひとくちに「レビュー」といっても、参加者のバックグラウンドが様々異なるため、フォーカスしづらい
  • ある程度ペルソナ的なものを用意して、議論のスタートを揃えたほうがいいかも？


当日のハッシュタグまとめ

togetter.com

第1回 テストもぐもぐ会

とりあえず言いたいこと

オムそばさんの企画力すごい

とりあえず言いたいこと　その2

お料理がすごく美味しかった

トゥギャりました

togetter.com

「テスト」にまつわるお題

めっちゃ真面目なお題ばかりでした。すごい。

色々なお題がありましたが、「テストにまつわるお悩み」が多かったですね。

  • いまからテストを学ぶ新人に伝えたいこと
  • テスト管理ツールについて意見交換したい
  • テストって楽しいの？
  • XXなことがあって正直つらい
  • QAが増えなくて悩んでいる

などなど。

プロジェクト全体の見通しが悪いことで自分のロールがわかりづらかったり、自分がコントロールできない領域に対してもどかしさを感じていたり、単純に作業感がすごくて精神的に辛かったり、いろいろお悩みがあるのだなあ。。。と感じました。

僕が用意していったお題は完全に休日向けで、遊び要素しかないものでしたので、また別の機会にもぐもぐお話しできればと思います。

個人的に面白かったこと

ブロッコリーさんやなそさんの話のアプローチがとても面白いなと感じました。 「立ち返りの問い」を投げることで、お題を出した人のお悩みを深堀りし、「お題の再設定」を促していらっしゃったと感じます。

個人的に面白かったこと　その2

僕自身は、バグを検出すること自体に快感を覚えるタイプの人間なのだということをあらためて自覚しました。

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

まつやまです。

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

ポメラとは？

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も大事
  • テストはなくならない　テストはしないといけない
  • テストの手段にあった組織作りが大事
  • テストエンジニアがフリーになるかも
  • アジアのエンジニアで一緒にやろうぜみたいなことも今後起こってくる

感想

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