Mirror House Annex

『初めての自動テスト ―Webシステムのための自動テスト基礎』を読んだ。 『アジャイルサムライ』の著者が送る自動テスト指南書。 一口にテストと言っても、いろいろなテストレベルがあるけれど、本書ではユニットテストから統合テスト、UIテストまでカバーしている。『アジャイルサムライ』で「問答無用で実践すべき」と紹介されていたのはユニットテストだけだったけれど、テストをテーマに掲げた本書では統合テストもUIテストも扱っている。 広範なトピックをカバーしつつも、ポイントを絞って詳細には立ち入らないので、コンパクトにまとまっているのがありがたい。これだけ幅広く「初めて」の人向けの説明がまとまっているの、見た記憶がない。各テストのバランス――テストピラミッドの話とか、人に伝えるときの参考にしよう。 自分は「初めて」というわけじゃないけれど、狭く深く追いかける癖があるので、こういう本が顔を上げて辺りを見回すいい機会になる。 最後に余談。個人的な語感の話だけれど、よく聞く〈テスト自動化〉より〈自動テスト〉の方が好み。〈テスト自動化〉と言うと手動テストを代替するイメージ。〈自動テスト〉と言うと手動テストとは違うテストをするイメージ。手動テストでは実現できない速度と頻度が欲しいので、後者の表現の方が、それっぽい。

『レガシーソフトウェア改善ガイド』を読んだ。『レガシーコード改善ガイド』とタイトルが似ていて紛らわしいけれど、続編だとかそういう直接的なつながりはない。そもそも原題は全く違う。 レガシーコード改善ガイド → Working Effectively with Legacy Code レガシーソフトウェア改善ガイド → Re-Engineering Legacy Software こちらの方が扱っている範囲が広い。『レガシーコード改善ガイド』がテスタビリティの低いコードに対してユニットテストを書く方法に特化しているのに対して、こちらは組織的なコンセンサスや承認の話から、静的解析をはじめ環境構築やビルドまで自動化全般を扱っている。 範囲が広い分、記述の抽象度が高くなっている。そのため、トピックによっては物足りなさを感じることもあった。特に気になったのが例のシンプルさ。レガシーソフトウェアとの戦いでは、泥臭い作業が必要で下手したら泥沼化しかねないと思っているから、あんまり例がシンプルだとちょっと不安だ。 おもしろかったのは、ユニットテストの扱い。『レガシーコード改善ガイド』がそれにフォーカスしていたのに対して、こちらでは、誇張だと断ったうえではあるけれど、 リファクタリングする前にユニットテストを書くのは、ときには不可能であり、しばしば無意味である。 と書いている。「ときには不可能」というのは、テスタビリティの低いレガシーコードにユニットテストを書くことの難しさを言っている。確かに思い当たる節がある。テスタビリティの低いコードを書いているプロジェクトで、トリッキーなテストコードを書いていけるとは思えない。「しばしば無意味」というのは、しばしばリファクタリングでクラス構造を変えることになり、ユニットテストが用をなさなくなることを言っている。こちらは分からないではないけれど、誇張し過ぎじゃないかな、と思う。 ユニットテストがこんな状態なので、複数のテストレベルで自動化しようと言っている。もう少し具体的に考えるなら、保護したい結合範囲（内部構造をリファクタリングしたい結合範囲）の振る舞いをテストでくるむことになるだろう。それがユニットテストより大きければ、サービス層をくるむ Subcutaneous Test なのかシステム全体をくるむEnd-to-End ...

