こちらの講演時にいただいた質問への回答です。

「テスト自動化とテスト駆動開発」講演資料 - やっとむでぽん

質問3. かなり最初の方のスライドにありましたが、「テスト自動化で新規のバグが見つかることは稀である」の意図とは何でしょうか?

STARソフトウェアテスト自動化研究会が提供している、テスト自動化の8原則ですね。

sites.google.com

  1. 手動テストはなくならない
  2. 手動でおこなって効果のないテストを自動化しても無駄である
  3. 自動テストは書いたことしかテストしない
  4. テスト自動化の効用はコスト削減だけではない
  5. 自動テストシステムの開発は継続的におこなうものである
  6. 自動化検討はプロジェクト初期から
  7. 自動テストで新種のバグが見つかることは稀である ←コレ
  8. テスト結果分析という新たなタスクが生まれる

これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら=原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。

簡単に言ってしまえば、「いったん正しく動くようになったものは、基本的にはそのまま正しく動き続ける」ので、その動きをなぞるテストを自動化しても、未発見のバグを発見する装置にはならないという意味です。 同じページから、こちらの7番の解説も引用します。

7. 自動テストで新種のバグが見つかることは稀である

運用に乗った自動テストは基本的に「枯れた」テストケースを対象とするため、ほとんどの種類のバグはテストケースを枯らす過程、あるいは自動テストを実装する過程で既に人間によって発見されているはずである。多くの運用に乗った自動テストの意義は「一度動いたはずの機能がうっかり壊れる」ことを最速で発見することにある。ただし、手順が同じでデータの種類が膨大なテストを自動化する場合、ファジング、テストパターンを有機的に生成できるAPIレイヤのテスト、ブラウザやRDBなどのバージョンアップの影響を受けていないことを確認するテストなど、いくつかの例外もある。

以前に直したバグが何らかの理由で再発してしまう、という事態を防ぐ役には立ちます。人間は同じミスをやらかしがち、と考えると、それほど悪くないようにも思えます。

逆に言うと、未発見のバグ、新種のバグを発見するには人間が手作業で、機械的ではない創造的な操作、観察、分析、推論などをしながらおこなう、探索的テストが向きます。探索的テストの結果から、発見したバグを再現するテストを自動化するのが効果的です。

質問4. 人によって「よいコード」=リファクタリングの着地点が違うのでは…?

その通りなので、着地点はチームとして合意しておきます。

質問2.で紹介した、B.「リファクタリングする」という動詞では、このコードをどういうふうにきれいにすべきか、探索しながら決めていきます。ペアプログラミングをすれば、ペアで相談しながら落とし所を決められます。 いずれにしても、よいコードは個人にとってではなく、チームにとってよいコードでなくては、意味がありません。

書籍『リーダブルコード』では「コードは他の人が最短時間で理解できるように書かなければならない」という、客観的指針を提示しています。Point of Useに向け、ソフトウェアを直しやすくしたいと考えたとき、実はプログラマーはコードを書くより読むことに時間をかけており、一説には10倍以上だとも言われています1。読む時間を短縮できるようにリファクタリングするというのは、有用な選択肢です。

個人の好き嫌い、センス、バックグラウンドなどによって、「よいコード」「きれいなコード」の基準は変わってきてしまいます。誰かの基準を押しつけるべきではないですが、チーム全体にとって読みやすくするには、個々人の状況も加味する必要があります。また言語、フレームワークアルゴリズムに習熟すると、「読みやすい」基準も変わってきます。たとえば「1からnまでの整数を合計する」ような簡単な処理でも、いくつか書き方があります。どれが最短時間で読めるかは、チームのスキルで変わってきますし、成長によっても変化します。

Pythonの例:

# a)  
s = 0
for i in range(n):
  s += i + 1

# b)
s = sum([i + 1 for i in range(n)])

# c)
s = n * (n + 1) / 2

「最短時間で読めるコード」は、人によって違い、チームによって違う。同じチームでも時期によって違う。そう認識すると、いわゆる標準化でカバーできる領域はそれほど大きくありません。経験と知識共有と成長の過程で、合意しつつ、少しずつアップデートしていくものとなります。

www.amazon.co.jp