CAT GETTING OUT OF A BAG

What the tester is thinking.

JaSST Online Bergamot に参加しました #JaSSTOnline

JaSST Online Bergamot に参加したので感想などをつらつらと

www.jasst.jp

セッション1「探索的テスト」

ゲストにnemorine氏をお招きし、事前に実施の様子を撮影して頂いた探索的テストの動画を視聴します。
視聴をしながら質問者が随時気になったところで動画を一時停止し、ゲストに対して質問を行い探索的テスト実施時の内容や当時の思考を深堀りします。
質問者は実行委員及び、参加申し込み時に質問者オプションを購入いただいた参加者になります。

これオンラインでどうやるんだろう?と想像できなかったのですが、面白そうなので「質問者オプション」を購入しました。セッションの雰囲気は『相席食堂』、質問者は千鳥のイメージです!とお聞きしたので、民間公式テレビポータル『ティーバー』をインストールしてさっそく視聴。なるほど。芸能人が全国各地でロケを行い、そのVTRを千鳥が鑑賞し、気になる点があれば手元の「ちょっと待てぃ!」ボタンを押してVTRを止め、ツッコミを入れながら見守る番組なんですね。*1

様式はなんとなくわかったものの「あの物理ボタンはどうするんだろう?」と疑問は残りました。当日は早押しボタンオンラインを使いました。世の中にはいろんなツールがあるんだなぁ。素晴らしい。

@nemorin さんが探索的テストしたテスト対象については、開催日の二日前に資料が公開されました。TwitterぽいWebアプリケーションです。株式会社LIFULLさん がテスト研修の際に利用しているサンプルアプリケーション(わざとバグが埋め込まれている)だとか。これまた素晴らしい。自分たちが開発してる製品(本物)でテストするのが一番いいと思うんだけど、本物だとちょうどいい感じのバグって出ないもんね。教えたいことを逆引きしてバグとして事前に仕込んでおいてそれをネタに幅広く解説したり、なんならソースコードを修正してうまく動くところまで確認できる。とても良い取り組みだと思いました。

参加するにあたってのモチベーション

  • テスターのあたまの中にあることを質問をとおしてあぶりだしてみたい(書籍や教科書には載っていないような何か)
  • 自分の開発(テスト)脳への刺激、エッセンス

@nemorin さんを同僚だと思って一緒に開発(テスト)する気持ちで参加しようと思いました。自分だけが気持ち良くなったらたぶん失敗で、これは普段の開発でも同じです。

今回のシンポジウムは開発(特にテスト)が好きな人や得意な人が参加するはずなので、探索的テストの様子を見ながら様々な視点や観点でバグを探すんだろうなと想像しました。実際そうでしたね。そこは参加者のみなさんにお任せすることにしました。すごく楽しそうだったけど我慢した!(はじめにそう決めておかないと絶対バグを見つけようとして本来やりたいことができないのがわかっていたから)

早押しボタンが反応しない

当日のお昼過ぎに早押しボタンのURLが公開され動作確認も済ませていたのですが、セッション中に早押しボタンを押しても「ピンポン♪」と鳴りません。連打とか長押しとかいろいろやってみたのですがいっこうに反応しない。そんなことはお構いなしに探索的テストの動画は進んでゆく…。

どうしたらいいのかわからなくて流れの遅かったzoomのチャットに助けを求めました。SafariじゃなくてChromeがいいかもとかiPhoneでやってみたらどうかとか「みわさんは口ピンポンでいいです」などなどアドバイスをいただきました。ライブ中に本当にすみません。結局iPhoneでやりましたがまた動かなくなってしまい口ピンポンも投入しました。他の質問者の方は問題なく動いていたようなのでわたしのブラウザ(Safari)の設定が気に入らなかったのかも。

自分たちの開発(テスト)とのちがい

開発の仕方が違えばテストのやり方も変わるので単純に比較はできないのですが、普段自分たちが当たり前にやっていることを差分として感じることができたのでメモしておきます。良い悪いの話ではありません。

一度にテストする範囲が広すぎる

今回1時間でTwitterぽいアプリケーション全体を触りましたが、自分たちの開発ではこういうのはないです。もし1時間しかないのだったらテスト範囲をもっと絞ります。製品を触りながらテストしていき、小さな綻び(違和感)を見つけたら、さらに深さ方向に探索していきます。バグを仕留めたら(こんなバグが見つかるならあっちも心配だ)といったん地上に出て水平方向や斜め方向に移動し関連性がありそうだと思う場所をさらに探索、といった感じです。いま目の前で起きていることを観察し、自分の脳内に蓄積されている情報を使い、都度判断しながら探索していく。こういった一連の流れは「探索的テスト」の醍醐味の一つなのではないかと思っています。*2

動画を見た参加者が「ああ、探索的テストって1時間であんな風にアプリケーション全体を草原を走るようにさらっとテストすればいいんだな」と誤解されないかヒヤヒヤしました。さらっと見えるかもしれないけど @nemorin さんがやってたのはそんなに簡単なことじゃないんだからな!

わりと仕様書を読み込んでテストしている

