CAT GETTING OUT OF A BAG

What the tester is thinking.

自分のiPhoneの電話番号が覚えられなくてカッとなってApple Watchアプリを作りました

テスト中にいきなりアプリがクラッシュしても、直前に操作していた内容や手順を11個くらいまで遡ることができるのに、自分のiPhoneの電話番号(11桁)を覚えることができません。

自分のiPhoneに電話をかける状況になったことはないのですが、飲食店などに電話をして予約する際に「では、ご連絡先をお願いします」と言われる時があって困っていました。

毎回こんな感じで対処しています

  1. そばに誰かいる時は「私の電話番号を電話帳から探して表示してお願い!」と頼む
  2. お店の方に「あの……もしかしてナンバーディスプレイとかで表示されてないでしょうか…?」と聞く
  3. もうどうしようもないときは自宅の固定電話の番号を伝える*1(そのあと家に電話して事情を話す)
  4. 「折り返しこちらからご連絡しますのでー」と言われたときは最悪で 3. の方法も使えないので、事情を話し一旦電話を切りどこかにメモしてからもう一度電話する


先日、娘(大学院生)がその犠牲者(1.の方法を使った)になりました。電話を切ったあと娘から『通話中でも電話帳から自分の電話番号を表示して相手に伝える方法』を教えてもらいました。教えてもらったというか強制的に教えられたのですが、手順が難しくてスマートにできそうもありません。(間違って電話を切ってしまうんじゃないかと不安になる)*2

自分のiPhoneの電話番号を表示してくれるApple Watchアプリを作りました

Apple Watchのホーム画面からアイコンをタップすると自分のiPhoneの電話番号を表示してくれるアプリです。それだけです。せめて自分の電話番号くらいはAPIから取得するかーと思ったのですが、調べたら難しそうなので諦めてハードコード(Labelに直書き)しました。1行もコード書いてない。

stackoverflow.com

Apple Watchのホーム画面からアイコンをタップします。

f:id:miwa719:20181230151750j:plain

自分のiPhoneの電話番号が表示されます。これでもう安心だ。

f:id:miwa719:20181230163251p:plain

アイコンはフリー画像から見つけました。電話といえばこれだなと思って。画像からアイコンにするのはいつもここで作ってます。画像を指定すると iOSiPhoneiPadApple Watch)とAndroid用のアイコンを作ってくれます。とても便利です。

f:id:miwa719:20181230171659p:plain

makeappicon.com

 

開発環境

  • Xcode 10.1(Swift 4.2)
  • iOS 12.1(まだ 12.1.2 にアップデートしてない)
  • watchOS 5.1.2

*1:自宅の電話番号は40年くらい同じだし何度もダイアルを回してかけていたので暗記している

*2:テストでは11個くらい手順を覚えられるのにな

違和感のつかまえかた

ソフトウェアテスト #2 Advent Calendar 2018 - Qiita 24日目の記事です。

qiita.com

はじめに

医用機器(自社製品)のソフトウェア開発に従事して、あと数年で30年になります。うち15年くらいはプログラマー、現在はテスターとして日々奮闘中です。

私は開発現場で感じるちょっとした『違和感』を大切にしています。風邪のひきはじめに「なんとなくだるい」「鼻がツンとする」「喉が痛い」「寒気がする」というような違和感を感じた時、症状がひどくならないよう行動を変えるのではないでしょうか。それと同じようにソフトウェア開発の現場で感じる違和感も『注目すべきシグナル』と捉え、活動のきっかけにしています。

この記事では

  • 何を見て違和感をつかまえているのか
  • 違和感をつかまえやすくする工夫
  • 違和感をつかまえたあとのこと
  • 違和感をつかまえるために知っておくと良いこと

について記載します。どれも私の経験に基づいたものであり、思考法や認知心理学のような専門的な話は一切ありません。気楽に読んでいただけたらと思います。そうそう、風邪をひかないように前もって何かをすることも大切ですが「予防」のような話もありません。いくら気をつけていても風邪をひいてしまうことはあるよね、という前提です。

本題に入る前に

