「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」

注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1

http://www.publickey1.jp/blog/12/8585.html
http://www.keyman.or.jp/at/dev/debug/30004610/

数値の正確さはともかく，だいたいそんなもんでしょう．

「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない．

• そもそもテストを知らない．テスト＝手動テストだと思っている．
• デバッグといえばデバッガでするものだと思っている．
• 導入するメリットが理解できない．
• テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1

• 導入するスキルがない．テストが書けない．
• テストできるような設計／実装になってない．
• モノリシックでモジュール化されてない．
• マルチスレッド，DBMS，フレームワーク，ネットワーク，或いは内部でそれらを使うライブラリなどが切り離されておらず，かつ切り離すのが非常に困難．
• 副作用がある／大きい．
• コードがスパゲッティ．中身を誰も理解していない．
• 内部の分岐が無駄に多いために，テスト工数が膨れあがる．*2 *3
• 入出力や動作が行き当たりばったりで定義されている．合い言葉は「なんか知らないけど，動いているからいいじゃない」．
• 人材不足＆人手不足．*4
• 技術的負債の利息の支払いで手一杯で，改良にさける余力がない．

• コスト積み上げ式で受注するので，コストダウンのインセンティブが働かない．
• 元請けがそういう風に要求するので，無理に変更するメリットがない．
• 元請けの人は丸投げするだけで，プログラミングを全く理解していない．

• 自社製品を作っている会社が少ない．作って納品したらそれで終わり．後は野となれ山となれ．
• プログラマが外注や短期契約の非正規雇用ばかりで，長期雇用の正社員がいない．いても離職率が高くて短期で辞める／辞めさせられる．*5

• 英語が読めないので，（独学で）身につけることができない．*6

等々．

特にエライ人ほどこの辺りの話を理解していない．

http://b.hatena.ne.jp/entry/www.publickey1.jp/blog/12/8585.html

• id:miyamae 「必要性を感じない」ってなんだよ。「有用性を理解していない」ってことか？ ≫ テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ−マンズネット調べ − Publickey

たぶんそういうことだと．プログラミングスキルのない人は，テストもデバッグも満足にできません．

• id:yogasa そらテスト＝証跡が画面キャプチャ脳の人にはムリよ
• id:A_Kamo 「じゃあその自動テストが本当に合ってるかもテスト検証しないといけないな」なんて言われました
• id:Jxck 回答者が、「テスト自動化」＝「テストを勝手に作って勝手に実行してくれる」と勘違いしてないことを祈る。実際そういう人に会ったことがある。
• id:ghostbass 知ってるかテストケースマトリックスに基づいたテストデータを時間かけて作ってると「時間掛けすぎ」とかいわれちゃうんだぜ？/ああ、せっかくNUnit用プロジェクト書いたのに「インストールに申請が云々」もあったよ

• id:naga_sawa 導入コストと教育（説得）コストが高いので、稼働率をカリカリに上げとかないと回らないような小規模なところはそこに手を回す余裕が無いでは？/大規模なところは専任置いたり先行調査できるからね
• id:Error401 会社が小規模の方が腰が軽く導入率が高いのではと思っていたが、調査結果では真逆で大規模になるほど導入率が高かった。

要するに赤字経営なんだよな．手抜きは「必要なことをやってない」という形で起こるので*7，眼が節穴のエライ人には問題が起こってることが見えてないし，理解できない．プログラミングスキルのない彼らに見えるのは目に見える物だけ．

技術的負債の意味を理解できない経営者やマネージャって害悪だと思うんだ．

• id:yun2dot0 自動化が可能な設計になっていない、という問題が大きそう。いまだにモデルとビューとコントローラがバッキバキに癒着した設計しかほぼ見たことがないので。Javaの案件ですら導入した話を聞かない
• id:smaaash ×必要を感じない○やり方がわからない。やれるスキルもない。
• id:kamei_rio 自動化できるように試験を設計する、って結構ハードル高いよなー

