CAT GETTING OUT OF A BAG

What the tester is thinking.

2018年はどのようなタイプのバグが検出されているのか(3)

このエントリーは こちらの記事Google 翻訳を使って雑に読んだときに、わたしが何を考えていたかのメモです。マニア向け!

applitools.com

SearchDown

  • ウェブページの右上のアイコン(サインイン、カートなど)の上に、検索用のテキストボックスが重なってしまう問題
  • スクリーンショットをよく見ると、上半分くらいアイコンが見えてるけど"Search box blocking shopping cart on ThredUp Website" と書いてあるから、押せなかった(お買い物ができなかった)のでしょうね
  • 前回、"経営情報は「テストする順番を決める時の軸のひとつ」として使えそう" …と、大層なことを書いてしまったので(仕方なく)調べました
  • メルカリだけじゃ無い! 海外の中古品売買スタートアップ12選  


なぜそのバグが起きてしまったのか

  • 前回前々回もそうだけど「なぜそのバグが起きてしまったのか」が、気になります *1
  • この SearchDown だと、こういうの(想像です)
    • 左端に貼ってあるロゴのサイズをすこしだけ変えたら(意図せずに)検索用のテキストボックスの位置がずれてしまった
    • ブラウザ間でのデフォルト位置、px指定に差異があった
    • リリース前に重なることに気がついて修正したのに、コミット漏れ(エアコミット)してしまった
  • 要は『失敗から学ぶ』みたいな話なんだけど「みんな学べ!」ではなく(わたし自身が)そこから学び、開発(テスト)に利用している感が、とても強い *2

問題のサイトを見てみよう

f:id:miwa719:20180925164629p:plain

  • 現在は重なってませんね(Safari 11.1.2)
  • ウィンドウの大きさを小さくしてみたらどうなるかな(ぎゅーーん)

f:id:miwa719:20180925164435p:plain

  • 大丈夫でした
  • せっかくなので iPhone(iPhone 6s Plus / iOS 12.0) でも試してみたよ
  • 縦画面

f:id:miwa719:20180925172514p:plain

 

  • 横画面

f:id:miwa719:20180925172533p:plain

  •  大丈夫でした

thredUP

  • アメリカ(サンフランシスコ)で、新品のような厳選した古着をオンラインで販売するお店
  • 個人間取引ではなく CtoBtoC(査定、撮影、仲介してもらえる)
  • だから、ウェブサイトの写真も統一感があって、綺麗なんですね
  • 洋服、靴、Bag、アクセサリー大好きなので、見てるだけでも楽しい(時間が溶ける)

www.thredup.com

 

*1:「調査の結果、そうなるように実装してました!!」とか言うと、わたしが暴れるので注意しような

*2:この辺の話をはじめると長くなるので省略

2018年はどのようなタイプのバグが検出されているのか(2)

このエントリーは こちらの記事Google 翻訳を使って雑に読んだときに、わたしが何を考えていたかのメモです。マニア向け!

applitools.com

Wanna Get A Way (to Book)

  • 航空機のチケット予約画面で、利用規約とContinueボタンが重なって、Continueボタンが押せなくなってしまう問題
  • 前回と同様、視覚的な問題ですね
  • Continueボタンの描画順が利用規約より後なら(重なりはするけど)ボタンは押せたのかもしれないな
  • 視覚的な問題は見つけやすいんだけど、見た目に重なってないから大丈夫かというとそうでもない
  • 透明な何か、が重なっていると見た目にわからないのだ
  • ボタンは押してみましょう
  • 変態さん*1になると、何もないところも押すようになります(ここに人間の目には見えない透明なボタンがあるかもしれない…)