ところで「違和感を感じる」という表現は、日本語としてどうなのでしょうか。この記事を書くにあたり、はじめに違和感を感じたのはそこでした。せっかく『違和感』について書くのだから、違和感なく読める文章を書いてみたいと思ったのです。「頭痛が痛い」のような表現は明らかにおかしい感じがしますよね。そこで『重言(二重表現)』を調べてみたのですが、いろんなご意見があるようです。この記事の中での「違和感を感じる」は「重言(二重表現)ではない」ことにして書き進めたいと思います。自分なりの解釈は脚注 *1 にメモしました。

何を見て違和感をつかまえているのか

私が何を見て違和感をつかまえているのか(その兆しも含めて)一部を列挙します。どれもチームや製品に対して解決すべき課題や問題が見つかったものです。皆さんは普段どのような周波数で違和感をつかまえていますか?

朝会やディスカッションの場で

  • 同僚の様子(顔色、声のトーン)がいつもと比べてどうなのか
  • 話している内容がわかりづらい
  • 聞いたことに対しての答えが直球で返ってこない
  • 「仕様なんで」
  • 「ずっと前からそういう動きになっています」
  • 「今回のは大したことない変更なんで」
  • 誰かの作業を待っている
  • 自分に関係ありそうなことなのに黙って聞いている
  • 「全部やりました」
  • 正しそうなことを言っている

チケットを見る

  • 書いてある内容がわかりづらい
  • 文章が長すぎる
  • 変更内容にプログラムの断片やコミットしたファイル名しか書いてない
  • 一見すると文章だがよく見るとプログラムを日本語にしただけ
  • 作業中(実装中)とだけ書いてある
  • 仕切り直しが多い
  • ずっと調査している
  • なかなか手をつけない(後回しにされる)チケット
  • 作るものに対してテストケースが少なすぎる/多すぎる
  • うまくいきすぎている

コミットログを見る

  • 変更した内容に対して変更したファイルが多すぎる
  • 1日に同じファイルを何回もコミットしている
  • 金曜日の朝の時点では苦戦していたはずなのに帰る間際にコミットしてる

製品を見る

  • 昨日と比べてどうなのか
  • 操作を間違えてしまう(スムーズに操作できない)
  • 速すぎる
  • もっさりしている
  • 一瞬だけど応答が遅くなった
  • 一瞬だけど表示がチカッとした
  • うるさい
  • 疲れる
  • 揃いすぎている数値(719.000 のような数値)
  • ディスクアクセスランプがやけにチカチカしている

自分自身を見る

  • 時間を忘れてテストしている(ものすごく楽しい)
  • 後回しにしたことがある
  • 焦っている
  • 退屈、つまらない
  • 眠い
  • いらっとした
  • スッとした

違和感をつかまえやすくする工夫

この記事の執筆中に 秋山浩一さん @akiyama924 と何度かメッセージをやりとりしました。*2
その中で

  • 違和感をつかまえやすくする工夫
  • 違和感に対する感性を高める工夫

があるのではないか、という話しになりました。狙いを定めて何かを仕込んだり試したりするのはこの記事の範疇ではないのですが、狙ってないけどいつも無意識にやってることがきっかけで違和感をつかまえられているとしたら、それが『工夫』なのかもしれない。

いつもならこんなことはしないけど(だって無意識にやっていることだから)ほぼ日手帳に『狙ってないけどいつも無意識にやってること』を書き出してみました。書き始めてから数分で1枚に書ききれなくなってしまい(なにかおかしいかも…)と違和感を感じ、書くのをやめて秋山さんにメッセージを送りました。

f:id:miwa719:20181214124015j:plain  

f:id:miwa719:20181217230204p:plain

『狙ってないけどいつも無意識にやってること』を(なぜ、それをやったのだろう?)と見つめ直してみると、その根底には(こんなことが起きたら嫌だな)という思いがあります。その思いは「過去に見た問題や不具合や自分の失敗」からくるものが多いのですが、中には説明がつかないものもあり、それはどこから舞い降りてくるのか自分でもわかっていません。