• id:kiyo_hiko テストしにくい巨大ブラックボックスを作られると結局業務をまんま再現して見た目だけを追いかけて、騙し騙し使うしかない　そういうものほど不具合が出るというのに過去にどんなテストをパスしたかもよくわからない
• id:thrakt それ以前にレガシーコードの山をなんとかしないと・・・ / 先々運用保守していこうって考えがない気がする

• id:joker1007 えー、このレベルでこれからアジャイル開発やるぜとか言ってんの・・・？馬鹿じゃないのか。鍛えられたウォーターフォール脳の人にはデグレとか技術的負債とか見えなくなるんですかね。

スキルの問題は大きいです．「テストできない設計」や「糞コードの山」もスキル不足より発生するものですから．結局は人．

1. オールグリーン
2. カバレッジ100%
3. デバッグログの出力とそのログの指す意味の解説レポートを作成
4. 全ての分岐点において、eclipseのデバッグモードを使用してテストの最中に動作を一時停止し、分岐点の前後でスクリーンショットを取得する
5. 超イレギュラーケース(筐体の破損レベル)においてのみ通過する分岐に関しては、「何故その分岐を通過せず、結果としてカバレッジが100%にならないか」を立証説明する
6. 上記を全てExcelレポートにまとめる

　これを全テストケースに対して行う事を義務付けられていました。テストクラスには1万行を超えるトンデモテストクラスもいくつか存在し、そんなものにこれを適用してた際には時間がいくらあっても足りません。…まぁそうは言ってもやったんですが、気合で。
(中略)
とレイヤーが分かれていました。当然それらが結合テストの際に正常に動作しない＝疎通できなければ、プログラムソースコードは修正、単体テストはやり直しになります。テスト自体は自動テストを既に記述済みなのでまぁ良いとして、エビデンスはそうはいきません。先ほど列挙した膨大な量のエビデンスを、もう一度取り直す必要があるのです。よしんば単体テスト工程まで無難に進められても、結合テスト工程で一回ミスるだけでデスマ確定！…って、なんの罠だそりゃ？

http://d.hatena.ne.jp/takigawa401/20120330/1333101469

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup (Pragmatic Programmers)

Less than 100 percent coverage means you have some cases that are not tested. Junior programmers will assume that the converse is true: when they hit 100 percent coverage, they have enough tests. However, that's not true: 100 percent coverage absolutely does not mean that all cases are covered.
(中略)
Don't lulled into complacency by 100 percent coverage: it means nothing about the quality of your code or your tests. Writing good tests, just like writing good application code, requires thought, diligence, and good judgment.

http://d.hatena.ne.jp/JavaBlack/20120505/p1

• id:qaz76 非LLだとこうなる。プログラマが蔑ろにされている証拠。

前半は意味不明．むしろLLの方がテストの必要性は高いが，テストとの相性は悪いイメージ．

• id:ryuzee これリンク元の記事見ると、いわゆるレコーディング系のテストツールを指しているようにも見える。ユニットテストとレコーディング系テストはかなり話が違う（がアンケート先には通用しない先もあるだろうがｗ）はず
• id:t-wada 元記事等を見ると xUnit 系も含めてこの数字と読み取れるが…… http://www.keyman.or.jp/at/dev/debug/30004610/ http://www.keyman.or.jp/at/dev/debug/30002651/

どっちだ．要確認．

追記：xUnitも含むと思われる．

単体テストとは、モジュールなど個々のプログラム（ユニット）が決められた仕様を満たしているかどうかを確認するテストだ。参考までに単体テストのプロセスの一例を図3に紹介する。ここで紹介している「JUnit」とはJava用のオープンソースの単体テストツールで、オープンソースで提供されているIDE（統合開発環境）「Eclipse」にも含まれている

http://www.keyman.or.jp/at/dev/debug/30002651/

Twitter

一体どんな言語を使っているんだ．．．

それとても，「もしスキルがあれば」の話ですけどね．
http://seleniumhq.org/

むしろこういう展開の方が多い気がする．

関連書籍

