ユーザー要件: これは、単に当事者 A によって提示された要件として理解できます。当事者 A が存在しない場合、エンドユーザーが製品を使用するときに完了する必要があるタスクです。技術的な実装の詳細は含まれません。ユーザーのニーズは、ユーザーとのコミュニケーション、市場調査、または需要分析から取得されます。

ソフトウェア要件 (機能要件): ソフトウェアシステムの機能的な動作と操作の詳細な説明です。ソフトウェアシステムがどの機能と機能間の関連付けを提供するかを指定します。機能要件は通常、開発者やテスターが理解して実装できるように、ユースケース、機能仕様、または要件仕様の形式で記述されます。

テスターの深刻なニーズ: ユーザーのログインと登録ビジネスを例に挙げます。

ニーズを深く理解するにはどうすればよいでしょうか?

ニーズ検討会議を実施する

要件検討会議は、ソフトウェアシステムの要件を検討、議論、検証するためのソフトウェア開発およびテストプロセスにおける重要な活動です。通常、この会議には、要件アナリスト、開発者、テスター、プロジェクトマネージャー、その他の関係者など、プロジェクトチームの関連メンバーが参加します。

要件レビュー会議は、プロジェクトチームのコラボレーションと要件の合意形成の重要な部分であり、要件内の問題を発見して修正し、その後の開発およびテスト段階での変更とリスクを軽減するのに役立ちます。タイムリーな要件レビュー会議を通じて、ソフトウェア開発プロセスの効率と品質を向上させることができます。

2. テストケース

テストケースは、ソフトウェアシステムが期待される要件を満たしているかどうかを検証するために設計および実行される、テスト環境、期待される結果、操作手順、およびテストデータの集合です。ユースケースは「ケース」と呼ばれます

ブログシステムのログインビジネスを例に挙げます。

テスト環境: Windows システム + Chrome ブラウザ + ローカル

テストデータ: アカウント + パスワード

操作手順：口座番号を入力し、パスワードを入力して「ログイン」をクリックします。

期待される結果: ログイン成功、個人ブログページにジャンプ

期待される結果は実際の結果と同じであり、テストケースは成功したと見なされます

なぜテストケースがあるのでしょうか?

テスターの作業効率を向上させ、テスターの繰り返し作業を軽減します。

テストケースは再開自動テストの基礎です

3. バグとは

プログラムと仕様 (ソフトウェア要件) の不一致 (期待される結果 != 実行結果) は、仕様が存在し、正しい場合にのみバグとなります。

要件仕様書に記載されていない機能については、最終的にはユーザーの判断基準となります。エンドユーザーが合理的に期待する機能要件をプログラムが満たしていない場合、ソフトウェアシステムにバグがあることを意味します。

ユーザーのログインインターフェイスでは、パスワードが平文で表示されるため、パスワード漏洩が発生しやすくなります。これは明らかにバグです。

4. ソフトウェアのライフサイクル

6つのフェーズ：要件分析、計画、設計、コーディング、テスト、運用、保守

要件分析: 要件が合理的で完全であるかどうかに注意を払う

計画: 開発、テスト、スケジュール設定

コーディング：コードを書く

テスト: テストを実施し、テストレポートを生成します。

運用とメンテナンス: プロジェクトがオンラインになった後、問題が発生した場合、テスターは開発者が問題を特定するのを支援し、問題を解決した後に再びオンラインにする必要があります。

5. 開発モデルとテストモデル

開発モデル

ウォーターフォールモデル

要件分析後の出力: 要件文書

設計段階での出力: 技術文書、関連するインターフェイス、ライブラリテーブル、mq、時間指定タスク、UI ビジュアルドラフト

テスト: テストケースを実行し、バグを送信します。

長所: 各ステージの作業が非常に明確です

短所: 単一プロセスであるためリスクが高く、テスターの介入が遅く、後のテスト段階で判明したバグは早期に修正する機会を失い、人的資源と物的リソースが無駄になります。

対象プロジェクト：規模が小さく、開発サイクルが短いプロジェクト

ラピッドプロトタイピングモデル

ラピッドプロトタイプモデル（ラピッドプロトタイプモデル）は、主にコンセプト、設計、機能の迅速な検証とデモンストレーションに使用されるソフトウェア開発プロセスモデルです。