今回は『狙ってないけどいつも無意識にやってること』『無意識に思っていること』を抜粋して載せます。なぜそれをやるのか(何を心配しているのか)はあえて書かないでおきます。 *3 なぜなら、私はこのような断片から想像することが好きだからです。突拍子もないことを思いついてしまったり、意識化できていないこと(暗黙知)を引き出せるような面白さがあります。

なぜこんなことをするのだろう
過去にどのような問題があったのだろう
うちの製品に対してこれをやるとしたらどんな問題が見つかるかな
《テストしてみる 》
そういえば、全然関係ないけどずっと前にこんなことがあったよね
あれはどうかな

《テストしてみる 》
うわあああ、ちょっと何やってるんですか!!(プログラマーの悲鳴)

もう一つの『違和感に対する感性を高める工夫』については、いつか別の記事で書きたいと思っています。

狙ってないけどいつも無意識にやってること、思っていること

  • 遅いPCで動かす(低スペックのもの)
  • いつもと違う順番で起動する
  • 起動直後は特別な状態である
  • 何日間も電源を落とさないで動かす
  • PCのシステム日時を23時55分に変更していつもと同じように動かす
  • たくさんデータを登録した状態で動かす
  • ひとつもデータがない状態で動かす
  • 古い装置で生成したデータを使う
  • 新しい装置で生成したデータを使う
  • いつも使っているデータを使う
  • いつも使っていないデータを使う
  • 壊れたデータを使う
  • 壊れたメディアを使う
  • 設定ファイルがいつも読めるとは限らない
  • タスクマネージャでリソース状況を見ながら動かす
  • モニタの電源をOFF→ONする
  • 他のダイアログ(メモ帳など)をかぶせて動かす
  • 放置する
  • ダイアログボックスで「どうする?」と聞かれてもすぐには選ばない
  • テキストボックスで(やってることがありすぎるので省略)
  • ラジオボタンはどうにかして2つ以上選ぼうとする
  • ドロップダウンリストは下から選ぶ
  • 常に何もないところをクリックしている
  • ゆっくり操作する
  • 素早く操作する
  • 何度何度も繰り返す
  • 両手を使う
  • 手と足を同時に使う
  • 「しばらくお待ちください」と言われても大人しくお待ちしない
  • 制限を突破しようとする
  • 接続しているものを外す
  • OSで定義されているショートカットキーを押す
  • 雷が鳴っている時は瞬電を期待している(瞬電が嫌そうな機能を触る)
  • エラーが起きた時さらに別のエラーを起こそうとする
  • ログファイルを見る
  • ログファイルを全部削除してから動かす

この記事を同僚(テスター、プログラマー)が読んだら(ああ miwa がいつもやってるわ)と思うのではないでしょうか。テストはこれとは別にやるので、ここに挙げたのは『工夫』というよりは『習慣』に近いかもしれません。

違和感をつかまえたあとのこと

せっかく違和感をつかまえたのに(そういうものなのかもしれない)と勝手に納得して無かったことにしてしまったり、気にはなるけど明らかな問題(バグ)でもないしなぁと、何となくそのままにしてしまうことってありませんか?

違和感の中には「気にしすぎ」も当然ありますし、今の製品には「マッチしていない」場合もありますね。他の人も同じように違和感を感じているけど大人の事情で「今はそういう実装」になっているものもある。開発の終盤でこんなことを言ったら(いまそれ言う?)(いちいちうるさい人だな)と思われるかも…とかね。なんとなく表に出さないままにしてしまう状況は少なからずあると思います。

でも、あとから問題が発覚して(ああ、あの時の違和感がそうだったんだ、みんなに話しておけばよかった…)と思うんですよ。勿体無いよね。違和感に申し訳ない。だから言いづらいなと思う違和感ほど誰かに伝えるようにしています。杞憂であったとしてもそれはそれでいいのです。『これは仕事だから仕方ない』と思うと躊躇せずに言えるようになります。このフレーズはいろんな場面で使えるので便利です。違和感を自分ひとりのものにしておかないのがポイント。だいぶ気が楽になりますよ。

声に出す