"Explore It!"を途中まで読んだ。 この本はソフトウェアテスト技法の一つ「探索的テスト」についての本。『知識ゼロから学ぶソフトウェアテスト【改訂版】』の第4章でも触れられていたけれど、もう少し詳しく知りたくて手に取ってみた。 読んだのは、Chapter 5 Evaluate Resultsまで。I. Establishing Foundationsを読み終えたので一旦ここまで。II. Adding DimensionsとIII. Putting It in Contextは、また必要な時がきたら読むことにした。 1. On Testing and Exploration 2. Charter Your Expedition 3. Observe the Details 4. Find Interesting Variations 5. Evaluate Results 探索的テストが、スクリプトテスト (事前に設計してから実行するテスト) と大きく異なるのが、テストの設計と実行が同時並行で行われる点。メリットは、直前の実行で得られたテスト対象に関する情報を、次のテスト設計に活かせること。おかげで、効率よくバグを発見できる。 デメリットは大きく2つ。いずれも他のテスト技法の裏返しになるので、テスト全体としてはこれらをうまく組み合わせていく必要がある。 1つ目はテスト対象が動かないと始められないこと。動かしながら実施すべきテストを設計していくので、どうしたって探索的テストを始められるのは遅くなる。にテスト対象の前にテストコードを書くテスト駆動開発 (TDD) とは正反対。一般に、バグの発見が速いほど修正が容易なので、テストはできるだけ早く始めたい。 もう1つは、網羅性がないこと。どの範囲でなら正しく動くかを確認するのには適さない。こちらには探索的テストよりスクリプトテストの方が向いている。 きっと アイスクリームコーン にならないようにうまく テストピラミッド を積み立てていくのが良いのだろう、という漠然とした方向は見える。けれど、具体的にどうしていくかは、ケースバイケースの側面が強いんだろうなあ。

『SOFT SKILLS』を読んだ。この本の構成は次のとおり。ソフトウェア開発の技術に関する話は出てこない。でも刺激的だった。 第1部 キャリアを築こう 第2部 自分を売り込め！ 第3部 学ぶことを学ぼう 第4部 生産性を高めよう 第5部 お金に強くなろう 第6部 やっぱり、体が大事 第7部 巻けない心を鍛えよう 描かれているのは、ソフトウェア開発者である著者の生き方だ。だから、サブタイトル『ソフトウェア開発者の人生マニュアル』というのも、あながち大袈裟でもない。 ただ「マニュアル」と称するのはさすがに言い過ぎか。首肯できない主張やとても真似できない選択がチラホラある。それらからさえ率直さを感じさせられるので、ちょっとズルい。 ともあれ、肯けるところは取り入れよう／前にやっていたことけれどいつの間にか止めてしまっていたことを再開しよう、そう思わせてくれるくらいの熱量があった。 本書を読んで再開してみた活動を挙げてみる。特に ポモドーロテクニック は、止め方が著者とあまりにソックリでビックリした。反対に、体の鍛え方は真似できそうにない。だからボチボチで。 GTD ポモドーロテクニック 筋トレ これらに加えて、停滞していたブログもエントリィを書く予定を立てたし（このエントリィを書くことも、その予定を守ることにつながっている）、お勧めの本（の一冊の『人を動かす』）も読み始めた。 その他、雑多な感想をいろいろと抱いてツイートせずにはいられなかった。 togetterにまとめてみた ら、これはこれで自分でも（自分だからこそ？）おもしろかったり。 各章の平均点は100点に満たないのだけれど、章によっては150点、200点の刺さり方をする。そんな1冊。

『知識ゼロから学ぶソフトウェアテスト【改訂版】』を読んだ。章構成は次のとおり。 はじめに ソフトウェアテストの基本ーホワイトボックステストー エンジニアが最もよく使う手法ーブラックボックステストー 探索的テスト 機能あらざるもののテスト、最難関のテストに挑むー非機能要求のテストー ソフトウェアテスト運用の基本ーテスト成功の方程式ー ソフトウェア品質管理の基本ーソフトウェア品質のメトリックスー テストの自動化という悪魔ーなぜ自動化は失敗するのかー それでもテストがうまくいかない人へ とても扱いやすい。テストについてマネジメントからテスティングまで、コンパクトかつプラクティカルにまとまっている。語り口こそ違うけれど、 『はじめよう！要件定義 ～ビギナーからベテランまで』 によく似た印象。 自分はユニットテストから入ったのでコードありきだけれど、そうではないテスタも少なくないことに改めて気付かされる。 和田卓人の“テスト駆動開発”講座 第3階「テスト」という言葉について の分類を使って言い換えると、Developer Testingの視点に偏りがちで、Customer TestingやQA Testingの視点が足りていない。意識していないとすぐ抜け落ちてしまう。

