概要

プロジェクトマネジメントのプロセスには、いくつかの重要な段階があります：

要求段階、開発段階、テスト段階、本稼働段階

要件フェーズと開発フェーズが最も重要であり、1つは設計であり、この機能がどのように動作するかを定義し、1つは実装と実現であり、これらの2つのフェーズがよく制御されている、次のステップははるかにスムーズになります。以下は、テストのステップの開発段階に焦点を当て、テストの品質を確保するために、テストの前に何を準備する必要があります。

まず、テストについて言及する行為についてですが、私自身は理解しています：

テスト済みということは、開発者が「この機能はこのように見える」と考えているということであり、製品PRDに完全に則って実装されているということであり、厳格で責任ある良心的な行動です。

理屈の上では、開発者はテストが完了したら、他の要件タスクに取り掛かることができます。

テストの質にこだわる理由

今述べたいくつかのプロジェクト管理の段階では、早ければ早いほど深刻で、問題の早期発見早期解決するために、テスト段階では、まだ様々な問題がある場合は、基本的に恐ろしい代償を支払うことになります。

機能言及テストの後、次のような状況に遭遇したことはありませんか？

何百ものフロントエンドのBUG、何十もの深刻な障害BUG、テスト環境は非常に不安定であり、テスターは、開発者が見つけるように来ている、製品のPRDと同じではありません。

注：ここでは、テストに言及するアクションの実行前に行うことに重点を置いており、懸念は、テスターが引き継いだ後、それがスムーズに進むことができるかどうか、アーキテクチャのスキーム、技術設計、圧力テスト、ロールバックのスキームのように、ああ、これらは他のアクションですが、必須であり、記事では強調されません。

試験を受ける前にすべきこと

完全なエンドツーエンドのチューニング

自分が担当する部分だけ完璧でも意味がないし、エンド・ツー・エンドでカップリングされた途端、何か問題が起こるかもしれません。

エンドツーエンドのチューニングの重要性はいくら強調してもしすぎることはありません。機能モジュールが製品の期待に応えているかどうかを総合的に検証することができます。UIの問題、エクスペリエンスの問題、バックエンドのインターフェース・データの問題、互換性の問題などは、すべてこの段階で見つけることができます。

他にも使えるヒントが2つあります：

• 開発環境があまりにも安定していないか、または不完全なデータである場合、それはテスト環境で直接開発を行うことをお勧めします、共同モデレーションの開発、環境の滑らかな、完了すると、テスターは、機能テストを行うには、同じテスト環境にすることができます、あなたはテスト、環境の問題の数が多いを言及しないようにすることができますし、テスターが対処する方法を知らないが、唯一のリソースの無駄遣いをもたらし、位置決めの開発を見つけること。もちろん、テスターが独立してテスト環境を維持する能力を持っている場合、それはそうすることをお勧めしません。
• テスターから提供された喫煙ユースケースに従って、開発コ・チューニングを的を絞って実施し、コ・チューニングの効率化を図ります。開発者が非常に忍耐強く、製品PRDに記載されたポイントに従って一つ一つ検証していけるのであれば、もちろんなおさらです。

煙と鏡のユースケースの実装

スモークケースはベースケースのサブセットであり、失敗した場合、テスターはテスト用に提案されたモジュールをノックバックすることができます。

さらに、テスターが提供する喫煙ユースケースは、ベースの重要な機能ポイントを正確にカバーする品質でなければなりません。

変更点のリスト

ここでの変更点は、あなたの現在の開発によって、既存のモジュールやオンラインの安定したモジュールがどのように変更されるかを示しています。テスターがより意図的かつ効率的に回帰テストを行えるように、それらをリストアップする必要があります。

環境復帰のためのチェックリストの作成

設定ファイルの変更のように、データベースの変更、MQの設定は、これらのテストの言及の前に、準備する必要がある、そうでなければテスト環境や回帰環境で機能モジュールがあるかもしれませんスムーズに実行することはできません、腕と脚を欠いている、サービスの多くを含む大規模なモジュールのいくつかのように、各サービスは、独自の変更を持って、タイムリーにそれらを記録していない、それは忘れやすいです。これは大幅に機能テストの効率が低下します。

私は数回、機能モジュール月曜日の夜のテストに遭遇した、翌日テスターが介入し始めたが、翌日の午後までテスト環境での機能モジュールがスムーズに実行するために、これは多くの開発者とテスターの時間の無駄、あるべきでない方法ですいくつかの深刻な、また、プロジェクトの遅延につながる可能性があります。

必要であれば、プロダクトマネージャーによる早期承認

非常に多くのポイントを含む大規模な機能モジュールのいくつかのように、この時点で、プロダクトマネージャが時間を持っている場合は、手の受け入れ前に、テストの機能でそれをさせることができますので、機能モジュールがオフになっているかどうかを調べることができますが、また、フロントエンドの経験の問題の多くを見つけることができますし、時間内に開発者がそれらを解決するために。

あるプロジェクトでは、テストに言及した後、テスターが何百ものフロントエンドの経験やUIの問題を提起し、テスターがバグの説明を書くだけでも長い時間がかかり、さらに開発にもバグを流させる必要があり、そのすべてに時間がかかりました。

テスターに伝えたいこと

なぜなら、テスターに提出されたものは非常に不安定なもので、テストセッションに入ると、テスターを落とし穴にはめるようになるからです。なぜなら、テスターに提出されたものは非常に不安定なものであり、ひとたびテストセッションに入ると、テスターを蝕み始めるからです。また、これはテスターを保護する方法でもあります。結局のところ、キューはそれほど長くはないのです。

加えて、テスターは正当な開発者に挑戦することができ、実際には、唯一の場所は、機能モジュールがオンラインである場合、テストの品質に言及することですが、問題のうち、その後、上司は、テスターを探すために最初にある、関数がオンラインであるかどうかすることができますので、それはテスターが決定され、上司と話しているのと同じです：

機能は厳密にテストされ、納品準備が整っています。

実際には、行の後に問題の束です。したがって、テスターは、テストする開発者の品質に対して死んで煙が、ヒットバック、その後煙が、深刻な警告、または煙が、その後、もう少し冷酷でなければなりません、あなたは、モジュールの上にテストする開発チームのいくつかをテストすることはできませんので、テストセッションに、上にテストするためのテストは、その後、廃棄物の様々な悪い、様々なを開始します。

まとめ

プロセスは、私たちは、最初は、より推奨される方法は、プロジェクトは、プロジェクト管理プロセスを理解する技術的な責任者を指定することです、彼/彼女の一時的な権限を付与する電力の実装をテストするために開始する必要があります、それは全体のプロセスを通じて調整され、どこでも戦争を監督し、誰が協力しない、あなたが直接指摘することができます。このように、いくつかのプロジェクトの実施後、誰もが徐々に適応し始めます。