平均的なRMに「なぜこのプロジェクトでテストするのですか？」という単純な質問をすると、ほとんどの場合、答えは「あなたはテストマネージャーです。この質問に答える必要があります。」
しかし、あなたが美容院に来たとき、あなたは主人に「あなた自身が私が必要なものを知っている」とは言いませんか？ 食料品店では、売り手に必要なものをバスケットに入れるように頼みませんか？ あなたは相談することができ、「どうすればいいのか」を見つけることができます。オプションを求めますが、決定は常にあなた次第です。 テストの違いは何ですか？ たぶん、プロジェクトマネージャーが必要な理由を理解しているプロジェクトマネージャーが少なすぎるという事実でしょうか。
この記事では、クライアントに「一般的に何が起こるのか」を示す売り手の役割を演じようとします。多くのことを説明します。おそらくあまりにも詳細で、単純すぎます...怒ってはいけません。
テストからの期待を策定する理由
カモン！ テストは、自動化されていれば、あらゆる種類のボタンを押すことです。 そのため、どの目標が明確になっています！ あなたはバグを見つける必要があり、それだけ多ければ多いほど良いです。 他のテスト目標は何ですか？
おっと...このアプローチに基づいて、すべての企業でテストを行い、すべてが正常に動作しています。 バグが見つかり、修正され、チェックされます...そして、テストはいつでも便利ですか？ 常にその可能性を最大限に引き出しますか？
何かが私に教えてくれません。 それでは、「すべてがテストで問題ない」というまれなケースと圧倒的多数のケースの違いは何ですか？
別のイラストをお試しください。 あなたはあなたの人生でマッサージに行ったことがありません。 あなたはサロンに行きます（なぜ、みんな行くのですか、なぜ行かないのですか？）そして、30分のセッションを注文してください。 予算は固定されており、「マッサージしてください」という要件があります。 不明瞭な外観、女性はあなたの非常に明確な肩で不明瞭にいじくり回します、あなたはサロンを出て、「ああ、マッサージ-それは完全なゴミだ」と考えます。 しかし、「マッサージしてください」という要件は満たされました。 おそらくポイントは要件の不正確さでしょうか？ 背中が痛いので、痛みを治したいですか？ または、十分なストレッチがありませんでしたか？ それとも、リラックスしたいですか？ 要件が正確であるほど、請負業者が要件を満たせる可能性が高くなります。 しかし、あなたが望むものを定式化できない場合、実行者は必要なことを行うことができず、結果を客観的に評価することができません。
テストから何が期待できますか？
製品の品質を改善するには、テストが必要です。 これは明らかです！
おっと...練習からの簡単な例。 テストチームはタイムリーに欠陥を発見し、開発チームはそれらを修正する時間を持っていません。製品は必ず市場に参入し、顧客は「吸う」と言います...何がテストが悪かったのですか？
またはその逆も可能です。 テスターは製品を徹底的に検査し、テールとたてがみでそれを使用して、単一のエラーを見つけず、市場にリリースされ、ユーザーは満足しています、キャップは空を飛んでいます、花は開発会社の住所に送られます...テスターはよくできていますか？
一般的に、多くの例があります。 しかし、結論はほとんど常に同じです。品質テストは効果がありません。 あなたの散髪があなたの成功に影響しないように。 「ねえ、美容師、髪を切って、試験に合格します！」 ロジックはありませんか？ テストでは、同じこと。 テストは、特定の予算で、特定の形式で、特定の速度で情報を提供します...しかし、テストは、たとえそれが本当に望んでも、品質に影響しません。
それでは何がテストを提供できますか？
すべての結果、すべての作業は、テストカバレッジ、提供される情報、速度、予算という4つの変数の式で表されます。
最初にこれらの点を見てから、式自体に進みましょう。
1.テスト範囲
これは、テストグループによってテストされた、考えられるユーザーシナリオ、条件、設定、入力パラメーターなどの割合です。 この割合が高いほど、発見されるバグが多くなり、見逃されにくくなります。 必要に応じて、可能であれば、より多くのバグを修正できます 。
さらに、テストのカバレッジとテストの数、およびテストに費やされたリソースは、非常に間接的に関連しています。 認定されたテスターには、「プッシュ不可能な状態で移動する」、テストスイートを最適化する、最小限のテストで最大限のカバレッジを提供する、さまざまなテクニックとツールが用意されています。
カバレッジは測定可能であり、測定する必要があります：トレーサビリティマトリックス、コードカバレッジ、見逃した欠陥の割合、およびその他の多くの指標が役立ちます。
2.提供される情報
何年もの間、テスターについてのミームが生きており、彼の目にはパニックがあり、「何も機能しない！」と言っています。 そして、もっと詳しく説明するように頼むと、彼は「さて、絶対に何もありません！」と答えます。 おそらく彼は良いテストカバレッジを提供しましたが、悲しいかな、適切な情報を提供しませんでした。 プロジェクトはテストからどのような情報を必要としますか？
- バグトラッカーで定性的に記述されたバグ
- リリースの予測とプロセスに関する意思決定のための製品統計
- リリース決定の品質メトリック
- テスト自体の評価：カバレッジ、チェック対象、テストで十分かどうかなど。
テストグループが製品とプロジェクトに関する明確な情報を提供しない場合（そしてこれが主な機能です！）、決定を下すことは非常に困難です。
3.テスト速度
わかりました。カバレッジは良好で、情報は明確です...遅すぎます。 または長い間。 または長いため、遅れます。
皆さんは明らかにこの状況に直面しています。3日間のリリース前に、重大なバグがあります。 開発者が頭を悩ませ、修正を開始すると、このバグが6か月間欠落していることがわかりました。実際には、はるかに早く発見できました。 そして、このバグは2か月前に30分で修正され、今では製品の半分がそれに結び付けられ、混乱するのに1週間かかります。
TOCプロジェクトの分析を行う人はほとんどいません。また、テストによってリリースが数回長くなることがあることに気づく人はほとんどいません。 ここで、テストをタイムリーなものに置き換えて、リリースを2倍速くします。
通常、これは目に見えず、バグがすべてのトラブルの原因であるように思われます...しかし、時にはそれらを早期に発見することで、開発サイクル全体のコストを削減できます！
または、テスト速度の別の側面：アセンブリの検証にかかる時間。 たとえば、リリースの準備をしています。 RC（リリース候補）を取得します。 テストには、それが機能していることを確認するために1週間かかり、RMは同意し、1週間を割り当て、5日目に重大なバグがあります...修正に10分、5日後に5日目に重大なバグがあります...直面しましたか？ おなじみの音？
4.予算
おそらくこれが最も簡単なアイテムです。 当然、相対的です。 1000ルーブルはたくさんですか、それとも少しですか？ たぶん一塊のパンにはたくさんのパンがありますが、おそらくバリへの旅行には十分ではありません。 したがって、予算は、「テスト」のためではなく、このテスト自体の具体的で理解可能な結果のために支払う意思のある金額です。
それでは、次は何ですか？
そしてこれ。 プロジェクトに最大限の利益をもたらすには、現在何が必要かを正確に知る必要があります。 必要なものを知るためには、その指標を分析する必要があります。これは、通常ではありません。期限、品質、予算です。 その後、テスト要件を使用して独自の数式を作成します。 同時に、私たちは正直になります：「時間を短縮する」または「カバレッジを増やす」-これらは同じ「私をマッサージする」です。
正確な指標が必要です。 なんで？ 変更を評価するため。 それらがプロジェクト全体のパフォーマンスに本当に影響するかどうかを監視するために（正直なところ、それ自体をカバーする必要はありません！） プロセスを制御します。
「ユニットテスト」、「自動化」、「テストデザイン」などと言ったことはありません。 すべてのアクションは、特定の目標の結果に応じてのみプロセスに導入されます！ アセンブリのテスト速度を上げる必要がありますか？ 自動化を導入します。 欠陥を見つける速度を上げる必要がありますか？ 単体テスト。 品質を報告しますか？ 欠陥の緩和。 テストでは、目標に基づいて組み合わせることができる何百ものアプローチ、ツール、ソリューション。 しかし、ツール自体は二次的です。
したがって、ASテスター/テストマネージャー/テストアウトソーサーはあなたの目標を達成します-これは彼の頭痛です。 しかし、プロジェクトに注意を払っているRMよりも優れた人は、このプロジェクトに必要なものを言うことはありません！