WACATEで分科会オーナーをやってきた 〜その２〜

独りアドベントカレンダー10日目です。

ご存知でしたか、年度内ならまだアドベントカレンダーなのです。

（色々忙しかったり体調が不安定だったりでこんなことに）

前回の記事はこちらから。

前回の記事が「分科会オーナーやってきた」の表側、

今回の記事がそのコンテンツを作るときにどう考えていたかの裏側だと思っていただければ。

考えていたこと

「きっかけ」をつくる

探索的テストに触れたことない人も少なくなさそうなので、まず「知る」「触れる」機会をつくれればと思っていました。

組織によっては探索的テストにまったく触れることがないこともあると思います。

別にそれが悪いこととは思いませんが、「知る」に至らないことには選択することもできないのでこちらは良くないと思っています。

観点の違いを知る

次に、触れたことのある人にはどんなことを感じて学んで欲しいかを考えていました。

単純ですが、観点の違いです。

経験ベースのテスト故に、人によって よく見る観点は異なり、偏ります。

探索的テストをしている人が10人集まれば、10人がそれぞれ異なる流れで、異なることを気にしながらテストをするでしょう。

ましてや年齢も経験も異なれば、webや組み込みなど業界も異なる集まりです。

普段はあまり出会えない観点に出会って刺激になれば、というのが経験者に対しての狙いでした。

「モブ」テスト

2つ目と少々被りますが、WACATEにはテスト専門ではなく普段は開発専門な方も参加しています。

モブでテストの中で、同じものを見ていても「テストの人」「開発の人」がそれぞれ異なることに着目したり、異なる経験からバグを探し出すでしょう。

これを体験して、互いに歩み寄るための好奇心を少しでも生み出せればと思っていました。

どんな狙いでどんなバグを仕込んだのか

壮大なネタバレですが、正直時間もなくテストアイテムとしてそこまで優秀とも思えないのでいいでしょう。

ここに挙げたもの以外にも仕込んであるので、楽しむ分には差し支えないかと思います。 

また機会があればちゃんと作ると思います。

ボタンを連打すると○○系

コッテコテのバグです。

お気に入り/お気に入り解除、フォロー/フォロー解除用のボタンを連打することで意図していないであろう操作ができます。

まずひとつを見つけ、残りを予測して見つけて欲しいという狙いがありました。

開発知識のある人に「伝われ...ｯ！！」の想いで「トグル処理になっていないので連打するとお気に入り数を爆上げできます」と一言ざっくり解説を添えました。

「過剰にお気に入り数を増やせる」ということは、リレーションが重複して作られてしまう（トグルでない）つくりになっているので、解除はリレーションを削除しているものと予測できます。

試してみるとひとつずつお気に入り数を減らせるので、推測が合っていそうなことがわかります。

では、解除ボタンを連打してリレーションが0個になったときにボタンが押されたらどうなるでしょう。

存在しないリレーションを削除しようとして500エラーを吐きます。

また、これらはお気に入りで発生した、つまり1対Nの関係にあるもの、リレーションテーブルを使っているであろう機能で起きている可能性があります。

なぜならこの機能を実装した人はトグル処理ではなく「リレーションがなければリレーションの作成、ひとつでもあれば削除」のロジックで実装をする人だからです。

同じような機能は同じように作っている可能性が高いですよね。

（欠陥の偏在？）

予期せぬタイミングでフォロワーが増える

元々は単純に実装時に作り込んでしまったバグなのですが、おもしろかったので残しました。

「こんな状態でテストに回すな」レベルの違和感バリバリのもので、TOP画面からマイページに飛ぶだけでフォロー数が勝手に増えています。

案の定、好評（？）で大盛り上がりでした。

お酒を飲んでいて楽しくなってしまっていたので仕方ないのですが、これはあまり構ってはいけないタイプのバグでした。

明らかにおかしいバグがあると楽しくてそこばかり深掘りしたくなるのですが、

先程の連打バグとは異なり、こちらは異常なことが明らかで容易に見つけられるものです。

このあたりは感覚な気がしますが、自分であればあまり深掘りはしません。

基本的な機能の明らかな異常がパッと見て見つかるのであれば、まず基本的な操作を一通り行います。

実装時及びマージする前によくレビューされていない可能性も考えられますし、こういった場合は回帰テストも不十分な可能性が高いです。

広く浅く探索し、まずはアプリケーションが落としたくない要件、致命的なバグを早く見つける方針です。

また、バグから派生して発生しているバグであれば根本の一箇所を直すと連鎖的に解決することがあるので、あまり派生バグを探すとバグ票の数が膨れ上がるする可能性もあり、対応の優先度を誤る二次被害も起こり得ます。

中枢を成すような機能に露骨なバグがあるときは別の機能に取り掛かる方が建設的であることも多いです。（感覚ですが。）

スマートフォンで閲覧

bootstrapを使ったのでスマホサイズでも致命的なことにはなりませんが、いい感じに表示が崩れるように確認を非常に雑に済ませました。

Webアプリケーションなので、ユーザーがどう利用するかを考えると気にしなければいけません。

 スマホからのアクセスも当然、想定されます。

Webの業界にいればパッと思いつくかもしれませんが、例えば組み込みにしか触れていなければ出てきにくいかもしれません。
（自分も組み込みの観点はおそらくパッと出てこないです。）

そして、ここで気にしてほしかったところがUI/UX部分です。

PCを中心に使っているので、スマホからの操作性はむちゃくちゃなはずです。

何をバグとして報告するのか、その基準や感覚も人によってバラついていると思います。

自分は気にしないけどあの人はここを気にする、またその逆など、様々な人の意見にふれることができればと思っていました。

UI周りで余談ですが、タイムゾーンをUSにしておいたのですが誰もそこにはツッコミを入れてくれなかったので自分からツッコんでしまいました。

参加者の方々からは「そういうものだと思っていた」との声もありました。

つまりは言いたかったのはそういうことです。おもしろいですよね。

おわりに

当日は寝不足とアルコールの影響もあって、このあたりまで全体にお伝えできなかったことをここにお詫びします...。

大勢の方にご参加頂いたり、実行委員の方🥦に拙い自分の進行をサポートして頂いたりと、この場で感謝の気持ちもお伝えできればと思います。

バグを意図的に仕込む作業はなかなか楽しいものでした( WACATE 前夜 AM4:00でなければ... )。

チームや組織の中でテストの教育等にこのようなものを使ってみてもおもしろいかもしれません。

12月も過ぎ去りアドベントカレンダーでありながらアドベントカレンダーではなくなっているので、好き勝手書いていこうと思います。

気が向いたら その３ として、頂いた声のご紹介記事にでもしてしまおうかなと思います。