CAT GETTING OUT OF A BAG

What the tester is thinking.

ベテランプログラマーKさんの弱点

隣のチームのベテランプログラマーKさんが担当したものを(自主的に)テストすることがあるんだけど、バグが出ない。これまでにわたしが見つけたのは1つだけ。「◯◯の隙間を突かれましたねー」と、笑いながら言われたので、そのときの風景も含めて覚えているのだけど、その1つだけ。

隣のチームで開発してる部分の理解が圧倒的に足りない(=効果的なテストができない)のもあるけど、ある程度わかったとしても、簡単には出せない感じがする。

…とは言っても、Kさんも人間なのでミスはする。わたしが観測した範囲だと、Kさん自身がミスに気づいて直すパターンが多い。それも、外側から動かして見つけたというよりは、内側から(理詰めで)見つけてきたような、うまく表現できないけど、そう簡単に見つかるようなバグではない感じ。こういう凄腕プログラマーもいるのだなあ、と常々思っている。

そんなことをプロの無職 @m_seki に話したら(頼んでないのに)Kさんに話したらしく、Kさんの弱点を聞いてきてくれた。ありがとうございます。

「作ったところに関してはあまりバグは出ないんだけど、たまに要件ごとごっそり抜けることがあります」


それ以来、チケットに書いてないこと(隠れた要件や機能など)も気にして触ってるのだけど、バグを見つけたことはまだありません。

テストのさじ加減


はじめに

テスターが「仕様書」や「見た目の出来栄え」だけでなく「設計の良し悪し」を感じ、それをテストに活かすことができたら良いんじゃないかな、という話です。テスター向けに書いたのだけど、プログラマーのみなさんは、どんなときに「設計の良し悪し」を感じるのか、教えてもらいたい気持ちがあります。

「設計の良し悪し」とは

書籍『達人プログラマー』第2章(達人のアプローチ)「8 直交性」より

直交性とは、簡単に設計、製造、テスト、拡張できるシステムを構築する場合に必要となる重要な概念です。

(中略)

この用語はコンピューティングの分野では、ある種の独立性、あるいは分離性を表しています。2つ以上のものごとで、片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶわけです。

本項では「直交していないシステムの変更や制御の難しさ」「良いとされる設計」「直交することの利点」などについて書かれています。はじめに貼り付けたツイートのような「再現手順が思いつかないような現象を見たときでも、プログラマーが問題箇所に当たりがつけられる状況」というのは、ここで良いとされている設計 *1 になっている(またはそれに近い)のではないでしょうか。

多くのテスターがそうであるように、わたしも普段はソースコードを読まないので、本当のところは分からないのですが、開発中に起きる様々なことから「設計の良し悪し」 を感じ、テストのさじ加減(テストを行う際の配慮や手加減のこと。一通り触ってみたけど、もうすこしテストしたほうがいいな、というようなテストの微調整)を決めるための「材料」にしているように思います。

「設計の良し悪し」を感じるとき

わたしが「設計の良し悪し」を感じるときをメモしておきます。悪いシグナルを書いたので、反対にすると良いシグナルとして読めるものもあります。

なお、うちのチームは世界的に『外れ値』として扱われてしまうことが多いので、これまで所属してきた複数のチームを思い浮かべて、観測できそうなものを書いてみました。*2

1. チケットの滞空時間が長い

手をつけてからコミットするまでに日数がかかっているチケット。進んでいるように見えるが、なかなかコミットできない。設計が複雑で難しいのかもしれない。*3

ただ、これは他にも問題(もっと深刻な開発全体に関わるようなもの)が起きていることもあるので、単に経過日数だけに注目すると間違えます。(例:開発が順調に進んでいるように見せる必要があり、ひとりのプログラマーが複数のチケットを同時にオープンしている)

また、チームによっては、滞空時間が長いのは良い傾向(サクッと進んでしまうときほど危うい)の場合もあるようです。

2. なかなか手をつけないチケット

設計が複雑で難しく(やりたくないので)なんとなく後回しにしてしまうのかもしれない。

これもさっきと同じで、経過日数だけ見てると間違えます。(例:バグが出すぎていて取りかかれない、手をつけているチケットで難しい問題が発生している、緊急度/重要度が他のチケットより低い)

3.「再現手順が分からないと分からない」と言われる

現象から当たりをつけられないくらい、これに取りかかったら、しばらく他のことができなくなるくらい、設計が複雑で難しいのかもしれない。

各種ログからも追いづらい、調査しづらい厄介な問題であることが多く、簡単には再現しない。再現手順が分からないと、直ったかどうかも確認できないので、わたしも再現手順を見つけたい。*4