違和感を感じた瞬間に首を傾げたり、小さな声で「ん?」「あれ?」「いまのなんか変だったよね?」と声に出します。これをやると何も言わないときと比べて『違和感を無かったもの』にしづらくなるのがよいです。私の異変に気がついた同僚が「なになに?」と興味を持ってくれることもあります。

観察する

違和感の正体を明らかにするために、どこに違和感を感じたのか、なぜおかしいと思ったのかを考えたり調べます。観察した結果をほぼ日手帳にメモするときもあります。小さな違和感ほど時間の経過に伴ってその感触が薄れてしまうので、違和感を感じた瞬間に(いまのあれはなんだ?)を考えるようにしています。

そういえば、この記事を書きはじめたときに「違和感を感じる」に違和感を感じたのですが、なぜそう感じたのかを考えたり調べました。これと同じですね。

同僚に話す

観察した内容をチケットに書いたり、朝会や朝会の二次会で話題にすることもあるのですが、それよりも先に同僚に話すことが多いです。同僚はどう思うのか、同じように違和感を感じるのかどうなのか。違和感の正体がわからなくてもよいので話します。

もしあなたのチームや組織だと(個人で感じる違和感レベルのことは)そこまで真面目に受け取ってもらえる風土がないと思うのでしたら、まずは違和感を交換しあえる同僚を一人作ってみてはどうでしょうか。二人で感じる違和感なら話しやすいよね。*4

違和感をつかまえるために知っておくと良いこと

いつもの状態を知る

『何を見て違和感をつかまえているか』にも書きましたが「いつもと比べてどうなのか」「昨日と比べてどうなのか」から違和感を感じているということは「いつもの状態を知っている」「昨日の状態を知っている」ということになります。いつもとの差分=違和感となるのでしょうね。風邪のひきはじめも同じで「いつもの自分の状態」を知っているから感じることができます。製品やチームもこれと同じですね。当たり前だけど重要なことだと思います。

練習ではなく実戦で

私は中学高校と6年間卓球部に所属していたのですが(女子シングルスで県チャンピオンになるくらいの腕前だったのでまあまあ上手なほうだと思います)

  • 練習すれば獲得できる技術
  • 実戦(試合)を重ねることでしか獲得できない技術

があります。後者は相手の動きと打ち返されたボールを見た瞬間に様々なことを判断して反撃するようなテクニックが必要になってくるのですが、違和感をつかまえることもこれに似ています。ソフトウェア開発の現場でより多くの違和感をつかまえられるようになりたいと思うのなら、練習ではなく実戦(本物)でやることを強くおすすめします。瞬発力を鍛えよう!

疲れているときは違和感をつかまえられない

これは言葉のとおりです。違和感をつかまえられないというより、いつものパフォーマンスで仕事ができないのは困るので1時間に1回は休憩を取るように心がけています。たまに熱中し過ぎる時もありますが Apple Watch が異変を感知して「スタンド」を強要してくるので安心です。8時間も仕事したら疲れるので残業もほとんどしません。

おわりに

ソフトウェア開発の現場で感じる違和感をテーマに

  • 何を見て違和感をつかまえているのか
  • 違和感をつかまえやすくする工夫
  • 違和感をつかまえたあとのこと
  • 違和感をつかまえるために知っておくと良いこと

について記載しました。

いろんな周波数を使ってつかまえたちょっとした『違和感』を大切にしながら、今後もより良い製品を丁寧に作っていきたいと思います。

あわせて読みたい

speakerdeck.com

 

*1:『重言(二重表現)』の例としてよく挙げられる「馬から落馬する」などが「漢字」の重複を含むために「文字」の重複を二重表現だと誤解されることが多いが、二重表現とは「まだ未解決」「すべて一任」「あらかじめ予約」のように「意味」が重複する表現のこと。例えば「体操着」は「衣類の名称」であって着るという動作自体の「意味」は含まれない。そのため「体操着を着る」と言っても二重表現にはならない。「違和感」もこれと同様で「違和感」は「感じの名称」であり、感じるという動作の「意味」は含まれない。よって「違和感を感じる」は二重表現にはならない。「歌を歌う」「舞を舞う」なども同じ。どうしても気になる場合は「違和感がある」「違和感を覚える」「違和感を抱く」「違和感に気づく」のように違う言葉で置き換える方法もある。この記事の内容だと「違和感に気づく」でも良さそうではあるが、私の感覚だと「気づく」よりも早く訪れるのが「感じる」であり、別物である。今回は「感じる」ことに拘りたいので「違和感を感じる」を使用することにしました。

