負荷試験/パフォーマンステストの勉強を始めます。

負荷試験/パフォーマンステストスキルを身につけるためには

唐突に社内プロダクトの負荷試験を実施せざるを得ない状況になったので、

負荷試験についての学習を急ピッチで進めています。

まずは『Amazon Web Services 負荷試験入門』という書籍を読み進めています。

せっかくなので、学習した内容についてはこのブログにアウトプット（というかほぼ自分の見直し用）として残していこうと思います。

今回は「負荷試験とは」という超基礎的な部分と、どうやって学んでいくのかの方向性を残しておこうと思います。

負荷試験とは

結論：極論＝可用性を担保するための手段の1つでしかない

負荷試験のPDCAサイクル

• PLAN：負荷試験計画の立案
• DO：負荷試験の準備及び実施
• CHECHK：計画時に建てた目標値と前提条件をクリアしたか、意味のある数字が取れたかの確認
• ACTION：負荷試験レポートの作成、またはシステムの改善、目標値や前提条件の見直しをして次のPDCAにつなげる

場合によっては要件や設計を見直したり、試験項目を新規追加することも必要となり、結果に応じて大きな変化が生じる。
なので上記PDCAをいきなり回していくのは労力だけがかかってしまう。
まずはDOに当たる実施部分を細かいチェックを行い、「DO」に絞ったPDCAを回していくと良い。

負荷試験担当者に必要な知識

• プロジェクト進行に関する知識
  • ビジネス要因等により負けることもあるが、それを避けられるかの判断・ピンチ時のリスクを適切に判断するための正しい知識や理解が必要
• IT知識
  • クラウドやWeb系システムに対する知識
  • システム評価に関わる数字の知識
  • 負荷試験進行に関する知識

現時点では、超ざっくりこんな感じのことをこういう感じで学んでいくんだな〜という雰囲気だけ掴めていればOKかなと思っています。

引き続き精進します。

【JSTQB AL TA】シラバス1.2 ソフトウェア開発ライフサイクルにおけるテストまとめ

テスト戦略で考慮すべき事項

テストアナリストは、テスト戦略を定義する際には、ソフトウェア開発ライフサイクル全体を考慮する必要があります。

プロジェクトにおいて採用されたソフトウェア開発ライフサイクルによって、テストアナリストの振る舞いが異なります。

具体的には、開発チーム内などにおける他関連組織に対して、どのような関与の仕方（程度・必要な時間・利用可能な情報・及び期待）をするかを検討する必要があります。

テストアナリストの他の関連組織との関わり方

テストアナリストは、テスト活動の一環として、プロジェクトを円滑に進めることを目的に、他の関連組織との関わり＝活動の提供が重要となります。

テストアナリストが把握しておくべき、活動の提供先・提供する業務内容は以下の通りです（シラバスからそのまま引用）。

提供先	活動内容
要求エンジニアリング及びマネジメント	要件レビューのフィードバック
プロジェクトマネジメント	スケジュールに対する入力
構成管理及びマネジメント	ビルド検証テストの結果、バージョンコントロールの情報
ソフトウェア開発	検出された欠陥の通知
ソフトウェアメンテナンス	欠陥レポート、欠陥除去効率、確認テスト
テクニカルサポート	正確に文書化した回避策及び既知の問題
テクニカルドキュメント作成	これらのドキュメントへの入力とドキュメントのテクニカルレビュー

上記の活動は、採用する開発ライフサイクルとの整合性を保つ必要があります。

以下は、シーケンシャルな開発ライフサイクルの場合で、V字モデルのテストプロセスのシステムテストについて記載した例です（シラバスからそのまま引用）。

1. プロジェクト計画と同時にシステムテスト計画を始め、テスト完了までテストモニタリングとテストコントロールを継続する。これは、プロジェクトをマネジメントする目的でテストアナリストが提供するスケジュールに影響する。
2. システムテストのテスト分析及びテスト設計は、システム要件仕様、システム及びアーキテクチャー(ハイレベル)設計仕様、及びコンポーネント(ローレベル)設計仕様などのドキュメントに沿って行う。
3. システムテスト環境の実装は、システム設計時に開始する場合があるものの、その大部分は、コーディングおよびコンポーネントテストと同時に開始するのが常であり、システムテストの実行開始数日前までシステムテスト実装への取り組みが続いてしまうことが多い。
4. システムテストの実行は、テストの開始基準を満たした(または必要に応じて免除された)ときにも始まる。これは最低でもコンポーネントテストと多くの場合はコンポーネント統合テストも終了基準を満たしていることを意味する。システムテストの実行は、システムテスト終了基準を満たすまで継続する。
5. システムテストの完了活動は、システムテスト終了基準を満たした後に実行する。

シーケンシャルならではのスケジュールリスク等によるシステムテスト遅延についての記載もあり、そのようなリスクを防ぐためにも、前工程からテスト計画を始め、モニタリングとコントロールを行い、開発ドキュメントを用いたテスト分析・テスト設計を実施しておくべきであると、シフトレフトの具体的アクションまで落とし込むことができています。

イテレーティブモデルやインクリメンタルモデルの場合は、テスト活動の順番を柔軟に変更したり、「テスト分析・設計・実装・実行」を実行する単位をイテレーションごとにするなどの工夫が必要となります。

もしアジャイルソフトウェア開発を採用する場合は、明確なプロセスや役割区分を設けずにプロジェクトを進行します。したがって、テストアナリストのタスクはチーム全体で行うものとされ、開発開始時点と同時にテストを開始する形でプロジェクトを進めていきます。

テストアナリストが関連組織と関わる上で意識すべきこと

以上のように、開発ライフサイクルに基づいたテストアナリストの関わり方の選択が重要であることは確かです。

しかし何よりも重要なのは、採用するソフトウェア開発ライフサイクルに関わらず、テストアナリストがプロジェクト全体において期待される「関与への期待度とタイミング」を理解することです。

事前に定義されたロールに固執することなく、採用された開発ライフサイクルへの活動と関与のタイミングを検討し、調整することによって、ソフトウェア品質に最大限貢献することができます。

【JSTQB AL】テストアナリストシラバス1.1 イントロダクションまとめ

テストアナリストが重点をおくべきテスト活動

ISTQB Foundation Levelシラバスにおいては、いわゆる「テスト活動全体のプロセス」として、以下の活動をテストプロセスとして定義し説明されています。

• テスト計画
• テストのモニタリング、及びコントロール
• テスト分析
• テスト設計
• テスト実装
• テスト実行
• テスト完了

しかしAdvanced Level Test Analystシラバスにおいては、より「テストアナリスト」の役割として関連性が強い活動の詳細説明に重点が置かれています。

特にテストアナリストが焦点を当てるべき領域として、適切なテストの決定・それらの設計/実装・及び実行が挙げられており、以下の活動に重点を置くべきとされています。

• テスト分析
• テスト設計
• テスト実装
• テスト実行

上記以外の活動についてはFoundation Levelの記載で十分適切に説明されているため、Advanced Level Test Analystシラバスにおいて更なる詳細解説は不要であると記載されています。