実践アジャイルテスト
この投稿は インタープリズムはAdvent Calendarを愛しています。世界中のだれよりも。 Advent Calendar 2017の6日目 の記事です。
背景など
今年から現場が変わり、初めてアジャイルを経験しました。 初めてのことも多くて失敗することもありましたが、なんとか生き延びることができました…
私たちのチームでは1週間で区切り、開発を行っていました。 小さい機能改善や不具合の修正を毎週リリースをした期間などもあり生産性が高く、 モチベーションも十分で開発を進めることができました。 (※毎週リリースと言っても並行で開発しているので開発期間は1週間ではない)
しかし、、、、
アジャイルを通して開発を進めていくにしたがって、
「この製品の品質は大丈夫なんだろうか…」
と不安がどんどん大きくなっていきました。 そんなときに「実践アジャイルテスト」という本に出会いました
今回は備忘録として本の内容をまとめたいと思います!
前半は主に6章~12章のまとめになります。
アジャイルテストの4象限
テストをする理由や目的は様々あります。
「バグを見つけるため」、「コードの信頼性を確認するため」などなど
本書ではテストをする目的を4つの象限に分けます。
まず一つの軸は「ビジネス面のテスト」と「技術面のテスト」かどうかで分けられます。
もう一つの軸は「チームを支援する」か「製品を批評する」かどうかで分けられます。
※「批評」という言葉は否定的な言葉ではなく、称賛と改善のための提言を含む
第1象限(Q1)
- 主な目的はテスト駆動開発あるいはテスト駆動設計
- これらのテストによりシステムに意図しない変更が起きることを心配せずにコーディングができる
- 単体テストの最大の利点はフィードバックの速さ
→単体テストを実行する継続的インテグレーションやビルドプロセスは10分以内に終わらせるべきと考える
第2象限(Q2)
- 最も重要な目的の1つは、情報をできるだけ早く提供して迅速な問題解決を可能にすること
→そのため頻繁にテストを行わなければならないため自動化する必要がある - これらのテストを製品の外部品質の定義のために使う
- 最も重要なことは機能がどのように動くべきかの例を顧客に求めること
第3象限(Q3)
- ソフトウェアが期待にあっているか、あるいは競争相手に勝っているかをみるためのもの
→プログラマがビズネス面のテストをパスするコードを書いたとしても、顧客が欲しいものを提供しているとは限らない - 探索的テストはエンドユーザーがするのと同じように行うためテスターは想像能力を直観力を使う
→多くの重大な欠陥がこの過程で見つかることが多い - テスト準備、データ生成、繰り返し作業、あるいはワークフローを開始したいところまでなどは自動化可能
第4象限(Q4)
- パフォーマンスやセキュリティ要求などは実際の機能性より重要かもしれない
→例えばネット販売サイトでレスポンスが1分かかるとしたらお客は機能が充実していようと評価はしてくれない - これらのテストは機能テストより早く行われることさえある
結論
後半に続く!………かも