*2:今回のお題は Twitter経由で秋山さんからいただきました。どのようなことが知りたいのか興味があったのです。

*3:次回のとちぎテストの会議 #toteka で話してもいいけど、わかりづらいことを延々と聞かされる辛いセッションになります(私だけがものすごく楽しいやつです)

*4:チームや組織は概念で実体は自分です。風土は自分たちで作ろう!

明日から試せるテストに関するアドバイス

この記事は、テストに関するツイート(わたしの)の抜粋です。
那須の「あのチーム」の話を聞いたからと言って、すぐに真似することはできないかもしれないけど、これなら明日から試せそうじゃない?と思うものを、集めてみました。

1. 実装する前にやってみたい(やる)テストを宣言する

2. 同僚が見つけた良いバグを褒める

3. なぜそのテストをやってみたのかを話す/聞く

4. 昨日見つけたバグや気になることを交換する

5. 暴れる前にツイートする

6. プログラマーに自信のあるところ/ないところを聞く*1

7. 話しづらいことは話しづらいので話せるように練習する 

 

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

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

 

 

*1:ツイートで引用したのは、書籍『達人プログラマー』の一節。テスターにもおすすめの本です。7. の『割れ窓理論』も載っています。

ブログのサイドバーに本棚を置きました

自宅の本棚を新調したいな…と思っているのですが、どういう本棚にしようか探したり、悩んだり、採寸とかいろいろ面倒くさいので、とりあえずブログのサイドバーに本棚を置いてみました。だからと言って何も解決してないんですけど、ちょっと満足しました。 これをやるためにブクログでIDとって、とかは面倒くさくない。

ブクログのIDを miwa719 にしたかったのに既に使われていて(もしかして自分で取ったのかな?)と思ったけど調べられなかったので beautyandharmony にしました。名前が美和だから。  

beauty and harmony

beauty and harmony

Twitter などで言及したことのある書籍を中心に並べていこうと思います。 booklog.jp

コーヒーの香りを楽しむための Apple Watch アプリを作りました

普段、紅茶やルイボスティーを飲むことが多いのですが、猫廼舎さんコーヒー豆が通販で買えるようになったので、毎日1杯だけハンドドリップする時間を作りました。コーヒーを淹れるときの香りには、人間の脳に働きかける二つの効果(癒しと集中力)があるそうです。

20秒間、時計の秒針を見てるのが辛い

コーヒーを淹れるのは、頭の回転が鈍くなる午後2時から3時くらい。リフレッシュして(午後5時まで)あと1、2個のテーマでテストするぞーと思う時間帯です。

コーヒーを淹れるときの手順はこんな感じ。

  1. ペーパーフィルターをドリッパーにセットする
  2. ドリッパーにコーヒーの粉を入れる
  3. 粉の表面に20cc程度のお湯を注ぎ、20秒ほど蒸らす
  4. 中心部に「の」の字を描くように、お湯を数回に分けて注ぐ
  5. できあがり

この手順 3 のとき、ハンドドリップならではのふわっとした良い香りがするのですが、時計(Apple Watch)の秒針を20秒間見てなきゃならない。これが地味に辛い。

20秒たったらお知らせしてくれる Apple Watch アプリを作りました

コーヒーを淹れるときの手順はこんな感じになります。

  1. ペーパーフィルターをドリッパーにセットする
  2. ドリッパーにコーヒーの粉を入れる
  3. 粉の表面に20cc程度のお湯を注ぐ
  4. Apple Watdh アプリを起動する
  5. ボタンを押す
  6. 香りを楽しむ ← ここが重要
  7. お知らせ(チャイム音と手首トントン)がくる
  8. 中心部に「の」の字を描くように、お湯を数回に分けて注ぐ
  9. できあがり

