ウェブサービスの不具合の見つけ方。僕なりの方法。

元ミクシィのエンジニアによるex-mixi Advent Calendar 2017の７日目です。

アドベントカレンダー２５日間埋まらないんじゃないか？　と思いきやしっかり埋まってますね。Advent Calendar 2017 Ranking - Qiitaの上位を目指して頑張りたいですね。現在は３桁位ですか・・・。

アドベントカレンダーでは「ミクシィを退職し、インドの山奥でオーガニック系日本料理屋を営むようになった理由」という名前にしてたけど、嘘です。ごめん。

【追記】いま見たら５位になってた、すごい。

近況

さて、私のミクシィグループへの在籍期間は2013年3月から2015年12月までした。

大本のミクシィに在籍していたのは最初の半年間でmixiメッセージのチームに在籍してました。

その後Find Job!で約2年間仕事をしてました。Find Job!での最後の仕事はサイトリニューアルのプロジェクトでした。

その後スタートアップにJOINしたりフリーランスをやったり、岡山に戻ってきたと思いきやまた首都圏に戻ってきたりで、現在はPOSレジアプリを開発運営している株式会社ユビレジというところでソフトウェアエンジニアやってます。

ものを壊すのが得意な程度の能力

ところで、僕はよく物を壊します。高校生の時は物理や化学の授業の時に使う実験器具をよく壊してました。今年は買ったばかりのスマホを５日で落として破壊しました。修理に戻ってきたスマホも３ヶ月後にまた破壊しました。

その、ものを壊す能力がサービス開発にどう役立つかというと、大いに役に立ちます。ウェブサービスは人間が沢山見るわけで、自分と同じ壊し能力者がいるし、その人達はエンジニアでもなんでもないわけなので「なにもしてないのに壊れた！！！！！１１１」となって、カスタマーサポートへお問い合わせされるわけです。お問い合わせして頂けるならまだしも「バグってるからつかうのやめた」になると目も当てられないわけです。

以下はそれを未然に防ぐために私が開発中に気にしていることの一例です。

複雑な事例を想像して気になるなら手元で動かしてみる

サービスのとある機能を開発するということになりましたとしましょう。既存のコードを読む他に、本番かステージングでこの部分がどうなっているのかを触って「いまはこうやって動いてるのか〜」と試したりすると思います。すると、いくつか疑問が生まれると思います。生まれないかもしれないですけど。 mixiやFind Job!は自社フレームワークを使っているのでOSSなWebフレームワークより脆弱性周りには気をつけてたと思います。Railsなんかはそこらへんしっかりと未然にふせいでくれるので「こんにちはこんにちは!!」みたいなことはできないと思います。

以下はいまパッと思いついたやつです。適当に思いついたのをならべてみました。

• グループチャットに２人招待。ある程度会話が進んだあと、もう１人招待。その１人は前にいた２人からブロックされていたら前の会話はどう見える？
• ログインしなくても押せる「いいね！」ボタンのPOST先URLに10000回POSTしたらどうなる？
• 140文字制限のあるミニブログに50万文字くらいコピペして貼り付けたらどうなるの？？？
• 外部サービス連携のOauth認証ページで、９割９分くらいの人が「はい」を押す所で「いいえ」をおしたらどうなるの？
• バナナはおやつに含まれる場合、チョコバナナケーキやバナナマンを連れてきたらどうなる？？？？？

大量の文字を入れた時の例。今は修正されているけどちょっと前試した時に一度に消せなくて非常に困った。ブラウザ閉じても入力中の文字は保存されていて残ってしまう。

実際にやってみてヤバイのかヤバくないのか

実際にやってみておかしな挙動が起きたとします。おかしな挙動の周りには応用したりあわせ技で、もっとおかしなことができてしまうことがあるので時間があればそのへんも遊んでみるといいと思います。

試したら、試した結果をGitHubのissueなりなんなりで文章に起こします。その時、ヤバさレベルの高さ・低さもわかれば書いてみるといいです。

ヤバいもの

• これをやるとサービスが高負荷で止まるなど、使っている人だけでなく、他人に影響がでる。
• 魔法石が特定の操作をするとn個無料で手に入る、表示上の売上と実際入ってくる金額が違うなど、お金に直に影響するもの。
• 求人サイトなのにユーザーが応募できなくなる、ECサイトなのに購入できなくなるなど、KPIに影響するもの。

そんなにヤバくないもの

• 特定の操作で、画面の表示が崩れる
• 通知のバッチ数が実際の数より多い
• 「投稿を非表示」にした投稿がまた表示される。

ヤバいものに関して起こる可能性が高いものに関しては、その日の朝会を待たずにエンジニアチーム全員で共有して最優先で直すべきだと思います。

不具合に対する嗅覚は正直わからん

今までのエンジニアライフを振り返ってみると、私は新しく開発するよりむしろ既存の不具合を見つけたりそれを直したりするほうが得意なようです。 エラーログからユーザーがどういう操作しているかとかを見つけたり、推理したりするときは推理小説を読んだりするときのようにワクワクするのかもしれないです。

そこらへんの嗅覚とか不具合の見つけ方なんかを書いた「ソフトウェアテスト」みたいな本を読んでみたけどあまりピンとこなかったです。 他にオススメな本があれば誰かおしえて欲しいなあ。

でも正直な所、自分の胸に手を当てて考えるとウェブサービスで色々遊んでみることが大事じゃないかなと思います。 新しいサービスがリリースされたらdeveloper toolで通信を見たり、htmlを読んでみたり、いたずら心で色んな入力を試してみたりするのが良いのかも？？？　しれません。（バグを見つけたらこっそり中の人に教えてあげましょう :p ）

明日はyuji0602さんです。なんか書くとのことなので、なにかに期待しましょう。何卒よろしくお願いします。