『Fearless Change』を読んだ。 "Change"――つまり「変える」ためのパターンが紹介されている。サブタイトルに「アジャイルに効く」とあるけれど、これらのパターンはアジャイルに限らず適用できるように見える。 自分が変わるのさえ難しい。どれだけ同じ過ちを繰り返していることか。ましてや他人を変えるなんて!!「他人と過去は変えられない」ってよく言うよね？ それでも現状を打破したいと思う。断続的に、ではあるけれど (普段はそこまで気が回らない)。というわけでこの本を読んでみた。 ざっと読んでみるだけでも、何が自分に足りていないのか、知るキッカケになる。自分の場合、縦にも横にももっと協力を求めないと、進めないだろうと思い知らされた。正直、苦手だ。ついつい先送りにしてしまう。 ステップバイステップで進めよう。

『迷惑をかけないExcel』を読んだ。ここのところExcelを触ることが多いので (残念なことに)。 言っていることは合理的。ポイントは次の2つ。これらのポイントを押さえておけば、再利用性や保守性を高くすることができる。 入力と処理と出力に分けて考える。 機能と関数とVBAを使い分ける。 自分には「Excelブックをソフトウェアとして設計せよ」と言っているように聞こえる。 Excelファイルにはストレスを感じることが多いけれど、こうして改めてExcelに向き合ってみると、エンドユーザコンピューティングの環境としてよくできていると感じる。 ユーザの問題の方が大きいよなぁ。自分には合理的に聞こえる本書の主張も、ほとんど手を動かさないで最終的な見映え (自転車置き場の屋根の色) しか気にしない人には、訴えるところはないだろう。 どうしたもんだか。

『魔法の世紀』を読んだ。研究者でありメディアアーティストである著者が、その研究成果・アートの位置付けやコンセプト、それから目指すところを書いている。 第5章「コンピュテーショナル・フィールド」とそれを受けての第6章「デジタルネイチャー」が刺激的だった。第5章では = 物体も情報も一元的に記述できる場の記述が導入される。第6章では、物体を情報的に制御する次の2種類のアプローチが紹介されている。 デジタル処理されたアナログな物質 アナログな物質を変化させるデジタル計算機 確かに〈魔法〉を使えるようになるには、このどちらかだと思う。つまり、人間が魔法の世界に入っていくか、人間の世界を魔法の世界にするか、だ。前者は、人間の意識（アナログな物質が計算する情報）がデジタル処理（アップロード）されて魔法の世界（プログラマブルな仮想世界）に移動（あるいは複製）されるイメージ。後者はよく分かってないんだけれど、何だかワクワクさせてくれる。 コンピュテーショナルフィールドで物体と情報を一元的にを記述できて、情報をデジタル処理してアナログな物質が変えられるようになるとしたら、それって『ウィザーズ・ブレイン』とか『されど罪人は竜と踊る』、『レターズ/ヴァニシング』の世界だ!! と思ってしまって。 という夢のある話だけじゃなくて、身近なところでは次の指摘が最近の自分が悩んでいることのヒントになりそう。 古典的にはゲームやイベントなど人の動きに関わるような分野でノウハウとして溜まっているようなものが、今世紀もっと一般的なデザインへと流れ込んでくるのではないかと考えられます。 エンドユーザやオペレータの動きまで含めたシステム全体としてのデザインってこの辺りにつながりそうだなぁ、とか。各ユーザの使うUIの洗練とか、ネットワークを介したユーザどうしのコミュニケーションとか、ゲームの得意分野だろうなぁ、とか。そう言えばゲーミフィケーションって耳にしなくなったなぁ、と。

