見出し画像

（学習ノート）JSTQB アジャイルソフトウェア担当者1.2 アジャイルアプローチの特徴

つとむ QAエンジニア

はじめに

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

アジャイルソフトウェア開発のアプローチ

シラバスでは、代表的な三つのアジャイルアプローチを紹介。

XP（エクストリームプログラミング）

  • 5つの価値を重視

    • コミュニケーション

    • シンプリシティ

    • フィードバック

    • 勇気およびリスペクト

  • 主要なプラクティス

    • 全員同席

    • チーム全体

    • 情報満載のワークスペース

    • いきいきとした仕事

    • ペアプログラミング

    • ストーリー

    • 週次サイクル

    • 四半期サイクル

    • ゆとり

    • 10分ビルド

    • 継続的インテグレーション

    • テストファーストプログラミング

    • インクリメンタルな設計

スクラム

  • 構成要素

    • スプリント

      • 固定期間（通常 2～4 週間）のイテレーションに分割する

    • プロダクトインクリメント

      • 潜在的にリリース可能／出荷可能なプロダクト

      • スプリント毎に作られる

    • プロダクトバックログ

      • 計画済みのプロダクトアイテムの優先度付けされたリスト

      • リファインメントを通して進化、洗練されていく

    • スプリントバックログ

      • 各スプリントの開始時に、プロダクトバックログから優先度の高い順に、スクラムチームが選択したアイテムのセット

      • プル型（＞プッシュ型）

    • 完了（done）の定義

      • スプリントが完了したと見なす条件

        • 定義する理由

          • 各スプリントの終了時に潜在的にリリース可能なプロダクトが確実に存在するようにするため

        • 例

          • コードレビューが実施済み

          • 機能テストに合格

          • 単体テスト合格

          • 統合テストに合格

          • リグレッションテストが作成され合格している

          • テスト環境にデプロイされている

          • POはユーザーストーリーの完了を確認している

    • 透明性

      • デイリースクラムと呼ばれる日次のミーティングにおいて、スプリントのステータスを報告し、更新する。

        • 効果）

          • スプリントの内容と進捗（テスト結果を含む）が、チーム、 マネジメント層および全ての関係者に明らかになる。

  • 定義された役割

    • スクラムでは３つの役割が定義されている。

      • スクラムマスター

        • スクラムのプラクティスと規則が実行されて遵守されていることを確認する

        • チームがスクラムの実践と規則を遵守することを妨げるあらゆる違反、リソースの問題、またはその他の障害を解決する

        • チームリードではなくコーチである

      • プロダクトオーナー

        • 顧客を代表し、プロダクトバックログの生成、保守および優先度付けを行う。

        • チームリードではない

      • 開発チーム

  • XP（エクストリームプログラミング）との違い

    • 特定のソフトウェア開発技法（テストファーストプログラミングなど）を強制しない

カンバン

  • 目的

    • 付加価値連鎖の中で仕事の流れを可視化し、最適化すること

  • カンバンで用いられる手法

    • カンバンボード

      • マネジメント対象の価値の連鎖を可視化できる

      • 複数の列（ステージ）で構成されたボードとタスクが書かれたカードを使用して、タスクの進捗にしたがって、そのカードを左から右に移動させ、進捗状況を可視化する

        • 例 ステージの分け方：「TODO」「WIP」「DONE」

    • 仕掛り制限

      • 並行して実行するタスクの総数を厳密に制限すること

    • リードタイム

      • タスクの継続的フローを最適化し、理想的なバリューストリームを目指す

  • スクラムとの違い

    • イテレーションまたはスプリントは必須ではない

    • 成果物をイテレーションまたはスプリントの単位ではなく、アイテム単位でリリースする

      • ⇨ できたものから順にリリースする（Just in time）

共同でのユーザストーリー作成

ユーザストーリーとは

  • 開発者、テスト担当者およびビジネス代表者の視点から、要件を捉えるために記述される

  • 要件の共有、詳細化は、頻繁な非公式レビューを通して行われる。

ユーザストーリー作成の技法

  • ブレインストーミング

  • マインドマップ

  • INVEST技法（ユーザストーリーを下記の観点で評価する）

    • 観点

      • 独立している

      • 調整可能である

      • 価値を提供する

      • 見積もり可能である

      • 小さい

      • テスト可能である

ユーザストーリーを構成するもの

  • カード

    • ユーザストーリーを記述するメモ

    • カードに記述される内容

      • 要件

      • 要件の重要度

      • 期待される開発～テストの期間

      • 受け入れ基準

        • ストーリーが完了（done）したことを確認するために使用

  • 対話

    • ソフトウェアの使用方法を説明し、文書化または口頭で行われる

    • リリース計画フェーズで開始され、開発中も継続する

  • 確認

    • ユーザストーリーに記述する受け入れ基準を用いて「確認」する

      • 目的：ストーリーが完了したことを確認するため

      • 確認内容：「正常系テスト」、「異常系テスト」が含まれる

      • 確認者：開発者、品質特性を重点的に確認する専門家

ふりかえり

概要

  • 各イテレーションの最後に行われるミーティング

    • 成功したこと、改善可能な点とそのアクションを議論する

      • 議論するテーマ

        • プロセス

          • テスト効率

          • テスト生産性

          • テストケース品質 etc

        • 人・組織

        • 人間関係

        • ツール

ポイント

  • 定期的に開催する
    → 自己組織化と継続的改善につながる

  • 血管の根本原因分析を行う
    → テストと開発の改善を促進できる

  • 改善はイテレーションごとに２～３個とする
    → 継続的な改善を一定のペースで維持できる

継続的インテグレーション

プロセス

コーディング、デバッグおよび共有ソースコードリポジトリへの チェックインに続く、自動化された活動から構成される

継続的インテグレーションのメリット

継続的インテグレーションのデメリット

継続的インテグレーションに含まれる自動回帰テスト

良い自動回帰テストとは
以前のイテレーションでデリバリーされたユーザストーリーを含む、可能な 限り多くの機能をカバーする

自動回帰テストのメリット

  • 大規模な統合システムの構築およびテストが容易になる

  • 新しいフィーチャと実装された 変更に対する手動テストおよび欠陥の修正の確認テストに集中できる

リリース計画とイテレーション計画

リリース計画とイテレーション計画の違い

各計画作成時の考慮事項

  • テストのスコープ、スコープ内の各エリアに対するテストの深さ

  • テストのゴールおよびこれらの判断の理由

  • テスト活動を実行するチームメンバ

  • 必要なテスト環境とテストデータ

  • 機能および非機能のテスト活動のタイミング、順序付け、依存関係

    • 例）

      • 回帰テストを実行する頻度

      • フィーチャと他のフィーチャまたはテストデータとの依存関係

      • 開発活動とテスト活動の依存関係

  • プロジェクトリスクおよび品質リスクへの対応

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