ラピッドプロトタイピングモデルの主な機能は次のとおりです。

迅速な開発: ラピッドプロトタイピングモデルは、迅速な反復と開発に焦点を当てています。開発チームは、システムのコア機能と外観を実証するために、簡略化されたプロトタイプを迅速に作成します。これにより、早期のユーザーフィードバックと設計の検証が容易になります。

ユーザーの関与: ラピッドプロトタイピングモデルでは、ユーザーの関与とフィードバックが重視されます。プロトタイプは、ユーザーと対話し、意見や提案を得るために使用できます。これにより、最終的なソフトウェアシステムがユーザーのニーズと期待を確実に満たすことができます。

高度な視覚化: ラピッドプロトタイピングモデルは通常、グラフィカルインターフェイスに基づいており、グラフィカル要素と対話型操作を通じてシステムの機能とインターフェイスを示します。これにより、ユーザーはシステムの外観と動作をよりよく理解し、評価できるようになります。

反復的な改善: ラピッドプロトタイピングモデルは反復的に開発されます。ユーザーからのフィードバックや要件の変化に従って、開発チームはプロトタイプの改善と拡張を継続し、システムの品質と機能が期待を満たすことを保証します。

短所: ラピッドプロトタイピングモデルは、後続の開発段階で技術的および複雑性の課題につながる可能性があり、慎重な評価と計画が必要です。

適用可能なシナリオ: システムの機能とインターフェイスを迅速に検証およびデモンストレーションするプロジェクトに適しています

スパイラルモデル

特徴：

反復ループ: スパイラルモデルは、ソフトウェア開発プロセスを反復サイクルに分割します。各反復サイクルには、要件分析、設計、開発、テスト、およびレビューの段階が含まれます。各反復サイクルでソフトウェアシステムが徐々に改良され、以前の経験に基づいて適応および改善されます。

リスク主導: スパイラルモデルはリスク管理に焦点を当てています。各反復サイクルの開始時に、リスク評価と分析が実行されます。開発チームはプロジェクト失敗のリスクを軽減するために、リスクの高い問題に優先順位を付けます

プロトタイプ開発：スパイラルモデルはプロトタイプ開発をサポートします。プロジェクトの初期段階では、ラピッドプロトタイピングを使用して要件と設計を検証し、ユーザーフィードバックを取得し、その後の開発作業をガイドできます。

フェーズレビュー: スパイラルモデルの各反復サイクルの後に、フェーズレビューが実施されます。レビューでは前段階の結果を検証・検討し、合理性・実現可能性を確認し、次の段階の方向性を決定します。

短所: より多くのリソースと時間が必要になる可能性があり、プロジェクトを確実に成功させるためにより厳格な管理と制御が必要になる可能性があります。

適用可能なプロジェクト: スパイラルモデルは、大規模で複雑でリスクの高いソフトウェアプロジェクトに適しています。

インクリメンタルモデル

システムの開発と提供を複数の増分または反復完了の部分に分解する

インクリメンタルモデルの主な特徴は次のとおりです。

増分配信: ソフトウェアシステムの開発と配信を複数の段階に分割します。各増分は、サブシステムまたは関数の完全な動作可能なコレクションです。各増分が完了すると、それをユーザーに配信してフィードバックを得ることができます。

反復開発: 反復的な方法で開発します。各増分は、要件分析、設計、開発、テスト、納品などの段階を含む反復サイクルです。各反復では、新しい機能が追加されたり、既存の機能が改善されたりします。

優先順位の割り当て: インクリメンタルモデルでは、各インクリメントの開発優先順位を調整できます。各増分は、ユーザーのニーズ、リスクの程度、システムの複雑さなどの要因に基づいて優先順位を付けることができます。

増分統合: 各増分が完了すると、増分間の相互作用とシステム全体の正常な動作を確認するために増分統合テストが実行されます。これは、統合の問題を早期に検出して解決するのに役立ちます。

ユーザーエンゲージメント: ユーザーエンゲージメントとフィードバックを重視します。ユーザーは完了後に各増分を確認およびテストし、システムの機能とパフォーマンスに関するフィードバックを提供できます。

アジャイルな手法