いい機会なので，ついでにメモ．

テスト本は洋書なら山ほどあるのでチェックし切れてない．和書の方は数も少なく，しかもテストの意味が違ったりすることも多いので要注意．テストの基本的なテクニックに関しては古くてもそんなに変わらないが，ツールに関しては進歩や流行り廃れの激しい分野なので，できるだけ新しい本の方が良い．

こうして見ると，洋書ばかりで和書が質・量共に少なく，あっても古すぎたり時代錯誤なのがほとんど．特に初心者向けの良書が見当たらない．今度気が向いたら探してみるとしよう．テスティングフレームワークを使うだけなら，最近はフレームワークやIDEに統合されてたりするので，それを使うのでも良いと思う．

[asin:0321803027:detail]

本当にちょろっとだけ読んだ．

テスト手法やツールの使い方ではなく，テストへの取り組みや組織的作りに関する読み物的な本の模様．この中でもかなり異質な書籍．テスターへのインタビューなど，プログラマだけでなくテスターに敬意が払われてるんだなと感じる．日本だとテスターはもちろん，プログラマなんてゴミ扱いだもんね．

日本語訳されたら面白いと思ってる本の一つ．日本のSIビジネスがどのように言い訳するか楽しみだ．

テストから見えてくる グーグルのソフトウェア開発

追記：日本語版も出た．タイトルが違うので気付かないかも．

テストから見えてくるグーグルのソフトウェア開発

さらに追記．Kindle版も登場．

パーフェクトソフトウエア

パーフェクトソフトウエア

当時気付かなかったので後で追加．タイトルではテスト本とは分からん．

技術者よりというよりは，もうちょい基本的な読み物的な本らしい．初級技術者またはマネージャーむけか．

そう，私は長年，技術の変遷を見てきたが，それは少しずつ忍び寄ってきた感じだった．数年前にケープカナベラルのロケット打ち上げ中止を伝えるニュースを聞くまで，変化に気づきもしなかった．このニュースのまとめに入った時，１人のアナウンサーが「NASAによると，原因はコンピュータソフトウエアのエラーと言うことです」とコメントした．

もう一人のアナウンサーが，「コンピュータのように単純でありふれたものがこんな間違いを起こすのは変ではありませんか？」と言った．

「そうですね」と最初のアナウンサーが応じた．「ソフトウエアのテストはしてないのでしょうか」

＊＊＊＊

いや，ソフトウエアのテストはしているだろう．断言してもいい．ところが，このアナウンサーは，どうやらテストをすれば完璧な製品ができるはずと考えているのだ．

この会話と，キャスターの非現実的な期待について考えずにはいられなかった．最初はただ肩をすくめて「これがソフトウエアテストに対する一般大衆の無知ってものだ」とひとりごとを言ってみたが，もはやそれですますことはできなかった．次第にこのことに対する意識が高まってきた．クライアントのソフトウエアメーカーのマネージャーでさえ，同じような無知を示すことに気づき始めた．特にマネージャーに多いのだ．ソフトウエアテストのことになると，かれらは正気を失う．

ビューティフルテスティング ―ソフトウェアテストの美しい実践 (THEORY/IN/PRACTICE)

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice)

パラパラ見ただけだけど，実践的ケーススタディ的な読み物で，とても興味深い感じ．むしろタイトルで損をしていると思う．これは普通はユニットテストの基本が分かっている中級以上の人向けだけど，興味があるなら初心者でも挑戦すれば良い刺激になると思う．

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature Series (Cohn))

どちらかというとマネージャー向けかな？

JUnit in Action

JUnitイン・アクション

和書は初版．洋書は第二版．どのくらい違うかは未確認．

The Art of Unit Testing: With Examples in .net

Effective Unit Testing: A guide for Java developers

Junit in Actionの第二版と，上記二冊が良い入門書っぽい気がする．しかしいずれにせよ英語なので，日本人の初心者だと厳しいだろう．*8

The Art of Unit Testing: with examples in C#