『【全15巻合本版】角川インターネット講座』をちょっとずつ読み進めている。先日 (1月末頃)、Kindleストアで、87%OFF+20%ポイント還元の大盤振る舞いだったので、全部は読まないだろうと思いつつまとめ買い。 最初に読んだのは、『1 インターネットの基礎』の第2部『TCP/IP発明者からの「宿題」』。大きな課題が俯瞰的に語られていて新鮮だった。自分の視線は細部にばかり向いている (その割に解像度は低いけれど)。 IPv6とかHTML5とかHTTP2.0とか、ここ数年で要素技術がアップデートされているけれど、もっと長期的かつ抽象的な「宿題」が提示されている。いくつも挙がっている中で、自分が特に気になったのは次の3つ。どちらかというとユーザの視点が強く出ている。 あらゆるレベルのセキュリティ ビット腐れ (bir rot) ガバナンスに関する課題 セキュリティが確保されていないと安心して使えないし、ビットが腐ると思うと大事なデータのアナログな原本を捨てられない。もちろんこれらは、利用者個人としても気をつけるべきことではある。パスワードを使い回さないとか、データは定期的にバックアップするとか。でも、技術的に解決できるものならして欲しい。 一方で技術と個人だけでは解決しない問題もある。著作権の問題をはじめ、技術が法の前提を揺るがすことがある。これらはガバナンスに関する課題として顕在化してくるはず。それから、技術からさらに離れると、倫理に関する課題も出てくるはず。 ロボット倫理 とか 神経倫理 とか。このあたり、哲学の〈主体〉とか〈責任〉に関する議論と繋がりそうだよなぁ。このあたり 『CODE 2.0』 が詳しかったはず（記憶が朧気）。対比させるとこんな感じだろうか。 アーキテクチャ: 技術 市場: ユーザ 法: ガバナンス 規範: 倫理

「『エクストリームプログラミング』を読んだよ」 「新訳の方ですね」 「最近、コミュニケーションが原因の問題に直面しているから、次の質問に考え込んでしまった。いろいろと考えてみたものの、まとまらないままだけれど」 問題に遭遇したときは、それがコミュニケーションの欠如によるものかどうかを自問してみよう。今から問題に対応するには、どのようなコミュニケーションが必要だろうか？これからトラブルに巻き込まれないようにするには、どのようなコミュニケーションが必要だろうか？ 「そもそも得意じゃない方ですよね？」 「うん。そのうえ相手あっての話なのが難しい。自分だけじゃどうにもならないから。まったく、どうしたもんかなぁ」 「一朝一夕で解決するような問題ではありませんし、気長にちょっとずつ変えていくんでしょうね」 「のんびり構えるかなぁ」

『実践ドメイン駆動設計』を2ヶ月ほどかけてちまちまと読み進めて、ようやく最後まで辿り着いた。 『エリック・エヴァンスのドメイン駆動設計』 に比べれば分かりやすい。たとえば、ちゃんと基礎となる戦略的パターンから説明されている [1] 。 ただ、それでも理解できたのはほんの一部だけ。噛み砕けていない部分の方が多い。諦めて斜め読みで済ませることがしばしば。 それでも読んでよかった。 まず、きっとまた読むことになると予感できた。苦労して読んだがゆえのバイアスかもしれないけれど。だとしても、噛み砕けないなりに、部分部分で得るところがあった [2] 。 余談。「カウボーイの声」が分からん……。文化の違いだろうか……。 [1] ドメイン駆動設計の間違った方向性 によると、『エリック・エヴァンスのドメイン駆動設計』では、基礎となる戦略的パターンが後半に書かれてしまっている。 [2] なるべくツイートするようにしていた。 『実践ドメイン駆動設計』を読んでいるときのツイート - Togetterまとめ に拾ってある。