テスターと経営情報

  • ところで Southwest Airlines website では1時間ごとに $2.5M を稼いでいるそうです
  • この記事を書いてる時(2018.09.24 11:00 JST)の為替レートは 1ドル=112.58円
  • 予約操作が1時間できないだけで、約2億8000万円の損失か!
  • 視覚的な問題は、軽く受け取られてしまうものもあるけど、そのソフトウェアの利用者数や、稼ぎっぷりを知っておくと、ダメージも想像しやすい
  • ダメージが想像できると、バグを報告するときの伝え方(騒ぎ方)が変わるかもしれない
  • そのソフトウェアにとって「致命的なバグ」とは何か(そこはいつも気にしてテストしたいし、絶対不具合を出したくないところ)
  • 経営情報って1テスターからみると、なんとなく遠い存在なんだけど、こうやって考えてみると「テストする順番を決める時の軸のひとつ」としても使えそうね
  • 競合他社がどれくらいいるかも知っておくと良さそう

 問題のサイトを見てみよう

f:id:miwa719:20180924114239j:plain

  • 現在は、利用規約とContinueボタンは重なってません
  • 2週間くらい休んで海外旅行したいな(次回はイタリアに行く予定です)

Twitter for iOS でも似たような問題が起きてた

  • 半年くらい前のバージョン 7.19 で起きてた
  • 前回の記事 にも通じる問題ですね
  • 起こりやすい問題(頻出バグ)のひとつなのかもしれない
  • 長い文字列は有能(問題を見つける力がある)

*1:わたしのようなテスターのこと

9月9日はテスターの日

applitools.com

Back on September 9, 1947, Grace Hopper, a Harvard computer scientist, was running tests on a calculator and found calculation errors. She did some investigation and found a moth that had landed between two solenoid contacts, shorting out an electromechanical relay. Apparently, the bug had been attracted by the warmth of the machine.

We now commemorate this occasion every September 9, Tester’s Day.


9月9日はテスターの日なんですって。今年のテスターの日は過ぎてしまったので、来年(だいぶ先だけど)テスターの日にあわせて、バグ供養的な Developer Meetup なんてどうでしょうか。

2018年はどのようなタイプのバグが検出されているのか(1)

このエントリーは こちらの記事Google 翻訳を使って雑に読んだときに、わたしが何を考えていたかのメモです。マニア向け!

applitools.com

Trippy Text Layout

  • ホテルの名前と口コミでの評価の表示が重なって、見えづらくなってしまう問題
  • ホテルの名前が長いときに問題を見つけることができる
  • 短いホテル名だと問題に気づけない
  • 仕様(ホテルの名前が長いときにどう表示するのか)が分からなかったので、アプリ TripAdvisor for iOS をインストールしてみた

f:id:miwa719:20180924085949p:plain

  • 長い名前のときは、三点リーダー(ellipsis)を表示するのね(仕様)
  • 現在は、長い名前でも重なってません
  • ホテルの名前が日本語でも大丈夫そう
  • よく見ると、三点リーダーの表示位置が英語と日本語で違うんだね。日本語は Midline horizontal ellipsis (⋯) になってる
  • 1つ目の単語がものすごく長くて入りきらないときは、どうなるんだろう(三点リーダーのみ表示するのかな?)
  • うちの製品も多国語対応してるけど、言語によって(当たり前だけど)単語の文字数はだいぶ異なる
  • 日本語や英語ではいい感じに表示できてるけど、ドイツ語だとラベルに入りきらないとかね
  • ラベルに入りきらない場合に、何でも省略すればよいかというと、そうでもない
  • 例えば、ラベルに入りきらない「患者さんの名前」を省略してもよいだろうか
  • 「ホテルの名前」だったら、省略してもよい?
  • 旅行先の都市周辺のエリア情報(観光スポット、レストラン、ホテルなど)をざっくり知りたいときと、宿泊先を予約するときでは、名前に求める厳密さが異なるかもしれない
  • 同じホテル名(省略されている後方部分だけが異なる)が並んでいたとしたら、お客様はどのようにして目的のホテルを見つけるのか(いちいち詳細を見るボタンを押して確認する?)

