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

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

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

実装する前や実装中に「こんなことしたらどうなりますか？」と、テスターが Testing の先出しをすることで、プログラマーが「こんなこと」を気にしながら実装してくれる。これは、とても良いことだなと思っています。

— miwa (@miwa719) 2018年10月19日

ああ、これは良いですね。うちのチームも「前にこんなバグあったよねー」「ここ間違えそう！」などなど、起きたら嫌なことを話してます。もしあなたがテスターなら「こういうテストをしてみたい（します）」とモノが出来上がる前に宣言してしまうのもおすすめです。 https://t.co/nX4sVnBVde

— miwa (@miwa719) 2018年11月28日

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

テスターNさんがとてもいいバグを見つけたのを朝会で聞いて嬉しくて「すごい！すごいわ〜」と言いながら思わず拍手してしまいました。拍手いいよね。気分が上がる。流行らせたい👏

彼女は半年前に隣のチームにJoinしたんだけど、最近めきめきと腕をあげてきてる。素晴らしいなあ。

— miwa (@miwa719) 2018年11月29日

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

テストの朝会（他チームのテスターとの）で、昨日見つけたバグを1つ紹介するんだけど、現象だけでなく「なぜ、その操作をしてみようと思ったのか」を話したり、教えてもらいます。その人がこれまで経験してきたこと（見てきたバグなど）がテストに現れるので、その源を知ることは貴重だし価値がある。

— miwa (@miwa719) 2018年9月17日

これは良いですね。わたしは「なぜその操作をしようと思ったのか」も聞いたりします。そうすると「前にこんなバグがあって」とか「画面の更新が急に遅くなったから」とか「こんなバグが出るかと思ってやってみたらそれは出なくてこれが出ました」とか聞ける。それらを自分のテストに活かしていきます。 https://t.co/yVfWRYq03l

— miwa (@miwa719) 2018年11月17日

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

毎朝、昨日見つけたバグやバグではないけど気になることを（チームを超えた）テスター同士で交換するのだけど、話を聞いたテスターがそれに関連するような（または似たような観点で）バグを見つけてくるのはおもしろい現象だなと思っています。一度や二度ではないから、偶然ではないと思っています。

— miwa (@miwa719) 2018年11月14日

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

暴れていいかな

— miwa (@miwa719) 2018年9月26日

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

"彼らはコードのどの部分が弱いかを知っており"

これはプログラマーに聞くことがあります。

「どこが自信ある？」
「どこが自信ない？」

自信あるところも、自信ないところも結局テストするんだけど、こんな会話から設計情報や自身がテストしたところとかが聞けることもある。テストに役立てます。

— miwa (@miwa719) 2018年9月16日

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

些細なバグでも気がついたことは言ったほうがよいと思います。バグじゃないけど気になることも、誰かに話すようにしてる。状況によっては（うるさがられるかな）と思うときもあるけど、そんなときは『割れ窓理論』を思い出します。自分自身が綻びはじめちゃだめだ、と思ってやる。仕事だからね。

— miwa (@miwa719) 2018年8月25日

 

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

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

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

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

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

beauty and harmony

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

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

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

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

コーヒーを淹れるのは、頭の回転が鈍くなる午後２時から３時くらい。リフレッシュして（午後５時まで）あと１、２個のテーマでテストするぞーと思う時間帯です。

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

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秒以外は対応しないという強い意志を示す
• アイコンの背景色は「モカ」という色を使用（コーヒー豆を意識）

　

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

　　

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

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

解決方法

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

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

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

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

新しく覚えたこと

• Timer.scheduledTimer
• Haptic Feedback（触覚フィードバック）
• はてなブログでソースコード（Swift）を貼り付ける方法

開発環境

• Xcode 10.1（Swift 4.2）
• iOS 12.1
• watchOS 5.1.1

その他

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

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

item.rakuten.co.jp

item.rakuten.co.jp

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

cafenekonoya.shop

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

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

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

はじめに

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

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

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

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

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

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

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

blog.jnito.com

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

NEWウォーリーをさがせ!

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

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

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

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

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

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

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

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

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

というものでした。

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

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

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

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

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

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

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

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

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

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

テストのさじ加減

昨日おかしな現象をプログラマーOさんに見てもらった。5分くらい追試したら再現手順が分かったのでOさんの作業場に行ったら、どこのコードがおかしいか当たりがついたところだったようで、再現手順とコードで答えあわせをした。こんな時わたしは（テストというより）デバッグしてる気持ちになります。

— miwa (@miwa719) 2018年10月5日

はじめに

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

「設計の良し悪し」とは

書籍『達人プログラマー』第２章（達人のアプローチ）「８ 直交性」より

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

（中略）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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