徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第７弾。
SDLCモデルに共通するテスト活動
ソフトウェア開発ライフサイクル（SDLC）のモデルが異なれば、テストに対応するアプローチも異なる。
ただし、以下のような特徴はモデルが異なっても共通するテスト活動である。
- 開発活動とテスト活動はペア：各開発活動に対してテスト活動がある。
- テストレベルごとに目的がある：各テストレベルには、そのレベル特有の目的がある。
- 開発活動ごとにテスト分析・設計を行う：各テストレベルのテスト分析や設計は、対応する開発活動の間に開始する。
- テスト担当者がレビュー関与：テスト担当者は、要件定義や設計の討議に参加し、作業成果物のレビューに関与する。
- シフトレフト：テスト活動はライフサイクルの早い段階に開始する。
参考：SDLCについて
シーケンシャル開発モデルとアジャイル開発モデル
シーケンシャル開発モデル
ウォーターフォール開発モデルやV字モデルがある。
ウォーターフォール開発モデル
要件定義や基本設計などの各フェーズが、直前のフェーズの完了とともに始まる。このモデルは水が上流から下流へ流れることに由来しており、原則的に逆流（後戻り）しないという前提でプロジェクトが進む。
しかし、基本設計を行なっている最中に要件定義の漏れに気づいてフィードバックをするなどはよくあることで、こうした後戻りがある場合は早めに行う方が修正作業は楽になる。工程が下流になるほど、上流工程に戻るのは大変になる。
このモデルにおけるコンポーネントテストや統合テスト、システムテスト、受け入れテストという4つのテストレベルは、開発活動（要件定義〜開発）が全て完了した後に実行する。
V字モデル
ウォーターフォール開発モデルをV字形に並び替えたものである。
並び変わっているが、各フェーズをシーケンシャルに順次実行するのは変わらない。
テストベースとテストのトレーサビリティを明確にする効果があるモデル。
具体的には、詳細設計の記述内容をコンポーネントテストで検証し、基本設計の記述内容は統合テスト、要件定義の記述内容はシステムテスト、要求分析の記述内容は受け入れテストで検証することになる。
このように対比させると、テスト担当者が開発フェーズのレビューに関与しやすくなる。例えば、システムテスト実す予定の担当者が、要件定義のミーティングやレビューに参加するという構図がわかりやすくなる。
画像引用元：https://biz.techvan.co.jp/tech-quality/quality-blog/000221.html
アジャイル開発モデル
インクリメンタル開発モデルとイテレーティブ開発モデルがある。
インクリメンタル開発モデル
図のように、システム全体を複数の機能（A,B,C,D）に分割に、機能単位ごとに要件定義→設計→開発→テストというイテレーションを回して完成した部分から順次リリースし、ソフトウェアフィーチャーを徐々に増加していくモデル。機能単位の大きさは手法によって大小様々である。
参考：リーン開発とは
無駄なものを開発しないという新しい開発手法。リーン（lean）とは「脂肪がない」という意味の英単語。
従来は、必要と思われる機能を全てを最初に設計・開発してから一括リリースすることが普通だったが、実際に顧客が必要としていない機能も含まれることも多かった。
リーン開発は、絶対必要と思われる機能のみを開発してリリースし、顧客の反応やニーズをフィードバックして次に必要とわかった機能を追加してリリースしていく。
リーン開発は顧客開発とも呼ばれている。最近流行りらしい。
イテレーティブ開発モデル
図のように、システム全体の機能別ではなく、一定の開発サイクル（イテレーション）で順次切り出し、イテレーション単位で要件定義→設計→開発→テストを行なってリリースする。
以下の2点がインクリメンタル開発モデルと異なる。
① イテレーションの大きさ（期間）が一定
スプリントプラニングで次のイテレーションにどのフィーチャーを開発するかを決め、同じテンポ（サイクル）
で開発を繰り返す。インクリメンタル開発モデルは、機能の塊単位でリリースするのに対し、イテレーティブ開発モデルではイテレーションに入る範囲だけを開発するのが特徴。
スプリントってなんぞ
開発手法によっては、反復（イテレーション）のことをスプリントと呼ぶ。
各スプリントの最初に、スプリントの進め方やゴール、必要な作業を計画することをスプリントプランニングという。
イテレーションとスプリントは開発手法による呼び方の違いだけで、内容はほぼ同じ。
② リリースが本番運用とは限らない
イテレーティブ開発モデルは、あくまでもイテレーティブ（反復型）で開発することを重視した開発モデルで、自分たちが作っているものを逐次確認し、より良いものを作ろうというアプローチである。インクリメンタル開発と違って、必ずしもその都度本番リリースして顧客のフィードバックをもらうとは限らず、本番リリースが最後になることもある。
イテレーティブ開発モデルの主な手法
イテレーティブ開発モデルの具体例として4つの手法を示す。
| 手法 | 主な特徴 |
|---|---|
| ラショナル統一プロセス（RUP） | 各イテレーションは他と比べて長期になる傾向があり、フィーチャーの増分は、関連するフィーチャーで構成するいくつかのグループなど、期間に対応して大きくなる傾向がある。 |
| スクラム | 各イテレーションは他と比べて短期になる傾向にあり、フィーチャーの増分は、わずかな機能強化、及び/またはいくつか新しいフィーチャーなど、小さくなる傾向がある。 |
| カンバン | イテレーションの期間の長さが固定されているかどうかに関係なく実装できるので、完了時に単一の機能強化やフィーチャーをリリースすることも、複数のフィーチャーを一括してリリースすることもできる。 |
| スパイラル | 増分を試行しながら追加する。増分は、後続の開発作業で大幅に作り直すことも破棄することもある。 |
ラショナル統一プロセス（RUP）
ラショナル統一プロセス（Rational Unifined Process）は、IBM Rationalという製品が提供する手法である。ウォータフォールの要素を取り入れた反復型プロセスモデルで、短期間のウォーターフォールを繰り返しながら、システムの機能を段階的に高めていく。
1つの開発で1つ以上のユースケースを実装するユースケース駆動アプローチという特徴を持つ。
インクリメンタル開発モデルとにているが、開発のたびに本番リリースするわけではないため、イテレーティブ開発モデル側に分類している。
ユースケースとは、システムの利用シーンをユーザー目線で図解したもの
特徴
RUPは、以下の4つのフェーズを行なっている。
- 方向づけ（inception） ： システムの方向性を定義して無駄な投資をするリスクを減らす。技術的になリスクの高いユースケースの実装を繰り返し、アーキテクチャーの確立を行う。
- 推敲（elaboration） ： 目指す方向の技術的な裏付けを行う。開発を進める上で障壁となりそうな重大なリスクに対応するための開発を繰り返す。
- 作成（construction） ： 大きなリスクが解消されたらシステムの開発を行う。
- 移行（transition） ： 本番環境の運用に移行する。
リスクの低減作業を優先することで、プロジェクトの最後になって大きなリスクに直面するトラブルを防ぐリスク駆動アプローチにもなっている。
ユースケース図
RUPでは、ユーザーがシステムを使って特定の目的を達成するまでのユーザーとシステムのやり取りのこと。
この図を使えば、そのシステムを使ったことがない人でも、どのような機能を作る必要があるかをさっと理解することができる。
スクラム
アジャイル開発で最も使われている手法。イテレーション期間を固定（1週間など）して、その期間で開発するフィーチャーをイテレーションで都度決めていく探索型の開発スタイル。
カンバン
タスクボード（カンバンボード）にタスクを貼って、タスクの進捗状況（ToDo, Doing, Doneなど）を可視化、共有する手法。
イテレーションの期間やタスクの大きさに関係なく、タスク単位の進捗をシンプルに把握できる簡便さが特徴で、開発現場の作業管理でよく使われている。
（開発モデルというよりも進捗管理の手法として捉えた方が良い）
スパイラル
設計とプロトタイピングを繰り返して開発していく手法。RUPと同じように重要な機能から順に作り、スクラムと同じように反復開発のたびに次に開発するフィーチャーを決めていく。
自由で探索的にプロトタイプ（試作品）を作り、クライアントとすり合わせをしながら開発を進める手法。
継続的〇〇
反復型開発なので、テストレベルの重複や繰り返しが発生することも多くなる。そのため、繰り返されるテストを自動化するためにことの後説明する継続的デリバリーや継続的デプロイなどのリリース手法を使用することも多い。
いずれもシステムが段階的に成長する開発手法なので、システムが成長するにつれてリグレッションテストの重要性が増大する。
ビルドとデリバリーとデプロイ
それぞれの役割は以下のように図示される。
各用語は以下のように定義している。
| 用語 | 意味 |
|---|---|
| ビルド（build）：作成 | 開発担当者が変更したソースコードをもとに、実行可能ファイルや配布パッケージを作成する処理 |
| デリバリー（delivery）：配信 | ビルドされたプログラムをテスト環境（ステージング環境）や本番環境に配慮する処理 |
| デプロイ（deploy）：配備 | デリバリーされたプログラムを利用者（テスト担当者やユーザー）が利用できる状態にする処理 |
継続的インテグレーション
継続的インテグレーション（Continuous Integretion : CI）とは、コード変更をコミット（変更を確定する処理）してからビルドまでの処理を自動化するものである。開発担当者がソースコードを変更してコミットが発生すると、自動的に変更が検証され、マスターブランチ（本体のコード）に追加され、ビルドアーティファクト（ビルドによって生成されるファイル）にパッケージされる。
一言で言うと「開発したものがデリバリー可能な状態になるまでの処理を自動的に行う」ということ。
継続的デリバリー
継続的デリバリー（Continuous Delivery : CD）とは、開発環境にデプロイされたパッケージをテスト環境（ステージング環境）や本番環境に配信する処理を自動化する。新しいビルドアーティファクトが作られると、自動的に目的の環境に配置される。
継続的インテグレーションと継続的デリバリーを連続して行うことをCI/CDという。
コミットが発生すると自動的にビルドされ、目的の環境にデリバリーされるまでが自動化される。ただし、単に継続的デリバリーという場合、継続的インテグレーションも含む一連のプロセスの自動化を指すのが普通である。
継続的デプロイ
本番環境へのデプロイまでを自動で行うのが継続的デプロイ（Continuous Deploy : CD）である。継続的デプロイは全自動のため、開発担当者がコミットしたものが自動的に本番環境に適用される。
まとめると以下のようになる。
- 継続的インテグレーション : コミットからビルドまでを自動化
- 継続的デリバリー : コミットからビルド、デリバリーまで自動化
- 継続的デプロイ : コミットからビルド、デリバリー、本番環境へのデプロイまでの完全自動化
DevOpsについて
DevOps（デブ・オプス）とは、開発チームと運用チームが連携・協力して、スピーディに良いものを開発し続ける仕組みのことである。
以下の画像のように表現されることが多いが、
左のDEVはdevelopの略で、開発チームの作業である。計画・設計（plan）したものをプログラミング（code）し、ビルド（build）してテスト（test）するまでが開発チームの一連の作業になる。
右側のOPSはoperationsの略で、運用チームの作業である。デリバリー（release）されたものをデプロイ（deploy）し、運用（operate）に入李、運用過程で出てきた不具合や要望を監視（monitor）して、修正要求や改善要望としてキア初チームにフィードバックする。
（個人的な見解では、このループは一見単純そうに見えるが、根幹となる価値観のずれや相互に発生するコミュニケーションの齟齬が生まれることが多いため、一筋縄ではいかないモデルであると思っている）
次回