『世界を動かすプロジェクトマネジメントの教科書』を読んだ。 「世界を動かす」だなんて、大げさに感じていたけれど、実質的なターゲットは中小規模・受注型プロジェクトだった。それならちょうどいい。大規模・受注型でも、厳格なマネジメントがされていないなら、この辺りから始めることになるんじゃないだろうか。いきなりフルセットは導入できない。 コストやリスクのマネジメントも含め一通り触れられているけれど、関心を引かれたのは進捗のマネジメント。これまで何度も、それに今も問題になっているからだろうなあ。まともに進捗することの方が珍しいくらいで、溜め息が出る。 きっと後で見返すであろう、自分にとってのポイントは次の通り。これらが、進捗管理の基本的なフローを構成している。くわえて予実の乖離に対するリカバリが必要だけれど、その内容はケースバイケースになるだろう。 2-3 WBSを作る 抜けがないように、P-WBS (成果物スコープ) とF-WBS (仕事のプロセス) のマトリクスで洗い出す。プロジェクトマネジメントの作業も忘れない。 3-2 スケジュールを立案する 「いつ着手すべきか？」を「逆算」で考える。並行関係、依存関係を意識する。 4-1 進捗を正しくとらえる 「いつ終わるか」を予測するために、「仕事があとどれだけ残っているか？」でとらえる。 4-2 スケジュールをコントロールする 見込日（≠予定日）で追いかける。計画のベースラインはめったに変えない。 とにもかくにもWBS。これが 最大のポイント とかかれている。P-WBSとF-WBSのマトリクスを知った今振り返ると、自分はP-WBSの視点でばかり考えていた。F-WBSにも目を配るようにしよう。そして、作ったら WBS作成のポイント を使って見直そう。

『実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる』を読んだ。2年前にテスト駆動開発について勉強しようと思った時には、まだハードルが高そうだったので見送った1冊 (ちなみにその時は 『JUnit実践入門』 で勉強した)。 読みながら考えたことをtogetterに集めた っきりにしていたのを、改めて振り返って整理してみようと思う。 この本の主題は、タイトルの〈テスト駆動開発〉ではなくて、サブタイトルの〈オブジェクト指向〉だと思う。原著のタイトル "Growing Object-Oriented Software Guided by Tests" に対応しているのも、サブタイトルの方。 次のエピグラフが、オブジェクト指向設計とテスト駆動開発の関係を端的に表している。 何かを設計するときには、常にもうひとまわり大きなコンテキストの中で考えること。椅子ならば部屋の中にあることを考える。部屋なら家の中、家なら環境の中、環境なら都市計画の中。 エリエル・サーリネン ここでいう「もうひとまわり大きなコンテキスト」がテストに対応する。 この比喩が示すように、ソフトウェアをエンドツーエンドで設計するために、動くスケルトンを作る。つまり、ユーザにどう使われて外部システムどうインタラクションするかを考える。加えて、開発側が行うプロセスもエンドツーエンドで通してみる。つまり、コンパイルだけでなくデプロイまでどうするか考える。 テストを書くことのメリットは、「Note インターフェイスとプロトコル」でいうところのプロトコル――インターフェースどうしの関係やメソッドどうしの関係をどうしたって考えることだと思う。テストなしだと各メソッドのシグネチャに指向リソースが奪われてしまう。 複雑な依存をコツコツ調べて引数無しコンストラクタでインスタンスを生成して、適切な順と適切な値の組み合わせでSetterを呼んで状態を調整して、ようやく呼び出せるメソッドのいかに使い辛いことか。そう言えば、 『レガシーコード改善ガイド』 にもこんな章があった。 このクラスをテストハーネスに入れることができません このメソッドをテストハーネスで動かすことができません これをうまくやるには、要件の理解とその分割が必要になる。必要なスキルセッ...