4. 変更内容をコードの断片だけで説明する

変更前にそう書かれていた意図、それをどのように変更したのか、それで良いと思ったのはなぜか(根拠)を言葉で説明できないくらい、設計が複雑で難しいのかもしれない。

5. 変更したら別の機能が壊れた

変更したことによる影響が分からないくらい、設計が複雑で難しいのかもしれない。*5 

6. 変更したファイルがやけに多い

一昨日、うちのチームのプログラマー @vistige_ から「コミットログを見ると、いろいろ分かって面白いですよ〜」と教えてもらったので、しばらく毎日観察してみようと思っています。ファイル名からどの辺を変更したか、だいたい分かると言っていたので、これは予想ですが、自分ではちょっとした修正だと思っていたのに、変更したファイルがやけに多いなとか、いつもとは違うあまり見たことのないファイルが変更されてる…を感じることができるなら、テストのさじ加減も変わりそうです。*6

 

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

 

*1:YourdonとConstantine が「凝集度」と呼んでいるもの

*2:プログラマーが常に良いコードを書きたいと願い、実際そういうコードを書こうとしてるのは、見て知っています。わたしが対象にしてるのは製品(ソフトウェア)なので、プログラマーを責める気持ちはありません。どうか怖がりませんように…!!

*3:うちのチームでは「仕切り直し」というキーワードが使われるので分かりやすい。最近、特に注目しているのは「鋭意作成中」とチケットに書いてくるプログラマーがいるので、注意深く観察しているところです。「作成中」なのは知っているので「作成中」と書いてくる時点で気になるけど、さらに「鋭意」を入れてきた理由があるはずだと思うから。

*4:この手の問題は1つ直っても、他に問題が潜んでいることも少なくないので、修正後の確認はかなり時間をかけて行います。問題の周辺をよく見る。

*5:どこを直したらどこが壊れた、という事実は、テスターが内部設計を予測するのを助けます。

*6:ある部分は機械化できそうな気もする。

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

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

applitools.com

No Order for You

  • Amazon’s mobile app
  • 注文数量を1以外に変更しようとすると、数量選択ポップアップが画面の外に表示されてしまう問題
  • "Off-screen quantity popup on Amazon App stopping the buy prosess"
  • 英語圏の事例だけど、国内でこの問題が起きたとすると
    • アマゾン日本事業の2017年売上高は1兆3335億円(1日36億5000万円)
    • 売上の全てが Amazon’s mobile app 経由ではないと思うけど、仮にそうだとして単純に24時間で割ると1時間で1億5000万円の売上
    • 1時間注文できないと1億5000万円の損失
  • すごいな

netshop.impress.co.jp

 

問題のアプリを見てみよう

  • 欲しいものリストから3つの商品をカートに入れます
  • カートをタップします

f:id:miwa719:20180930145030p:plain

  • 数量を変更します

f:id:miwa719:20180930145038p:plain

  • 数量選択ポップアップ、画面の真ん中に表示されてる
  • 大丈夫でした(Amazon Mobile LLC for iOS / Version 11.18.0)

問題を見つけました

  • 数量を変更しようとしても、画面が暗くなるだけでポップアップが出てこない(ときがある)
  • 見えないところにポップアップが表示されてるのかな
  • 元の記事の問題と似てる?

f:id:miwa719:20180930150515p:plain

  • わりと再現する
  • カートの中身を表示して、画面左上の戻る(<)をタップしてから、再度カートの中身を表示して数量変更しようとすると、再現することが多い気がする
  • この操作を何回か繰り返してたんだけど、それが嫌なのかな
  • 誰か追試してみてー *1
  • これ、ポップアップが出てくるときもあるので、全く注文できない状態にはならないけど、このような不安定な動作は、お客様を不安にさせるよね
  • わたしも不安だわ(Amazon’s mobile app のテスターになったつもりで触っている)
  • ところで、なんでこれポップアップにしたんだろう(開発者に聞いてみたい)

ポップアップの仕組みが分からないので似たような画面を作ってみた

  • 2種類の方法でポップアップ(alert)を出してみた
  • WKWebViewでJavaScriptを呼び出す方は、まだよく分かってない(時間切れでやめた)
  • モバイルアプリ開発、こうやって自宅で試せるのが、とてもいいなあ *2

 

*1:動作環境は iPhone 6s Plus / iOS 12.0、Amazon Mobile LLC / Version 11.18.0 です

*2:わたしは組み込み系製品の開発経験しかないので、とても興味があります

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