個人でスマホアプリやウェブサービス（以下、アプリ）を作っている人でテストを書いている人がいたら、いますぐやめたほうがいい。時間の無駄だからだ。
自分はほとんどテストを書かない。
細かい動作テストはユーザがしてくれる。
出すことが大事
不具合を恐れるあまりテストに時間を割くのは愚かだ。
自動テストを組むのには相応のコストがかかる。
限られた貴重な時間をテストに使う理由はほとんど無い。
そんなことよりさっさとリリースしてユーザに触ってもらって意見を聞いたほうがずっと有益だ。
不具合が露呈したら恥ずかしい？そんなのは問題ではない。あなたのプライドなど誰も気にしない。
あなたの書くプログラムは銀行口座の引き落としのような厳密さが要求されるのか？爆弾処理のようなプログラムはほんの一握りだ。
不具合のせいでユーザが怒る？それは関係性を深めるいいきっかけになるだろう。不具合報告には感謝を込めて誠実に対応しよう。
アプリはあなた一人で作るものではない。ユーザと一緒に作るものだ。
TDDもBDDもやるな。あれはリソースがたんまりあるチーム開発向けだ。
怒りを好意に変える
不具合は時としてアプリの評価を下げる。
レビュー欄がひどいことになっているアプリを見たことがあるだろう。
そういうアプリはたいていユーザとコミュニケーションする場が設けられていない。
ユーザとの交流の場は機能性に直接関係がないから軽視されているのだろう。
ユーザがレビュー欄に走って怒りをぶちまけるエネルギーはすさまじい。
このエネルギーをアプリの成長に使えたらどんなに素晴らしいだろうか。
この問題にはフォーラムの設置が効果的だ。
フォーラムはユーザと作者が交流している様子が可視化される。
それは作者がユーザの声に耳を貸す姿勢が伝わるという効果がある。
ユーザは自分と同じ問題で困っている別のユーザを見つけられて安心できる。
このフォーラムをアプリ内の見つけやすい場所で案内する。
あるいはクラッシュした次の起動時にアラートなどで案内する。
そうして得られた声に迅速に誠実に答えれば、その怒りは好意に変わるだろう。
ユーザと一緒に作る
ユーザは敵ではない。
不具合を恐れるな。アプリは更新できる。
リリースとはアイデアを試す事だ。
フィードバックを汲み取る仕組みを用意しよう。
もちろん、テストの自動化が「便利」なケースでは使うべきだ。
手作業での動作確認が難しいとか、とても複雑なアルゴリズムだとか。
つまりは効率の問題だ。
方法論に溺れるな。