見出し画像

(学習ノート)JSTQB アジャイルソフトウェア担当者 2.1 テストにおける従来型アプローチとアジャイルアプローチの違い

はじめに

アジャイルテスト担当者のシラバスを読んで、重要なところを引用し、感想をつけた学習ノートをまとめました。この記事は「2.1 テストにおける従来型アプローチとアジャイルアプローチの違い」が対象です。

アジャイルライフサイクルのテスト活動

イテレーションごとのテスト活動

イテレーションごとに、ビジネスステークホルダに価値あるフィーチャ(動くソフトウェア)をデリバリーする

例外的なイテレーション

硬化(ハードニング)イテレーション/
安定化(スタビライゼーション)イテレーション
→残存する欠陥や他の形態の技術的負債を解決するためのイテレーション

バグフィックスファースト
(説明)
前のイテレーションで解決されていない欠陥を次のイテレーションの開始
時にそのイテレーションのバックログとして対処する。
(注意事項)
イテレーションで完了させなければならない作業量の合計が不明となり、残りのフィーチャを完了できる 時期を見積もることがさらに困難になる

アジャイルライフサイクルで用いられるプラクティス

リスクベースドテスト

リスク分析はリリース計画策定時とイテレーション計画策定時に行う。
それぞれのタイミングでのリスク分析は以下のような差異がある。

  • リリース計画時

    • テスト担当者が概要レベルのリスク分析を行う

  • イテレーション計画時

    • 各イテレーションに付随する特定の品質リスクを識別し、評価する

    • 以下に影響をおよぼす

      • 開発の順序

      • フィーチャのテスト優先度と詳細度

      • 各フィーチャで必要なテスト活動の見積もり

テスト自動化

  • すべてのテストレベルで自動化を行う

テストレベルごとの自動テスト担当領域

→アジャイルチームでは、テスト自動化経験があるテスト担当者が好まれる

  • 手動テストはソフトウェア攻撃、探索的テスト、エラー推測などの”経験ベース”および”欠陥ベース”の技法を使用して行うことが多い

プロジェクト成果物

成果物の特徴

アジャイルテスト担当者に直接関連するプロジェクト成果物は、一般的に次の三つに分類される。分類ごとの成果物とその特徴は下表の通り。

考慮事項

  • ドキュメントを減らして効率を上げることと、ビジネス、テスト、開発およびメンテナンスの各活動をサポートするためのドキュメントを十分に提供することをうまく両立させる。

  • 法規制がある、安全性が強く求められる、または非常に複雑であるプロジプロダクトを対象とするアジャイル開発では、成果物をさらに形式化する必要がある。

アジャイル開発のテストレベル

テストレベルとは

・ 論理的に関連性があるテスト活動
・ テスト対象の成熟度または完成度と関連づけられる

アジャイルライフサイクルにおけるテストレベル

ユーザーストーリーに関わるテスト
アジャイルライフサイクルでは、イテレーション計画で策定したユーザーストーリー毎にテスト活動を行う。イテレーションの特定のタイミングで受け入れテストを実施する場合もある。

イテレーション全体を通して行われるテスト

  • イテレーション全体を通して、回帰テストプロセスが実行される。

    • 回帰テストプロセスで実行されるテスト
      ※ 以前のイテレーションで実装したテストを含む

      • ユニットテスト

      • フィーチャー検証テスト

テストと構成管理

構成管理の対象と自動テスト

自動化されたビルドとテストのフレームワークを使用して、コードとユニットテストを継続的に構成管理システムにチェックインする。(下図参照)

アジャイル開発とテストチームの独立性

アジャイルチームとテストチームの関係性について、チームの独立性とテストチームが担う役割の観点から3つの選択肢がある。それぞれのメリットとデメリットは下表の通りである。テストチームを立ち上げる際には、独立性を維持するための選択肢を考慮するとよい。

この記事が気に入ったらサポートをしてみませんか?