手順が増えたけど(笑)蒸らし時間を気にしないでコーヒーの香りだけを楽しむことができます。

このアプリの特徴やこだわり

  • 20秒たったらお知らせすることに特化する
  • 視覚以外(聴覚と触覚)でお知らせする
  • 時間を設定することはできない(20秒固定)
  • アイコンでも20秒以外は対応しないという強い意志を示す
  • アイコンの背景色は「モカ」という色を使用(コーヒー豆を意識)

f:id:miwa719:20181111144340j:plain f:id:miwa719:20181111145742j:plain

  • 画面は見ないので凝ったデザインにしない 
  • 画面に Button とか Label という文字が表示されていても気にしない *1

f:id:miwa719:20181111145752j:plain f:id:miwa719:20181111150257j:plain f:id:miwa719:20181111145812j:plain

問題点:Apple Watch がスリープしてるとお知らせしてくれない

シミュレータでまあまあいい感じに動くようになったので、実機(Apple Watch)にインストールして動作確認をしていたら、20秒たってもお知らせ(チャイム音と手首トントン)してくれないときがあるんですよ。どうやら Apple Watch がスリープしてしまうと通知しないみたい(そうなるように実装しているんだろうけど…)。大問題ですね。アプリを動かしたら Apple Watch がスリープしないように目で監視しなきゃならないわ*2。これでは困ります。

解決方法

そもそもなんでスリープするのか調べていたら、Apple Watch の設定で「タップ時」というものがあるのですね。知らなかった。

f:id:miwa719:20181111162127j:plain

「15秒間スリープ解除」というのは「画面が表示されたままになる時間が15秒間」という意味で(分かりづらい)鋭い人はもう分かったと思うけど、この設定を変更しました。

f:id:miwa719:20181111162136j:plain

こうすればアプリ起動後、70秒間はスリープ状態に移行しないので問題解決です。(自分のためだけのアプリだから、これで良いことにする)

タップ時の設定をこれまでの15秒から70秒に変えたことで、バッテリーの持ち時間にすこし影響が出るかもしれませんね。Apple Watch がスリープ中でもアプリからお知らせする方法を調べるのは、必要に迫られたらやろう。

新しく覚えたこと

開発環境

その他

来月のとちぎRubyの勉強会 #toruby で Rubyist にコードレビューしてもらおうかな。Swift だけど。前にキッチンタイマー(言語はC#)を作ったとき、みんなにコードを見せたらでダメ出しされたので耐性はついてる。

f:id:miwa719:20181111153242p:plain

 

ドリッパーとペーパーフィルターは、こちらで購入したものを使っています。

item.rakuten.co.jp

item.rakuten.co.jp

猫廼舎さんはスイーツも美味しいです。お店に猫はいないけど、猫好きな店主がいます。コーヒー豆はこちらから購入できます。(スイーツと店主の @ogijun さんは通販してません)

cafenekonoya.shop

*1:これは自分に言い聞かせています。開発環境など諸々のアップデートをしながら、週末の二日間で動くものを作りたかったので。プロジェクト名も sec20 にしてあれこれ手を出さないように自分で自分をコントロールしたよ。名前重要!

*2:こんな運用回避は嫌だ

プログラミングの「アンチパターン」からテストを考える

はじめに

この記事は、技術系ブログや書籍などに書かれているプログラミングの「アンチパターン」を読んだとき、わたし(テスター)が、どのようなことを考えているのか紹介したものです。

もし「アンチパターン」で実装されていたら

わたしはよく「過去の不具合を使って(同じような)不具合が起きないかを確認する」ということをするのですが、この「過去の不具合」を「アンチパターン」に置き換えて、テスト対象のソフトウェアが、もし「アンチパターン」で実装されていたら

  • どのようなこと(ミス、不具合)が起きそうか
  • どのようなテストをやってみたいか

を考えます。この2つが対になるように考えてもいいし、テストが思いつかないときは「こんなことが起きそう」だけでもOKです。要はより多くの「起こりそうな嫌なこと」を描くトレーニングです。

