「実践アジャイルテスト」を読んだ感想
実践アジャイルテストを読んだのでその感想を書きます。余談ですが、この本は絶版らしく*1図書館で借りて読みました。 www.shoeisha.co.jp
なぜ読んだか
アジャイルで進めているプロダクトに対して、どのように品質と向き合うかということを知りたかったこと、そして「Agile Testing Condensed Japanese Edition」で語られている部分について、より詳細な部分を知りたくて読んでみました。
「Agile Testing Condensed Japanese Edition」を読んだ感想 - 徒然なるままに
学びになったこと
アジャイルテストの4象限
第1象限(チームを支援する技術面のテスト)
- 単体テストやコンポーネントテストを指す
- 活動の目的は、内部品質を最も高めること
- 支援する手段としてのTDD
- テストコードがあることのメリット一例は、バグ探しの時間が減ること、テスタビリティの高いプロダクションコードができる、迅速なフィードバックをもたらす。
第2象限(チームを支援するビジネス面のテスト)
- 第1象限より高いレベル(おそらく抽象度が高いとか、大まかな概要という意味)が対象
- 顧客チームから提供される例からテストが導き出される。
- ビジネス面のテスト
- ビジネス用語で記述される。
- 顧客も参加するテスト
- 顧客が読んで理解できるように書く
- 外部品質を検証するためのテスト
- 自動と手動でのテスト
第3象限(製品を批評するビジネス面のテスト)
- 製品を批評するテスト
- 探索的テスト
- デモ
- 人間の知性や経験、本能に依存するため、この部分のテスト自動化は難しい。
- テスト準備、テストデータの作成、その他繰り返し作業などは自動化できる。
- 第1、第2象限を自動化しておくことで、第3象限のテストを行なえる時間を得れる。
第4象限(技術面のテストを使った製品の批評)
- ～性のテスト
- 非機能テストについて考える時間はリリース計画時やテーマ計画時
テスト自動化について
テスト自動化のメリット
- 手動でのテストだと間違いを誘発しやすいので、それを防ぐことができる。
- リグレッションテストによって意図しない振る舞いの変化に気付けるため、セーフティネットとしての役割を持つ。
- 早く、頻繁にフィードバックを与えることができる。
- 変更が加えられるまでは自動テストは成功し続ける必要がある。
- もし自動テストが予期せずに失敗する場合は退化している可能性がある。それをいち早く開発者に伝えることができる。
- 退屈な手作業を減らすことで、探索的テストやユーザー受け入れテストなど重要な仕事のための時間を捻出できる。
- 文書化
- システムが実際にどのように動作するかを表した生きた資料
- メンテナンスしないとテストは失敗する。「グリーン」に保つために自動テストを更新し続ける必要がある。
- 静的な文書との最大の違い。失敗することで、資料を特徴更新する必要があるタイミングを知れる。
単体テスト・コンポーネントテストでの特徴
- すべてのテストタイプの基礎
- アジャイル開発ではこのレイヤーに可能な限り多くのテスト実施することで、ROIの向上が期待できる。
- テスターがTDDと単体テストの自動化を習得するにつれて、この層は成長し始める。
受け入れテスト(APIテスト)
GUIテスト
- (AIテスト自動化ツールが無い時代の本なので、そこは留意する必要あり)
- 保守工数が結構かかるため、一般的には低いROIとなる。
- HTMLの要素を変更すると失敗となるケースがある。
- 常に製品を批評するために記述される。
- 重要なフィードバックをもたらすが、実行に時間がかかる。そのためなるべくこの層のテスト数を減らしたい。
- GUIテストの自動化に開発者が携わることは、システムの全体像の理解を深めることに役立つ。
- やり過ぎてすべての可能なシステムを自動化するようなことはしないように。
CIの重要性
- CI＞単体テスト自動化＞APIテスト＞E2Eテストの順番に自動化を検討すべき。
高速で実行される継続的インテグレーションとビルドプロセスは、あらゆる自動化の取り組みに絶大なROIをもたらします。これは、あらゆるチームが自動化する必要のある、最初に行うべきことです。それが適所にある時には、チームは自動化されたテストから迅速なフィードバック方法を得ることができます。
自動化しないほうが良いテスト
- ユーザビリティテスト
- 探索的テスト
- 絶対に失敗しないテスト
- 要求を満たすために1つの実装の方法しかない場合など
- リスク分析して、仮に変更が発生しても影響が少ないもの
- 1回限りのテスト
検討時に必要なこと
- 「なぜ自動化が必要か？」「どんなゴールを達成したいのか？」「どこが最大の痛みか？」「もっとも退屈な領域は何か？」
- 影響度、将来の変更可能性、繰り返し実施する必要性があるか
テストを記述するための戦略
- テストを成功し続ける
- テストが成功した後は、要求が変更されない限り失敗すべきではない。
- 変更を検出するための役割があるので、要求の変更についてテストで忘れられた部分があるのであれば、失敗することを期待している。その後成功させるように変化させる必要がある。
- どんな時でも、継続的インテグレーションやビルドプロセスにおいてテストが失敗した時は、チームの最優先事項(致命的な稼働環境での問題を除き)はビルドプロセスを再び通過させること。
チーム全体のアプローチ
- テスターがプログラマと組になり、より良いテストを記述できるように支援する。
- 順番にテストピラミッドのレンガの基礎層を固めていく。
- テストは開発を推進するため、チーム全体が常に最大のテスタビリティを求め、テストピラミッドは正しい形に成長していくことができる。
自動化の評価
- 自動化の労力の見返りを評価する時は、ツールが技術チームと顧客チームの共同作業を促進したかといった、はっきりとしない側面を考慮する。
- テストを記述することの第一の理由は、開発を推進することの助け。自動化された受入テストを記述する過程が、ビジネス要求の完璧な理解をもたらすのであれば、後でテストが1つのリグレッションのバグを見つけることがなくても、それは十分な見返りとなる。
要求を引き出すための質問の例
- このストーリーは問題を解決しますか?
- そうだとすると、私たちが解決しようとしている問題は何ですか?
- 問題を解決しないソリューションを実装することができますか?
- このストーリーは、どのように価値をビジネスにもたらしますか?
- この機能のエンドユーザーは誰ですか?
- 彼らはどのような価値を得るでしょうか?
- ユーザーがこの機能を利用する直前あるいは直後にすべきことは何ですか?
- どのようにして、このストーリーが達成されたかを知ることができますか?
- 起こり得る最悪なことはなんですか?起こり得る最も良いことは何ですか?
開発者との協調（共同作業）
- ペアテスト
- 開発中のGUIを見せてもらう
- 顧客または顧客の代理に、コーディングが始まる前にテストケースをレビューしてもらう。
- チーム全体は新しい機能を手動でテストするのと同様、手動リグレッションテストを実施する時間を計画する。
- アプリケーションのテスト自動化ができるように、どのように設計するかを学ぶためのモチベーションを提供できるため。
チーム運営
独立した品質保証チーム
- 独立しないことによるデメリットの1つは、テスターがあまりにも開発者と近くで作業をした場合、みな開発者のように考え始め、 顧客の視点を失ってしまう。
- アジャイルチームのテスターは、顧客の代理としての役割も必要。
- テスターと開発者の正しい比率はないので、比率にこだわるよりも必要としているテストスキルを評価する必要がある。
チームメンバー全員が平等
- あなたがテスターで、ミーティングに呼ばれることが忘れられているとしたら、自分から参加する。
- 技術に強くないテスターは、設計の打ち合わせでは、場違いで気後れするかもしれないが、たまには技術屋が思いつかないような鋭い質問をすることもある。
- 自動化の問題を抱えて困っているテスターなら、チームメンバーに助けを求める勇気を持つ。
- マネージャーやチームリーダーならば、こういう協力が得られるようにし、もし得られないのであればチームに問題提起する。
まだわかっていないこと
- テスト自動化について、どうやったら有効なメトリクスが得られるか知りたいですが、まだわからず。
- TDDのデメリットは何なのか。テストコードを書く工数がかかることとか？
感想
ページ数が多く読むのが大変でした...その分学びになる点も多かったです！自動化の部分に関心が強いので、自動化がらみの内容が多くなってしまいました...でも、アジャイルで品質向上のためにどう向き合うかという点を、「Agile Testing Condensed Japanese Edition」以上に知ることができました。
今回学びとなったことは多いので、ある程度時間が経ってから見直すことでより理解を深めようと思います！
*1:絶版だというのは図書館で借りた後に初めて知りました