『Selenium デザインパターン & ベストプラクティス』を読んだ。読み進めていくと、Seleniumを使ってテストを書き始め、それを成長させながらパターンを入していくシナリオを追うことになる。ストーリィのあるシナリオに沿って読み進めていけるので、パターンカタログより入りやすい。そう言えば『実践テスト駆動開発』もこの書き方だった。 最近、テストコードよりテストデータに関心が向いているので、「4章 データ駆動テスト」はちょっとスピードを落としてじっくり読んでいたように思う。特に、Default Valuesパターンとfakerライブラリに関する記載を、読んでは悩み読んでは悩みを繰り返している。 Default Patternsパターンでは、テストの関心でないデータにはデフォルト値を使う。 "xUnit Test Patterns" でいうところの Dummy Objectパターン に近いと思う。その利点と欠点は次のとおり。欠点1は比較的軽いと思う。テストヘルパに寄せたり、許容できるレベルまで軽減できる。より深刻なのは、欠点2の方だ。バグを見つけられないリスクが高くなる。 利点 知る必要があるものだけに知らせる テストがシンプルになる 焦点を絞れる 重要な値だけを上書きする 欠点 上書きを実装する必要がある データが均一になる そのデフォルト値として実際に入力されそうなデータを使いたい、というのがfakerライブラリのモチベーションのようだ。ここはnullも候補になるDummy Objectパターンとは大きく違う。テストレベルの違いが出ている。 どんなテストであっても、できるだけ実際のシナリオに近い入力データを目指すべきです。 テストの関心ではないからテスト設計はしないにしろ、確かにあまりにも非現実的なデータだと、サービス開始直後に足下を掬われるかもしれない。デザインの文脈でいうところの "Lorem Ipsum" のようなものだろう。 本書では触れられていないけれど、fakerライブラリで実際に入力されそうなデータを作る代わりに、実際に入力されたデータ（いわゆる移行データ）を使う選択肢もあると思う。そもそも存在しないとかセキュリティ制約にひっかかるとか、使えない場合も多いだろう...

ここ最近、データベース設計のダメさ加減に苦しめられている。悩んでいる最中、『達人に学ぶDB設計徹底指南書』を読んでいたら、 下手くそなデータ構造に対して、エレガントなプログラミングを行うことは不可能なのです。データ構造がダメな状態で、プログラミングによって挽回することはできません。 とあり、挫けそう。 解消するためにどうアプローチしたらいいか参考になると思って、『データベース・リファクタリング』を読んでみた。 そうしたら、本書でも というのも、データレベルの設計が貧弱だと、まず間違いなく上位の層に問題が波及し、ほとんどの場合は、頼りない基礎を安定させようと無駄な努力をしながら、質の悪い設計を繰り返していくことになるからである。 なんて書かれていて、追い打ちを食らった気分。まさにその通りで、どんなに努力しても、設計の質が一向に良くならない。影響を局所化するためにレイヤを切りたいのだけれど、切り口が見えない。 続くこの一文を読んで、変えるしかないんだろう、とは思う。内容はプラクティカルで合理的だと思った。が、文化的・政治的な文脈でも自分のロール・性格的にも難しそうで、二の足を踏んでいる。 さらに、変更が認められなかったり怖くてできないなどの理由でデータ層を発展させられなければ、ソフトウェアを最善の状態で納品することはとうてい不可能になる。 どうしたもんだか。