わたしたちのチームは朝会でチケットを音読します。チケットは仕様書(よりももっと詳細)でプログラマーやテスターと議論した内容とともに毎朝強制的に頭に入ってきます。

実際にテストをする前にもチケットを読み返して一度おさらいしてからはじめることが多いです。どのように動くのを期待している/期待していないがだいたい頭の中に入っていないとテストできないんですよ。うまく言えないけど自分が期待しているパフォーマンスでテストすることができません。たぶんテストしながら目の前で起きる一瞬一瞬の動きやふるまいを脳内にある期待値とコンペアしてるのだと思います。もちろん仕様書自体が間違っていることもありますし、これまでは正しい仕様だったけど今も正しいかは分からないし、自分の脳だってバグっているかもしれないので、疑うことは忘れてはいけませんが。

そういうわけで前述した内容とも関連しますが、アプリケーション全体の詳細な仕様を頭の中に全部入れるのは無理なので、テスト範囲をもっと絞るということになります。わからない部分はその都度仕様書を読めばいいのでは?と思うかもしれませんが、それだとやりたいテストとスピードがぜんぜん合いません。*3

「探索的テストする」って言ってない

今回のテーマは「探索的テスト」ですが、普段「探索的テストする」って言ってないなと思いました。それだけです。

OST: 探索的テストをやるタイミングについて

Open Space Technology で shiromoto さんのテーマ「探索的テストをやるタイミングはいつにしてますか?」に参加しました。この問いについてのわたしの答えは「いつもです」としか言いようがない。テスターもたぶんプログラマーも毎日やっているので感覚がおかしくなっているのかもしれないけど、探索的テストってそんなに特別なものではないと思っています。わたしたちのチームがレアケースすぎるのかな。もしかしたらテーマの捉え方が違うのかもしれないし(前半は離席していた)、探索的テストという用語の解釈がずれてる可能性もあるな。わたしがいつも毎日やっているのはTestingだしな。そんなことを考えていました。

OST: 探索的テストをどうやって勉強、指導するかについて

Open Space Technology で とろ さんのテーマ「探索的テスト、どうやって勉強しますか?どうやって指導しますか?」に参加しました。テスト対象(製品やサービス)ではなくテストそのもの(テクニック)を対象に話してみたいとのこと。わたしはこんなことから日々学んだり、テストの幅を広げています。

  • 同僚(テスターやプログラマー)との会話
  • テストしている同僚の横に座って見てる(気になったところは教えてもらう)
  • ペアテスト(プログラマーともやります)
  • テーマを決めてチケットシステムを全文検索し過去の開発や起きた問題を斜め読みしながら、これから起こりそうな嫌なことを妄想する(バグをとらえるための瞬発力を鍛える訓練だと思ってやってる)
  • 他チームの開発者との会話(開発の仕方や最近見つけた面白い不具合とその原因について教えっこする)
  • 同僚(凄腕テスターSさん)になりきってテストする
  • 若手開発者とテストに関する本を読む

miwa719.hatenablog.com

この読書会、週1回のペースでやっているのですが1年半も経つのにまだ読み終わってません。途中でHAYST本に寄り道したのもあるけど毎回脱線しながらじっくりやっています。本に書いてあることが呼び水となり、お互いの開発(若手開発者とは開発してる製品が違う)について話していることが多いです。*4

勤続年数的には指導する立場なのでしょうけど、まだまだ知らないこと、分からないことも多くいつも一緒に学んでいます。

この練習帳がなかったら、社内教育に対して暴言を吐いておしまいになっていたかもしれないので助かりました。

  • 『ソフトウェア技術者のためのバグ検出ドリル』を解く

miwa719.hatenablog.com

  • iOSアプリやAppleWatchアプリを作って遊ぶ(無限にテストできます)

このテーマだけで1本記事が書けそうだけど、これくらいでやめておこう。*5 

当日使用したマイク

これまではiPhoneについてきたおまけのイヤホンを使っていたのですが、オンラインでのコミュニケーションは音声品質がすごく大事!と実感することがありまして、今回のシンポジウムに合わせて購入しました。でも自分では自分の声を聴くことはできないのである。どうだったんだろうか。

もっといろいろあったような気がする。思い出したらまたあとで書きます(更新したらツイートします) 


 

*1:このとき視聴したのがショーガールのブリアナ・ギガンテさんが大阪府枚方市にあるテーマパーク(ひらかたパーク)で遊ぶ回でした。

*2:ケースバイケースですが、検出したバグの修正に影響しそうなところはもう触らないことが多いです(直した後にそこも含めてテストしようという思考に変わる)。どこら辺まで修正の影響が及ぶのか分からないときは「ここをテストしようと思っているけど、あのバグが直ってからのがよいか」をプログラマーに相談するときもあります。

*3:車の運転中にあることがしたくて取扱説明書を見てしまうと、それをしたかった時と場所と状況にはもういないイメージです。

*4:先週、最終章の第6章「多次元の品質」に入り、ようやく終わりが見えてきました。

*5:ここにあげたものの多くは手段であって、ここから具体的に何を学び、どうテストに活かすのかは書いてないのだった。