"The Art of Unit Testing: With Examples in .net"の第二版扱いなのかな？

追記：

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

日本語入門書では，この本が一番っぽい．

実践 JUnit ―達人プログラマーのユニットテスト技法

Pragmatic Unit Testing in Java 8 with JUnit (English Edition)

Pragmatic Unit Testing in Java 8 with JUnit

より新しい本で注目株．

Perl テスティング ハンドブック

[asin:0131495054:detail]

ユニットテストのテクニック的には名著の雰囲気．ただしあまりに量が多いので，いきなりこれを読むのはお勧めできないだろう．英語だし．むしろ辞書的に使う方が良い気がする．
http://xunitpatterns.com/

JUnit Recipes: Practical Methods for Programmer Testing

Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality

Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast

Testing ASP.NET Web Applications (Wrox Programmer to Programmer)

Pragmatic Unit Testing in C# With Nunit (Pragmatic Bookshelf)

Unit Test Frameworks: Tools for High-Quality Software Development

.NET Test Automation Recipes: A Problem-Solution Approach (Expert's Voice in .NET)

Python Testing: Beginner's Guide

Python Testing Cookbook

[asin:4894717115:detail]

Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))

　

[asin:4048707868:detail]

Test-Driven JavaScript Development (Developer's Library)

[asin:0321784154:detail]

[asin:0321503627:detail]

[asin:193435662X:detail]

Test Driven: TDD and Acceptance TDD for Java Developers

Test-Driven iOS Development (Developer's Library)

Test-Driven Infrastructure With Chef

Professional Test Driven Development with C#: Developing Real World Applications with TDD (Wrox Professional Guides)

Agile Java™: Crafting Code with Test-Driven Development (Robert C. Martin Series)

　

eXtreme Programmingテスト技法―xUnitではじめる実践XPプログラミング (OOP foundations)

非常に古い本．出た当時はこれくらいしかなかったので悪くない選択だったが，今となってはお勧めしない．送料込み251円でも首をかしげるレベル．
既に2001年にはユニットテストの概念はあって，書籍も出ていたという証拠にはなる．

達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化 (Ascii software engineering series)

これは

1. Pragmatic Version Control Using Cvs: With Cvs (Pragmatic Programmers)
2. Pragmatic Unit Testing In Java With Junit (Pragmatic Programmers)
3. Pragmatic Project Automation: How To Build, Deploy, And Monitor Java Apps (Pragmatic Starter Kit)

の三冊をあわせたものだと思う．出た当初は良書だったのかもしれないが，抱き合わせ販売にしたためにJUnitだけが目的の人には割高になってしまった．しかも出てすぐにSubversionが主流になったためにCVSによるバージョン管理部分も時代遅れになって*9，書籍としての価値も半減してしまったようだ．また内容的には比較的軽そう．

以下，テストはテストだけど，ちょっと意味が違う．

[asin:4873115388:detail]

Metasploit: The Penetration Tester's Guide

Advanced Penetration Testing for Highly-Secured Environments: The Ultimate Security Guide: Learn to perform professional penetration testing for highly-secured environments with this intensive hands-on guide (Open Source: Community Experience Distilled)

Metasploit Penetration Testing Cookbook

Selenium 1.0 Testing Tools: Beginner's Guide

たしかSeleniumは既に2.0になってるので，本書は時代遅れのはず．2.0本も出る予定があったがキャンセルされたようだ．公式サイトのドキュメント（英語）が充実しているなので，英語が分かる技術者ならそっちで読めば良いようだ．
http://seleniumhq.org/

追記

Selenium 2 Testing Tools: Beginner’s Guide (English Edition)

Selenium Testing Tools Cookbook (English Edition)

Selenium Simplified

実践 Selenium WebDriver

Seleniumデザインパターン & ベストプラクティス

たぶんこの辺も関係あり．

レガシーコード改善ガイド (Object Oriented SELECTION)

Working Effectively With Legacy Code

継続的インテグレーション入門

Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series (Fowler))

Continuous Integration in .NET

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Java Power Tools

この辺でも一応扱ってはいるようだが，見たことないので要確認．見た目からして内容は薄そうだな．．．

現場で使えるソフトウェアテスト Java編

経験ゼロでもできるプログラミング現場の単体テスト

JUnitによるテストファースト開発入門 (次世代エンジニアへのパスポート)

Webアプリケーションテスト手法

ユニットテストとは違うかもしれんけど，念のため追記．

知識ゼロから学ぶソフトウェアテスト 【改訂版】

はじめて学ぶソフトウェアのテスト技法

ソフトウェアテスト293の鉄則

Web

• 故人ページ： http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/junit.html
• るびま： http://jp.rubyist.net/magazine/?0013-RubyOnRails

• テスト不能な PHP コードをリファクタリングするための戦略 http://www.ibm.com/developerworks/jp/opensource/library/os-refactoringphp/index.html
• レガシー・コードのテスト http://www.ibm.com/developerworks/jp/java/library/j-legacytest/
• コード品質を追求する: カバレッジ・レポートに騙されないために http://www.ibm.com/developerworks/jp/java/library/j-cq01316/
• Selenium 2 を導入する http://www.ibm.com/developerworks/jp/web/library/wa-selenium2/
• Selenium を使用して Web テストを自動化する http://www.ibm.com/developerworks/jp/opensource/library/os-webautoselenium/
• http://www.ibm.com/developerworks/jp/offers/jasst/ : ちょっと古いけど，第3回のツールなどは小さくまとまっているので目を通す価値あるかな？

developerWorksの「テスト不能なPHP〜」は目を通しておくと良いかも．こういうちょっとした変更ができないモノリシックなコードは，テスト作成の敵なのです．

キーマンズネット

http://www.keyman.or.jp/at/dev/debug/30002651/
リンク元を確認

一般的に開発フェーズとテストフェーズの関係はV字モデルで表現される。

．．．なんという脱力感．orz

調査している本人が，バカの元締めだったというオチかな？

*1:http://d.hatena.ne.jp/JavaBlack/20120520/p1

*2:最近あった偶数／奇数のアレなんかは，ある意味で好例と言える．あんなコードを書かれたら，テストの側もcase文の数だけ分岐が必要になる． http://d.hatena.ne.jp/JavaBlack/20120529/p1
しかも実際にはそれと強く依存関係のあるコードが二段三段と重なって，組み合わせの数も二乗三乗で増えていくので，バカが書いたコードは容易にテスト不可能になる．

*3:「テスト書いたら時間がかかる」なんて言ってる奴の，一体何割がそういう糞コードが原因であることか．下手っぴが書いたコードほどテスト困難で，そのままテストを作ると膨大な工数がかかったりする．

*4:改善が上手く言って人手が足りてくるとエライ人が「効率化」して一人減らすので，結局テストを構築する余力がなくなったり．

*5:長期だからテストを作るとは限らないが，短期の場合はメンテナンスを担当するのが他人なのでテストを作るインセンティブがない．短期だとテストを作った方がむしろ「無駄なことをした」という口実でクビにされたりする．無能な管理職はIT企業のお荷物だねえ．

*6:必ずしも全員が英語をスラスラ読める必要は無くても，最低誰か一人はマニュアルや参考書を英語で読んで吸収する必要がある．しかし，それができる人が職場に一人もいないというのは良くある話．

*7:たとえば，コメントがなかったり，間違ったコメントが修正されなかったり，例外処理が抜けてたり，バグが放置されたり，実行されることのないゴミコードが削除されなかったり，バージョン管理がなかったり．

*8:"The Art of Unit Testing"は第二版のMeapでの執筆が始まっている．June 2012 始まりなので，完成はまだ先の話． http://www.manning.com/osherove2/

*9:

Pragmatic Version Control: Using Subversion (Pragmatic Starter Kit)

Subversion実践入門?達人プログラマに学ぶバージョン管理

Pragmatic Version Control: Using Subversion (The Pragmatic Starter Kit Series)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)