f:id:miwa719:20180924090109p:plain

  • 実は1枚目のスクリーンショットは、たまたまホテルの名前しか出てないけど「エリア検索」の検索結果
  • 2枚目のスクリーンショットは「宿泊先検索」の検索結果
  • 「宿泊先検索」の検索結果:ホテル名には、三点リーダーを使っていない(良いですね)
  • その情報を「お客様はどのようなシーンで、何のために使うのか」を、自分の頭で考える癖をつける(それが仕様であっても)
  • なぜそれで良いと思ったのかを、自分の言葉で説明できると良い(もし、それが間違いだったときに「なぜ」の部分から、誤り訂正できるから)
  • 同じような検索結果(今回の例だと、エリア検索と宿泊先検索)で、表記方法を微妙に変えるのは、問題が入りやすいのかもしれない(そういう仕様が悪い、ということではない)
  • この先「エリア検索」に変更が入った場合、もしわたしがこのアプリのテスターなら、変更していない「宿泊先検索」の検索結果も確認すると思う

 

テスターのあたまの中(サマータイム開始日と終了日)

 

サマータイムが話題ですね。システムやソフトウェアに手を入れなければならないようなサマータイム導入には反対ですが、サマータイムをお題に「起きたら嫌なこと」や「気にしたいこと」を想像するのは面白い。思いついたことをメモしていこうと思います。*1

この記事は

  • きれいにまとめるつもりはないので、粒度はバラバラです
  • 重複しても気にしないことにします(無理に1つにまとめると隠れて見えなくなってしまうものがある)
  • わざと言葉を曖昧、省略してるものがあります(ここからさらに想像を膨らませたい)
  • 不定期に更新します
  • こちらのBCN+Rさんの記事が、とても分かりやすかったので、これをお題にしました。図もモディファイさせていただきました(気にしたい時刻、時間帯を、赤い線や丸印でマークしました)

www.bcnretail.com

サマータイム開始日の午前2時、3時台はスキップされる

f:id:miwa719:20180815092931p:plain

  • バッチ処理が実行されない
  • 予約処理が実行されない
  • 1日=24時間を意識した処理がおかしくなる
  • 経過時間を意識した処理がおかしくなる
  • この日、週、月、四半期、年などの統計値がおかしくなる
  • 歯抜けの日時はおかしくないのに異常だと判断される
  • 実行すべきでないバッチ処理が実行される
  • 実行すべきでない予約処理が実行される
  • 実行すべきでないタイムアウト処理が実行される

サマータイム終了日は午前2時、3時台が2回訪れる

f:id:miwa719:20180815165713p:plain

  • 実行すべきでないバッチ処理が実行される(2回目)
  • 実行すべきでない予約処理が実行される(2回目)
  • 実行すべきでないタイムアウト処理が実行される
  • 順番に並べることができない
  • タイムアウト処理が実行されない
  • 重複したデータが作成される
  • データが上書きされる
  • データが存在することを前提に動いている処理がエラーになる(例えば、1回目でデータ削除、2回目で削除するデータは存在しない)
  • 1日=24時間を意識した処理がおかしくなる
  • 経過時間を意識した処理がおかしくなる
  • この日、週、月、四半期、年などの統計値がおかしくなる
  • 重複した日時はおかしくないのに異常だと判断される
  • 実行すべきでないバッチ処理が実行される(2回目)のは、実は正しかった(仕様が間違っていた)
  • 実行すべきでない予約処理が実行される(2回目)のは、実は正しかった(仕様が間違っていた)

