しかし、私はしばしば小規模なチームに紹介されました。そこでは、1〜2人のテスターに対して5人の開発者がいて、原則としてプロジェクトで多くの熱気がありました。 実際、あなたがどこで自分を見つけたのかを理解する方法を学び、QAプロセスの策定を進める方法を共有したいと思います。
まず第一に、あなたはどのプロジェクトに参加しているかを理解する必要があります。
プロジェクトに参加して経験を積んだ後、条件付きで3つのタイプに分けます。
- テストなしのプロジェクト。
- 不公平なテストを伴うプロジェクト。
- テストプロジェクト。
私が関与した時点では、それぞれが開発の段階にありました。 私はこれらの状況を観察し始め、私のビジョン、つまりそれらのテストプロセスを促進する方法を開発し始めました。 しばらくして、私は成熟度モデルに出くわし、彼女は私の基礎の上に1対1で横になりました。 これは、これが場所であるという私の信念を強化しました。
成熟度モデルとは
そして、ここで私は非常に巧妙にウィキペディアから引用を挿入しています：
Capability Maturity Model Integration（CMMI）-さまざまな規模および活動の組織でプロセスを改善するための一連のモデル（方法論）。 CMMIには一連の推奨事項がプラクティスの形式で含まれており、その実装により、モデルの開発者によると、特定のアクティビティ領域の完全な実装に必要な目標を実現できます。
簡単に言えば、これは、特定の基準に従って組織内のプロセスがどれだけうまく組織化されているかを示すモデルのセットです。 このような評価を行うことで、特定の請負業者に1つまたは別の注文を与える価値があるかどうかを冷静に評価できます。
実際、これから成熟度モデルの開発が始まりました。 80年代、米国国防総省は、ソフトウェア開発請負業者の作業の品質を正確に評価できないことに気付きました。 そして、これはそのようなレベルの状態構造であるため、これは受け入れられません。 お金は国有であり、締め切りは明確に描かれており、武器用の信頼できるソフトウェアは誰もがより平和に眠ることを可能にします。 これに基づいて、省はソフトウェア工学研究所にそのような評価システムを作成するように指示し、1年後に最初のアンケートが作成され、4年後にモデルの最初のバージョンが作成されました。
成熟度モデルのレベル
これらは5つのレベルであり、その中で企業の仕事/信頼性/安定性が評価されます。
成熟度モデルのどこでテストしていますか
テスターには、TMMiと呼ばれる特別なMMがあります。 また、5つのレベルが含まれています。これらのレベルについて詳しく説明し、各レベルの典型的なものを検討したいと思います。
最初のレベルは「初心者」です
最初のレベルでは、テストは構造化されておらず、混chaとしていません。 テストプロセスをサポートする安定した環境はありません。 チームは計画と標準に注意を払いません。
ここでのテストは、重大な問題なしにアプリケーションが機能することを示すためだけに使用されるため、主な目標は、重大な問題なしに製品を時間通りに提供することです。 多くの場合、このようなプロジェクトの成功は、確立されたプロセスではなく、個人のヒロイズムとスキルのみに依存します。
その結果：
- テスト文書なし;
- 製品が不安定です。
- 問題のある状況でのプロセスの拒否;
- テストはデバッグの助けにすぎません。
第2レベル-「繰り返し可能」
第2レベルでは、テストは制御されたプロセスになります。 規律と進歩により、これらの慣行はストレスの間も維持されます。 テストは、引き続き開発に続くアクティビティと見なされます。 テスト計画は、どの種類のテストをいつ、誰が行うべきかを明確に決定する助けを借りて開発および実装されます。
主な目標は、製品が指定された要件を満たしていることを確認することです。
その結果：
- テストの主なタイプとタイプがあります（統合、モジュール式、回帰、受け入れ）。
- 実装されたテスト計画。
- テスト活動は監視および制御されます。
- プロセスは文書化されており、繰り返すことができます。
第3レベル-「定義済み」
3番目のレベルでは、テストはプログラミング後のアクティビティとは見なされなくなりました。 テストはプロジェクトに完全に統合されています。 テスト計画は初期段階で実行され、マスタープランで修正されます。 機能しないテスト（使いやすさなど）が導入されています。
その結果：
- テストは要件段階から始まります。
- より効率的に作業できるようにするアクティビティが追加されました（内部トレーニング、追加レビュー）。
- 非機能テストが導入されています。
第4レベル-「測定可能」
第4レベルでは、テストは明確に定義され、確立され、測定可能なプロセスです。 テストは評価として認識され、ソフトウェア開発ライフサイクルのすべての操作で構成されます。 テストの品質を測定する方法が導入されています。 これらの測定値は、テストのパフォーマンスとコストを予測するために使用されます。
その結果：
- 測定可能なプロセスとしてのテスト。
- 測定値は予測に使用されます。
- チームは、テストプロセスをより効率的にする方法を探しています。
第5レベル-「革新的」
第5レベルでは、すべてのアプローチとプロセスが確立されています。 チームはこの段階で停止することはありませんが、プロセスを体系的に改善し続け、プロジェクトの品質を低下させることなく、テストサイクルと市場投入までの時間を常に削減しようとしています。 テストは予防に焦点を合わせています。 リソースのより効率的な使用のために自動化が追加されました。
その結果：
- 継続的なプロセス改善。
- 予防と最適化に焦点を当てます。
この構造の知識がどのように役立つか
ケース番号1.不公正なテスト
顧客、友人、または猫によってテストが行われる小さなプロジェクトに着いたとき。 状況を評価し、モデルを見ると、レベル1にいること、およびアクティビティの計画中にレベル2に焦点を合わせる必要があることを理解できます。 多数のバグ（ほとんどが重複または再現性がなかった）があったJiraを整理した後、チェックリストの形式でテストドキュメントのコンパイルを開始し、基本的なテストプロセスを整理しました。 主要な変更中の回帰テストや健全性チェックなど。
ケース番号2.テストなし
私の意見では、このタイプのプロジェクトは3つの場合があります。
- プロジェクトはまだ始まったばかりです。
- プロジェクトにテスターは必要ありませんが、機能は少しありました。
- フルスタックチームは、品質の高いコードレビューと開発テストにより、テスターの不足を解消しました。
これらのプロジェクトのいずれかで一度、あなたはしばしばそれが秘密のゼロレベルにあるという事実の利点を見ることができます。 最初のレベルを飛び越えて、すぐにすべてを定性的に、適切な感覚、感覚、配置で行い、2番目の目標に導かれます。 多くの場合、必要なすべての種類のテストが実行されることに基づいて、テスト計画を実装できます。 最初のケースのプロジェクトにない開発チームと同じワークフローをすぐに特定できます。
ケース3。テストは
実際、最もまれなケース：特定のイベントにより、人がチーム/部門/仕事を変更することを決定し、彼のベストプラクティスを提供します。 この状況では、開発者との相互作用の確立されたシステム、テスト文書の特定のベースがすでにあります。 さらなる開発パスには、確立されたプロセスの改善または第3レベルへの移行（初期段階でのテストの導入、または機能しないテストの追加）が含まれます。
ケース番号4。スリーインワン
Provectusのプロジェクトに来たとき、上記の3つのケースからほんの少ししか出ていない状況に直面しました。 ケース1のように、最初にすることはJiraを整理することでした。 2番目のケースと同様に、すぐに2番目のレベルに導かれるように、すべてをすぐに高品質で行うことが決定されました。 そのため、すぐにテストドキュメントの開発とテスト管理ツールの実装を開始しました。 また、3番目のケースのように、過去の反復のアーティファクトを最大限に圧縮しようとしました。
非常に短い時間の後、私たちはすでに意図的に第3レベルに進んでいると安全に言うことができます-私たちはビジネス要件段階でテストさえ接続しました:)
結論
私の経験では、ほとんどのウクライナのプロジェクト、および長期間設計されていないプロジェクトは、レベル3でGoに正常に移行できます。 しかし、長期プロジェクトがある場合、それを改善する可能性は無限であり、最高レベルの成果によって安全に導くことができます。
結論として、この記事の目的は、古典的なMMまたはTMM自体の操作方法を示すことではなく、プロジェクトのどの段階で関与しているかを明確に理解できることです。どの動きをとるか、それは価値がない。 さらに、その原則を基礎として、独自のモデルを作成できます。このモデルは、開発だけでなく、生活のさまざまな分野にも適用できます。 そして最も重要なこと-テストされ、動作します:)