プロセスやツールよりも個人と相互作用の方が重要: ソフトウェア開発では、個々のメンバー間のコミュニケーションと協力がプロセスやツールよりも重要であることを強調します。つまり、チームメンバーはツールやプロセスのみに依存するのではなく、効果的なコミュニケーション、コラボレーション、対話に重点を置く必要があります。

包括的なドキュメントよりも使いやすいソフトウェア: アジャイル手法では、面倒なドキュメントに重点を置くのではなく、使いやすいソフトウェア製品を提供することに焦点を当てます。

顧客との協力は契約交渉よりも重要です。顧客との緊密な協力と継続的なフィードバックを重視します。チームとクライアントの間のコラボレーションとコミュニケーションは、比較的厳格な契約交渉よりもプロジェクトの成功を促進します。

変化への対応は計画に従うことよりも重要です。アジャイル手法では要件が変化することを認識しているため、変化への柔軟な対応を重視します。

後者はアジャイル手法において価値がないわけではありませんが、前者に比べれば二次的なものです。

スクラムの3つの役割

プロダクトオーナー: 利害関係者、顧客、またはユーザーを表し、プロダクトバックログの管理に責任を負います。彼らはチームと緊密に連携して、製品の要件、優先順位、リリース計画を定義します。プロダクトオーナーは、スプリント計画会議、スプリント振り返り会議、およびスプリントレビュー会議にも参加して、チームがユーザーの期待に応える機能を確実に提供できるようにします。
R&D チーム (スクラムチーム): 製品の開発、テスト、提供を担当する、部門を超えた自己組織化チームです。チームメンバーには通常、開発者、テスター、その他の必要なスキルが含まれます。研究開発チームは、スプリント計画会議で完了した作業に取り組み、毎日のスタンドアップミーティングを通じて情報を調整および共有します。彼らは、プロダクトバックログのタスクに基づいて作業を完了し、スプリントレトロスペクティブおよびスプリントレビューミーティングで完了した作業を発表して議論する責任があります。
プロジェクトマネージャー (スクラムマスター): チームのアジャイルコーチであり、反復プロセスの守護者です。彼らは、スクラム方法論の実装と継続的な改善を促進するために働いています。プロジェクトマネージャーは、チームの障害を取り除き、チームがスクラムのルールと実践に確実に準拠していることを確認し、チームの自己組織化と機能横断性を促進する責任があります。また、スプリントの振り返りや毎日のスタンドアップを企画して主導し、スクラムチームに参加する新しいメンバーをトレーニングします。

プロセス

プロダクトマネージャー (ユーザー要件の収集) -> プロジェクトマネージャー (要件の優先順位付け、プロジェクトスケジュールの計画) -> 毎日のスタンドアップミーティング (昨日の作業が完了したかどうかと発生した問題の報告、今日の問題に対する作業計画) -> プロジェクトのデモ

テストモデル

Vモデル

要件分析とシステム設計: 製品が提供するソフトウェア要件が正しいかどうかを検証し、プログラミング言語を決定し、フレームワークを使用します。

簡単な設計: プロジェクト構造の設計

詳細設計：各インターフェース、ライブラリテーブル、タイミングタスクの設計

コーディング: コーディング

この時点で、テスターがフォローアップテストに入ります。

単体テスト: Java のすべてのメソッドとクラスをテストします。

統合テスト: 多くのメソッドを一緒にテストする

システムテスト：モジュール間で影響がないかをテストし、すべての機能をテストします。

受け入れテスト: プロジェクトがオンラインになる前に、製品と操作を確認して受け入れます。

特徴: 左側は開発プロセス、右側はテストプロセス (ウォーターフォールモデルと同様)

長所: テストプロセスは多くの種類に分かれています

短所: テスターの介入が遅く、問題を発見するのが遅すぎます。

Wモデル

ダブルVモデルとも呼ばれる

特徴: V の開発、V のテスト

利点: テスターが要件に早期に介入できる

デメリット：テスターや開発者がある程度シリアル化されている、ウォーターフォールモデルに似ているため要件定義書が最初から決まっており、VモデルやWモデルは変化を受け入れられずアジャイルに適用できない

テストの基本概念と一般的な開発およびテストモデル

1. 需要の概念

2. テストケース

3. バグとは

4. ソフトウェアのライフサイクル

5. 開発モデルとテストモデル