『ソフトウェアテストの技法 第2版』を読んだ。 テストには一見相反した態度が必要になる。改めてそう思った。真剣にバグを見つけようときめ細かくテストしつつも、結果的にバグが出ないことも成功だからだ。 われわれの考え方からすると，ひと塊のソフトウェアに対する，よく構成され実行されたテストは，修正できるエラーをみつけたときに成功と見なし．そしてその同じテストによって．これ以上エラーがみつからないことが結果的に確立されたときにもまた成功と見なす． 気をつけないといけないのは、バグが出なかったという結果は成功だけれど、バグを出さないという目的でテストしているわけではないことだ。それならテストを粗くすればいい。極端な話、テストしなければ出てくるバグは皆無だ。 できるだけ多くのバグを見つけようとしなければ、テストする甲斐がない。頭では理解しても、これがなかなか難しい。例えば、一刻も遅れも許されないという状況で、バグを見つけようと徹底できるだろうか。見つけてしまえば、修正～再テストが必要になって、ますますスケジュールがタイトになるというのに。 テストとは，エラーをみつけるつもりでプログラムを実行する過程である． 嘘か誠か、テストコードを動かすだけ動かして、全く結果を見ていなかったプロジェクトがあったなんて話が、Martin Fowler's Blikiにある。4 Phase Testでいうとexerciseまでやってverifyしなかっただなんて。 しかしながら、そのJUnitのテストコードにはassertionが一切含まれていなかった。 Martin Fowler's Bliki in Japanese - AssertionFreeTesting これは極端な例にしろ、ともすればテストが通るようにテストデータを設計しがち。最初はそれでいいと思う。まずHappy Pathを通すのは悪くない。『ソフトウェアテスト 293の鉄則』にもこうある。 鉄則287 製品の成熟度に応じてテストせよ でも、それだけじゃ明らかに足りない（どこまでやれば十分か、は明らかじゃないけれど）。

『はじめて学ぶソフトウェアテストの技法』を読んだ。 控え目に言って、読む順番を間違えた。ソフトウェアテストのテストケース設計技法を学ぶ取っかかりとして、良い本だと思う。最初に導入すべき同値分割や境界値分析について学べる。そこからさらに広げるための各種技法も一通り揃っているように思う。紹介されている技法は下記の通り。 ブラックボックステスト技法 同値クラステスト 境界値テスト デシジョンテーブルテスト ペア構成テスト 状態遷移テスト ドメイン分析テスト ユースケーステスト ホワイトボックステスト 制御フローテスト データフローテスト 探索的テスト この本だけじゃよく分からない技法もあるけれど、リファレンスがあるから必要に応じてそちらを当たればよいと思う。 のだけれど、自分は先にそちらを読んでしまっていた。 『ソフトウェアテスト技法』 とか、とか。 『ソフトウェアテスト293の鉄則』 とか。というわけで、「順番を間違えた」というのが正直な感想。 でも、全部のテスト技法を押さえているわけではないし、テスト技法だけでなくて計画・管理のトピックも立っているので、ソフトウェアテストについて概観するのに便利。

『はじめよう！要件定義 ～ビギナーからベテランまで』を読んだ。 要件定義の肝が200ページ足らずにコンパクトにまとまっているように見える。「見える」と言ったのは、自分は要件定義に明るくない（つまりビギナーだ）から。これが肝かどう判断がつかない。でも、最近の問題意識と照らすと的を射ているように感じる。本書が述べる要件定義の成果物が揃っていたら、今の苦労はない。ダメを押したのが下記の書評。 【書評】はじめよう！要件定義 -ビギナーからベテランまで - GoTheDistance 糞システムにしないため、私ができること『はじめよう！ 要件定義』: わたしが知らないスゴ本は、きっとあなたが読んでいる 本書にある、要件定義の成果物がちゃんとそろっていたら、今どれだけ楽なことか。各機能の処理定義が手続き的に記述されているドキュメントはあるけれど、入出力定義や行動シナリオがないから実装できないし、テスト設計もはかどらない。 企画書 全体象（オーバービュー） 利用する実装技術 実現したいこと一覧（要求一覧） 行動シナリオ一覧 行動シナリオ ワークセット一覧 概念データモデル ラフイメージまたはモックアップ 画面遷移図 項目の説明 機能の入出力定義 機能の処理定義 統合ERD 一方で、自分はDBを重視しているからか、 「データベースはUIに従属する」 なんてUIファーストな手法には抵抗がある。まっさら新規開発ってレアで既存データがあるはずだから、それも押さえたくなる。UIファーストだけでは細部が抜け落ちていたりする気がして安心できない。