その他

  • ファイルやデータの作成日時、更新日時、削除日時を意識した処理はないか
  • 日時を元に計算してるものはないか
  • 時間、または単一時間内を何かでカウントしているものはないか
  • 表示用の日時を誤って計算用に使ってしまう
  • 内部処理用の日時を誤って表示用に使ってしまう
  • 表示用の日時と内部処理用の日時の変数名が似ているかもしれない(ミスしても気づきにくい)
  • お客様に直接関わる機能のサマータイム対応は万全だったが、メンテナンス用のツールやサービスツールが対応できていない(サマータイムに対応したことで、これまであまり使われることがなかったツールを使う羽目になることを予想)
  • インストール時に使用期限を設定しているものはないだろうか
  • お客様の環境で、これまで一度も通ったことのない「エラー処理」が初めて実行される(例えば、日時データがおかしいことが原因で)
  • お客様が使わないデータ(例えば、アクセスログ、操作ログ、エラーログ)がサマータイムに対応してなかった(不具合の解析などで困る)
  • サマータイム用のロジックが、サマータイムではない日、月、年に実行されてしまう
  • オンラインヘルプ、取扱説明書などへの記載(サマータイム対応)を忘れる
  • 自システム(サマータイム未対応)では問題が露見しないが、接続している他システム(サマータイム対応)では日時エラーになり、結局やりたいことができない
  • サマータイム対応前に登録したデータが、正しく処理できない
  • 接続している他システムがサマータイムに対応してるとは限らない(おかしな日時データが指定されても、システムが耐えられるか)
  • 接続している他システムがサマータイムに対応してるとしても、自分たちが想定してる日時データを指定してくるとは限らない
  • サマータイムに対応するために、データフォーマット、データベース、ファイル構造が変わるものがあるかもしれない
  • データサイズが変わったことで、受け渡しに使うデータ群の1番最後の項目が正しく処理されないかもしれない(1番最後の項目が、今回追加した日時データでない場合は、注目されにくいかもしれない)
  • サマータイムは馴染みがないため、正解を想像するのが難しい(不具合かどうかがわかりづらい)
  • その仕様は本当に正しいのか、お客様のやりたいことができるようになっているだろうか 

*1:わたしはテスターとして組み込み系製品の開発に従事しています。

サディスティックミワテスト

はじまりはこのツイート

で、こうなって

技術顧問にロゴを発注して*1

f:id:miwa719:20180812141607j:plainf:id:miwa719:20180812141558j:plain

Tシャツを作ってもらいました

suzuri製です。Tシャツをクリックしてみてね。 

suzuri.jp

うれしい。ありがとうございます!

追記(2018.08.25) 

druby.booth.pm

druby.booth.pm

 

*1:"Sadistic Miwa Test" → サディステックミワテスト → サディステック・ミカ・バンド → おお、懐かしい → 1970年代 → サイケデリックな感じで、とお願いした。

ベテランプログラマーとバグの調査をしたときのこと


これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作(入力)が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2 

プログラマーに状況を説明する

おかしな状態になる前に、どんな操作(入力)をしていたのか。たまたま、関係しそうな画面を4枚ほどキャプチャーしていたので、それを1枚ずつ見せながら、Sさんに説明しました。

miwa「次にこの画面ですけど、Aの値は、デフォルトの値が XX だったんですが、YY に変更しました。で、Bの値は、Aを変えたことで自動的に ZZ になったので、それを 1.4 に変更して、、
Sさん「うわあああ、ここに 1.4(小数点の値)を入れたんですね
miwa「入れました。小数点の値、嫌なんですか?
Sさん「嫌かも、というか、小数点の値はあまり試してません…


その後も

「きゃーーー、やめてーーー
「こわい、こわい、こわい
「これは、何が起きるかわからない


Sさんのリアクションは、控え目に言って最高
でした。こういうのって(テスターにとって)ものすごく有難いんですよ。

  • プログラマーが「やって欲しくないこと、嫌なこと」を知ることができる
    わたしの脳内:ここは大したことしてないと思っていたんだけど、内部の処理は、想像以上に複雑なのかも。もしかしたら、Sさんもまだ不安なところがあるのかもしれないな。もう少し時間をとって、テストしたほうが良さそう。
  • プログラマーが「まだ試してないこと、試しづらいこと」を知ることができる
    こんなことを聞いたら(テスターだったら)とりあえず、すべての入力項目に、小数点の値を入れてみようと思いますよね。それから 1.4 以外の値は大丈夫なのか、数値を丸めているのだとしたら、どのような丸め処理をしているのか、有効桁数はいくつなのか、いろいろ気になってきます。