題材さえあればいつでもどこでもできます。一人でもできますが、何人かで集まってやると自分では思いつかなかったこと(他人の思考)を、自分のものとして頭の中に取り込めるのでお得です。時間を制限してやると瞬発力がつきます。なお、わたしたちのチームは(特別に集まることはなく)普段からこのようなことを話しています。

 

今回は、伊藤 淳一さんの こちらの記事 を題材にしてやってみたいと思います。サンプルコードや解説がとても分かりやすい!テスターのみなさんにも、ぜひ読んでもらいたい記事です。

blog.jnito.com


なお、実際に開発してる製品を絡めた形では書けないので、架空のシステムを想定した、やんわりとした内容になっています。  

主要な変数が全部連番、かつあらゆる変数がグローバルなシステム

どのようなこと(ミス、不具合)が起きそうか

  • プログラマーが打ち間違いをしそう*1
  • コードを見ても間違っていることに気がつかない
  • 実装に時間がかかるので、十分なテストができないかもしれない
  • 指定するテーブルやカラムを間違うことで、お客さまがやりたいことと無関係なデータを表示、変更、削除してしまう
  • 仮にテスト対象が電子カルテシステムだった場合
    • 別の患者のカルテで治療計画を立ててしまう
    • 患者の体位と向きの表示を間違えたまま開腹手術してしまう
  • ループ用の変数もグローバル変数で宣言されているのか……
    • データは取得できても、中途半端に表示することがあるかもしれない
    • 件数は合っていても、前回のデータを残したまま表示することがあるかもしれない(初期化が中途半端)
  • 主要なテーブルやカラムについては目に触れることも多いし、みんなが気にして確認するけど、そうではないものは確認が手薄になりそう

どのようなテストをやってみたいか

  • この実装だと間違える要素がありすぎるので「間違っているものを探す」というよりは「正しいものを探す」という気持ちでテストしたい
  • 単にデータが取得できた、変更できた、削除できただけでなく、データの中身まで確認したい
  • 全テーブル、全カラム、全てだ!
  • テストデータは適当な文字列の羅列ではなく、テーブルごとに意味のある内容にしたい
  • テストデータを見ただけで「どのテーブルのどのカラムのデータ」が分かるものを用意したい(テスト結果を見たときに、指定先の間違いに気づきやすい)
  • 指定するインデックスも間違うかもしれない。応答速度(検索、ソートなど)も気にしたい
  • とすると、テストデータの量も調整しながらテストしたい
  • ループ用の変数もグローバル変数で宣言されているので「件数」を気にしたい

カンマ区切りで複数のコード値を格納しているテーブル

さっきのもすごいけど、これもすごいな(こういう実装を思いつくのがすごい)*2

どのようなこと(ミス、不具合)が起きそうか

  • マシンスペックが良すぎると、案外サクッと動いてしまうかもしれない
  • 性能問題に気づけないのが問題
  • 売上げテーブルの商品コードカラムに、商品マスタに存在しない商品コードが登録できてしまうかもしれない(外部キー制約をつけられそうにないから)
  • カンマ区切りで複数のコード値を格納しているテーブルは、この売上げテーブルだけではないかもしれない
  • データの整合性に関して何もかもが怪しく思えてくる

どのようなテストをやってみたいか

  • プログラマーの開発PCより遅いマシンスペックでテストする
  • システムで推奨してるマシンスペックより劣るもので動かすと、早いうちに問題に気づきやすい
  • たくさんの商品を1回で購入するような操作をしてみたい(売上げテーブルの商品コードカラムを溢れさせたい)
  • 商品を購入した後に、商品マスタのマスタデータを削除してみたい
  • 商品マスタの商品コード自体にカンマを入れてみたい
  • 商品名にもカンマを入れておきたい(ITEM_NAMEからコードを逆生成することがあるかもしれないので、念のため) 

おわりに