『システムテスト自動化標準ガイド』を斜め読みした。「システムテスト」というと機能テストだけでなく非機能テストも含むことが多いけれど、本書の中心は機能テスト。もちろん機能テストだけでもトピックは多岐に渡る。なお、「標準」とあるけれどISOなどの標準化団体がオーソライズしているわけではない。 本書が説明しているのは、 テスト実行ツールを用いて中～大規模のテスティングを自動化し、継続的に利益を得るためには、自動テスティングの枠組みをどのように設計・構築すれば良いか。 「継続的」であるために、「スパゲティテスト」を問題にしている。具体的には、キャプチャリプレイツール (例えばSelenium IDE) の安易な利用で濫造されるメンテナビリティの低いテストコードを想定しているみたい。「第2章 キャプチャーリプレイはテスト自動化でない」で「単なる記録によるテスティングの自動化は行うなかれ」と提案している。システムテストではなくユニットテストにフォーカスした "xUnit Test Patterns" でも同じ事を言っていた。 以下、あとで参照するときのための覚え書きとして、どこにどんなことが書いてあるか簡単に整理しておく。 第1章、第2章は概論と失敗シナリオ（キャプチャリプレイだけでは自動化できない）の説明。 第3章から第9章までが、テスト自動化に関する技術の話。第3章はテストコードの開発アプローチ（リニア／構造化／共有／データ駆動／キーワード駆動）について。第4章は自動比較 (4 Phase TestでいうVerify) の自動化について。第5章はテストウェア（テストコードやテストデータ、各種ドキュメント、テスト結果）のアーキテクチャ。第6章は前処理と後処理 (4 Pahse TestでいうSetupとTear Down) の自動化。第7章が保守性について。第8章はテスト管理やテスト自動化で計測するメトリクスについて。最後の第9章は落ち穂拾い。 第10章、第11章は非技術面の話。第10章はツールの選択プロセスについて。第11章は組織に導入し定着させるためのプロセスやそこで各人が果たす役割について。自分が苦手とするところなので、ここは気持ちしっかり読んだ。が、苦手だからだろうなぁ、あまり具体的なイメージが湧かない……。 第12章以降は...

『バッドデータハンドブック』を読んだ。 「ハンドブック」という言葉からパターンなりノウハウなりがまとまっているかと思っていたけれど、どちらかというとエッセイ風な印象を受けた。そもそも体系的に扱えないのがバッドデータだから、期待が過剰だったか。 本当に色々な話がある。「1章 はじめに：バッドデータとは何か？」ではこんな風に整理されている。 泥臭い実務のためのアドバイス 2章 気のせいかな。このデータ、何かおかしくないか？ 3章 機械ではなく人間が使うことを意図したデータ 4章 プレーンテキストに潜むバッドデータ 5章 Webにあるデータの（再）構成 予期せぬことをするデータ 6章 オンラインレビューから嘘つきと混乱した人を発見する 9章 データと現実が一致しないとき アプローチ 8章 血と汗と尿 7章 バッドデータは起立して 10章 バイアスとエラーの源 11章 最善は善の敵、バッドデータは本当にバッドなのか？ データストレージとインフラ 13章 Crouching Table, Hidden Network 14章 クラウドコンピューティングの神話 12章 ファイルにこだわる データのビジネス面 16章 機械学習の専門家の手なづけ方 15章 データサイエンティストのダークサイド データポリシー 17章 データ追跡可能性 18章 ソーシャルメディア：消去可能インク？ 19章 データ品質分析の解明：データが十分良いときを知る 面白かったのは、2～4章と、10, 11章。バッドデータしかないときにどう取り組むか、先人の知恵に学びたい。特に「11章 最善は善の敵、バッドデータは本当にバッドなのか？」が示すバッドデータへの見方はすぐにでも。 データに基づかない判断より、不完全なデータに基づいた判断の方が良いのです。 バッドデータからだって分かることがあるんだから。