このような情報は、当然、設計ドキュメントには載ってない。だから大変貴重です。*3

どの操作が引き金になっているのかを探る

わたしがやったことを一通り話した後に、どの操作が引き金になっているのかを探りました。*4いま思うと、もうこの時点で「この現象が起きるのなら、どの操作(入力)が関係しているのか」が、Sさんにはある程度わかっていたんだと思います。話を聞きながら、Sさんの頭の中には、プログラム(コード)が浮かんでいたのでしょうね。


今度はSさんの話を聞きながら、わたしが手を動かします。ペアテストに似ていますね。

「まず、ここは関係ないはずなので、ここの設定は全部オフにしてみましょう
(カチャカチャ、ターン)
「はい、再現しますね(想定どおり)
「では、ここも関係ないと思うので、ここもオフにしましょう
(カチャカチャ、ターン)
「はい、再現しますね(想定どおり)
「この現象が出るのは、◉◉の値がおかしくなっている、ということなんです
「◉◉の値は、AとB、あとCの値が関係してるんですよ
「ということで、AとBとCの値を変えてやってみましょう
(カチャカチャ、カチャカチャ、ターン)
「再現しなくなりましたね。ということは…


すこしずつ条件を変えながら「これだ!」という操作(入力)に迫っていきます。いくつかのパターンを試しました。引き金になる操作を特定したのは、それから10分後くらい。やっぱり早いわー。

今回のケースは、入力値だけでなく、操作順も関係していたので、再現手順を見つけるのが大変なバグでした。同じ値を設定しているのに、再現するときと、再現しないときがあるのです。こういうのは難しいですね。Sさんのナビゲーションがなければ、1時間かけても、たどり着かないかも…。*5

「実は、AとBに値を入れた後に、ある計算をしていて、ほら画面にも計算結果を表示してますけど、これ以外にもいろいろ計算してるんですよ。表には見えないんですけどね。裏でものすごい計算が走ってる。特にBね。だから、Bに値を入れた直後に、おかしなことになっているのかもしれないな。


わたしの脳内に「Bはヤバい、Bに注意」が刻まれました。こういう情報も、テスターにとっては貴重です。

Sさんの予想どおり、Bにある値を入れた直後に処理を実行すると、再現しました。Bにある値を入れた後に、違う項目(例えば C)に値を入れてから処理を実行すると、再現しませんでした。

こんなのを目の前で見せられると、プログラマーすごいなあ、これは真似できない、と思いますね。鮮やかでした。素晴らしかった!

ベテランプログラマーに共通する、ある行動

確信はないのだけど、前々から(もしかしてそうなのかな?)と思っていることがあります。それは「ベテランプログラマーほど、不安なところを包み隠さず、丁寧に教えてくれる」(傾向がある)ということなんですけど、今回のことで、うちのチームだけではなく、隣のチームでも観測することができたので(やはり、そうなのかもしれない)と思っている、今日この頃です。*6

おまけ

今回の「再現手順を見つけるのが大変なバグ」を説明するのに、簡単な画面を作りました。でも、文章で伝わりそうだから、いらなかったですね。せっかく作ったので、貼っておきます。(ラベルの枠のコーナーを丸くするやり方を覚えました!)

f:id:miwa719:20180805204133j:plain

プログラマーとお仕事をするということ

プログラマーとお仕事をするということ

 

*1:Region of Interest:操作の対象として選ぶ領域(関心領域)のことで、画像処理などで使われる用語です。

*2:ここのところ、隣のチームで絶賛開発中の「ある機能」をテストしている。

*3:この情報は、同僚のテスターや、隣のチームのテスターにも伝えます。

*4:Sさんがいちいち悲鳴をあげるので、観客が2名もついた。

*5:まあ、その前にうちのチームの誰かが、わたしの異変に気がついて、1時間もやらせてもらえないと思うけど。

*6:観測範囲がものすごく狭いので、気のせいかもしれません。書籍『プログラマーとお仕事をするということ』にも、そんなことは書いてなかった。