『実践アジャイルテスト』第18章のコメント・疑問

第18章 コーディングとテスト (P. 401～)

18.1 開発を推進する (P.404～)

18.1.1 簡単な事から始める (P.404～)

18.1.2 複雑さを加える (P.405～)

18.1.3 リスクを評価する (P.405～)

「そのストーリーに関連するすべての潜在的なリスクをリストすることから始める」ウォーターフォール型では工程をやり直すチャンスがないのでリスクを正視することが難しい。繰り返し型だからこそリスクを適正に扱えるのかも、と思いました。（ヤマモト）

18.1.4 コーディングとテストを同時進行させる (P.407～)

18.1.5 組み合わせを認識する (P.408～)

18.1.6 3人の力 (P.408～)

18.1.7 1つのストーリーに集中する (P.409～)

18.2 製品を批評するテスト (P.410～)

P.410 「あまりROIの高くない高価なテストを他のストーリーを入れないでください。」訳がちょっと変。 (You&I)

18.3 プログラマとの共同作業 (P.411～)

18.3.1 ペアテスト (P.411～)

「ペアテスト」あまり聞いた事のない用語ですね。 (You&I)

18.3.2 「見せて下さい」 (P.411～)

18.4 顧客に話しかける (P.412～)

18.4.1 顧客に見せる (P.412～)

18.4.2 ビジネスを理解する (P.413～)

18.5 テストのタスクを完了する (P.413～)

18.6 バグに対処する (P.414～)

欠陥追跡システム(DTS：Defect Tracking System) 第5章でも出てきました。 (You&I)

18.6.1 それは障害か、機能か？ (P.415～)

18.6.2 技術的な負債 (P.415～)

「メンテナンスに時間がかかる」確かに掛かります。 (You&I)

18.6.3 ゼロバグの許容誤差 (P.416～)

「ウォーターフォールの罠」工程待ちになってしまい、テストが進まない状態になってしまう事でしょうか。

テストに限らず設計が進まずに実装が進まない事も考えられますね。

前の章(P.390)では「ミニウォーターフォール」と表記されているのと同じ意味合いかと。 (You&I)

「未解決のバグを持ったリリース」これが許容されるかどうか。納入後に大量にバグが出た時はそういう事をやりましたが。 (You&I)

18.7 選択のすべて (P.417～)

18.7.1 どのバグを記録するか決める (P.417～)

「すべてのバグを記録する必要はありません」ほう。（ヤマモト）

「すぐに修正できるバグは記録しない」「すぐに修正できなバグは記録する」うーん、そのような方針はプログラマとしてはありがたいですが、統計的な分析ができなくなってしまいますよね？（ヤマモト）

「対応されることは稀であるため、時間の無駄です。」問題があるなら記録としては残しておきたいです。例えばOSS等のBTSでも起草はされたけど処置なし状態というのはあとあと同じ問題で調べる時にとても参考になる情報だと思います。 (You&I)

18.7.2 いつバグを修正するか決める (P.419～)

18.7.3 バグを記録する媒体を決める (P.420～)

P.421「カードは実態のあるものです。」ここでは「実体」が正しいような。 (You&I)

18.7.4 バグへの対処の代替案と提案 (P.421～)

P.422 「「バグ」が機能の欠落なのであれば、そのバグのカードを書き、ストーリーとして計画することを選択」確かに。ストーリーとすることで影響範囲を明確にする意図もあるかなと。 (You&I)

P.424～425 「青、緑、赤のステッカー」この説明の部分こそ、写真が欲しい。 (You&I)

18.7.5 シンプルなことから始める (P.425～)

物事・問題をシンプルに、チームも必要最小限でシンプルに。正しくアジャイルといった感じ。 (You&I)

18.8 コミュニケーションを促進する (P.426～)

18.8.1 テスターがコミュニケーションを促進する (P.426～)

18.8.2 分散したチーム (P.428～)

18.9 リグレッションテスト (P.429～)

18.9.1 ビルドを「緑」に保つ (P.429～)

18.9.2 ビルドを速くする (P.430～)

18.9.3 リグレッション環境を作る (P.431～)

「（リグレッションテストは）開発を推進するものではなく、（中略）唯一の目的は、予期せぬ変化や、システムの副作用を見つけること」。言葉尻になってしまうかもしれませんが、リグレッションを検出できる安心感は開発の推進そのものではないでしょうか？システムの副作用というのもよく分からない。変更の副作用なら分かるけど。（ヤマモト）

18.9.4 大きな視野を持つ (P.431～)

18.10 リソース (P.431～)

18.11 反復指標 (P.432～)

18.11.1 進捗を測定する (P.432～)

18.11.2 欠陥指標 (P.433～)

18.12 まとめ (P.436～)

「コーディングとテストは、反復の間プロセスの一部である。」？？？「反復の間、プロセスの一部である。」としてもちょっと意味が通じないような。 (You&I)

テストの流れは：タスクのテスト ＞ ストーリーのテスト ＞ リグレッションテスト > UAT (You&I)