テストの定義はいろいろありますが、わたしが一番好きなのは、マイヤーズの「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」というものです。この「エラーを見つけるつもりで」という行為は、より具体的な「エラー」を頭の中で描けないと難しいと思っています。絵本『ウォーリーをさがせ!』を想像してみてください。ウォーリーを知らないと探すことはできませんよね。ウォーリーを見つけるための手がかり(どんな顔をしていて、黒縁メガネをかけていて、ひょろっと痩せていて、赤と白のしましまの長袖Tシャツを着ていて、赤いボンボンのついた帽子をかぶっていて…)を知っているから探せるのです。

今回この記事で紹介したのは、より多くの「起こりそうな嫌なこと」を描くためのトレーニングの一例になります。「起こりそうな嫌なこと」は「エラーを見つけるための手がかり」の1つです。いつでもどこでも「起こりそうな嫌なこと」を描いてしまう癖がつくと、思考のバリエーションがどんどん増えていき、ソフトウェア開発の各場面で活かせるのではないかと思っています。実際、わたしが普段やっている Testing はこういった癖(トレーニング)で習得した要素が含まれています。きっと明日のテストでは、入力項目に思わず「カンマ」を入れてしまうと思います。

 

ソフトウェア・テストの技法 第2版

ソフトウェア・テストの技法 第2版

  • 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
  • 出版社/メーカー: 近代科学社
  • 発売日: 2006/08/01
  • メディア: 単行本
  • 購入: 7人 クリック: 267回
  • この商品を含むブログ (47件) を見る
 
NEWウォーリーをさがせ!

NEWウォーリーをさがせ!

 

 伊藤 淳一さんのチェリー本も載せておきます

 

*1:そんなの当たり前!と思うことでも出します。それが本当に当たり前かどうかは分からないし(でも、だいたいは当たり前なんですけど)当たり前にやるだろう、と思っていたことがすっぽり抜けてしまった苦い経験があります。

*2:すごすぎて他の言葉が見つからないわ。テーブルやカラムを増やしてはいけないシステムだったのかな。

「バグの伝わり方」を知るということ

見た目は単純そうなバグでも、その生い立ちを知ると「バグの伝わり方」が見えてきて(面白いなー)と思うときがあります。

たとえば、アプリケーションの画面には、やりたいこと(処理)を実行するための「ボタン」があります。状況に応じて、ボタンを有効(enable)にしたり、無効(disable)にしたりするんですけど(Twitterクライアントアプリなどもそうですね。何か文字を入力すると「ツイートボタン」が押せるようになります)あるソフトウェアをテストしてたとき、そのボタンは使えない状況だったのに「有効」になっていたのです。ああ、無効にするのを忘れたのかな(単なるコーディングミス)と思ったのですが、実際はもうすこし複雑でした。

ボタンの有効/無効は「状態」によって決まり、4つの状態(A,B,C,D)を持っているモデルがありました。でも、使う側はBかCかそれ以外(D)で判断していました。だからAのときはDに倒れてしまう。Aのときはボタンを「無効」にしなければならないんですけど、Dに倒れたことで「有効」になってしまった。さらに、

  • 状態Aは開発の途中で後から追加した
  • これらの状態は複数の機能で使われている
  • 複数の機能は複数のプログラマーによって開発されている

というものでした。


開発の過程で様々な機能が作られていき、それによって新しい状態が生まれる。元からあった機能は新しい状態を知らない。これまでうまく動いていたものが、あるとき急に動かなくなる。「バグの伝わり方」が目に見えるようでした。

また、このときに思ったのは「外側から見えている状態」と「プログラムで扱っている状態」は必ずしも同じではないということでした。プログラムで扱っている状態は4つ(A,B,C,D)ですが、わたし(テスター)から見えていた状態は3つ(A,B,D)だった。わたしが想像するよりも、プログラムの世界はもっともっと複雑で繊細なのです。

今回の話は「バグの伝わり方」の一例ですが、それ以来、状態に関する変更が入りそうな時には「プログラム内部で持ってる状態が増えたりしますか?」とプログラマーに聞くようになりました。昨日より良いテストをするために(わたし自身が)知りたい!という気持ちが強いのですが、朝会などでわざとらしく聞くのは「このチケットがコミットされたら、状態も気にしてテストしますよ(だからみんなも気にしてね)」というメッセージでもあるのです。