テスト労働計画-SQAデイ15レポート

SQA Days-15カンファレンスでのAlexandra Kovalevaによるレポート。







プレゼンテーション





会社でリスク評価をしています。 過去、テストリードとして働いて、私はグローバルプランニングに携わってきました。 ただし、すべての企業が計画に多くの時間を費やしているわけではありません。 どうすればいいのかを話します。



マスタークラスは2つの部分で構成されます。

1.理論-評価と計画の概念。 役割とタスク。

2.実用的-リソース管理の例（ ビデオを見ることができます ）



それで、計画は何ですか？ これは非常にグローバルな概念であり、生活のあらゆる分野に適用できます。

    –        «-»  ..
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

。



例として、朝仕事に行って、夕方に映画を見に行くことを考えるとき、あなたは計画しています！ 職場でも！ 計画について尋ねられないという事実にもかかわらず、作業を終了して結果をチームに渡すことができる時期を知る必要があるため、計画を立てています。 それ以外の場合は、リリース日を正確に述べ、その日付を計画します。これは、計画に示されている日付の範囲内にないため、多くの場合延期されます。



計画は非常に広い概念です。 そして、テスト段階での計画について話す前に、この言葉が会社の他のメンバー、特に経営陣にとって何を意味するかを知る必要があります。



しかし、チームは計画に参加しますが、チームはそれを必要としません。彼らはそれを望んでいません。 この問題は管理から発生します。 マネージャーは、時間を知りたい顧客と常に連絡を取り合っています。 しかし、これは開発に費やされた時間ではなく、最終製品を受け取る日付と必要な時間です。



この場合、特に製品のリリース日が違反されている場合、お金と時間は非常に相互に関連しています。 たぶん彼はあなたからの報告を必要としませんが、彼は他の専門家と関係しています：マーケティング担当者（広告会社）、投資家（予算配分）。 製品リリースの最後のリンクはテスト中なので、彼らはそれを保存しようとします。



プロジェクトの開始前に計画する時間があるため、予測方法論での計画について説明します。 柔軟な方法論では、すべてが「今ここで」発生します。通常の計画だけでなく、原則として初期計画も管理に従事します。 これは別のトピックです。







予測方法論について話している場合、スライドで観察できる段階全体が存在する可能性があります。 ここでは、たとえば、最初の段階-インセンティブ-最大6か月かかることがあります。 そして、これは彼らがプログラムを行わず、実際に要件を処理しない期間です。 彼らが私たちに支払うときに誰が同意することができ、私たちは本当に何もしませんか？ これは、軍事、医療産業かもしれません。 これらは、人々の生活が依存するグローバルプロジェクトであり、開発期間は約2〜5〜7年です。 通常、計画には約2週間かかりますが、多くの場合、それは「明日」です。



テスト計画とは何ですか？ テストリードの場合、これは時間だけでなく、テストの対象、方法、場所でもあります。



テスト計画 ：



1.テスト要件の定義

2.リスク評価

3.テスト戦略の開発

4.リソースの定義

5.テスト計画の開発

6.勤務スケジュールの作成



各質問は検討する価値があります。 ただし、 「作業スケジュールの作成」という小さな項目については説明します。 もちろん、テストについて簡単に言うこともできますが、議論を示して何らかの形で形式化する方が良いでしょう。



それではこれについて話しましょう。 もちろん、結果を評価せずに計画を立てることはできません。これが私たちの主な問題です。



「評価する方法がわかりません！」-チームは、そのようなジュニアまたは経験豊富なスペシャリストをあなたに伝えることができます。 その理由は、特定の方法がない場合に見られます。 これは非常に大きな間違いです。 メソッドがあります：



詳細な数学的研究が必要：



1. Delphiメソッド。

2. 3点法（逐次計算）;

3.機能ポイント/テストポイントの分析方法。

4.ユースケースのポイントを評価する方法。

5. COCOMO（COnstructive COst MOdel）-コストモデル。

6.遺伝的評価モデル。



これらは数学的手法ですが、それらを使用する企業は見たことがありません。 主な欠点 ：



1.時間がかかります

2.労働集約的です

3.結果は得られません。



なんで？



なぜなら計画は柔軟でなければならないからです。 複雑に計算された計画は、誰かが来たり病気になったりしなかったという事実によってのみ違反される可能性があるからです。 数えるには？ ほとんどない！



したがって、すでに使用している方法について説明しますが、常に実現するとは限りません！



最も使いやすい：

1. PVN（空の指）、または試行錯誤;

2.特別な方法;

3.専門家のアナロジーと推奨事項。

4.仕事の分解の構造。

5.開発の割合。

6.パーセンテージ分布の方法。



私たちのお気に入りは試行錯誤です。 私たちは皆それを頻繁に使用します。 専門家の評価方法との違いを理解する必要があります。



すでにプロジェクトで作業したことがある場合、それは使い慣れたものであり、何かをテストした後、すでに専門家としてやっています。 テストのためにこれを行わず、プロジェクトで作業せず、この領域または顧客に出会ったことがない場合は、空を指で完全に評価します。 それが大きな違いです。







私の好きな方法は作品の分解の構造です 。 これは、最も時間がかかりませんが、評価のための形式化された方法です。 どういう意味ですか？ 作業を最小限に分割するだけで、非常に簡単に評価でき、学習する必要もありません。



たとえば、認証をテストします。 文字「o」は通らない-すぐに自分で5分と言うことができる。 これは最小単位です。 これは、数か月しか働いていない人でも判断できます。 さらに、この方法では、何かを忘れるのが難しくなります。

要件と大きなタスクを取り、それらを3つの部分に分割します。たとえば、フィールドテスト、ボタンテスト、ローカライズテスト、パフォーマンステスト、およびタイプ、メソッド、エリアごとのテストです。 さらにスクロール：数字、文字、文字などを入力します。







図に注意してください。ここに、6か月から1年のサイトの統計があります。 プログラミングは開発の20％〜40％を要します。これはプロジェクトの20〜40％と同じではなく、プロジェクトの平均15％です。 テストで製品の15％が使用されることはありません。 テストする時間があまりない場合は、少なくともいくつかを入れてください。 プロジェクトの何パーセントがテストにかかるかを統計的に調べることをお勧めします。これは、安定したバージョンのリリースがある場合に適用できます。製品の一定量は同じです。



問題解決



1.初心者に教える：

a。 タイミング

b。 分析

2.プロジェクトのポートフォリオ用の汎用推定チェックリストを作成します。

3.見積もりの​​誤りを非難しないでください。



これを行うには、トレーニングに行く必要はありません。どういうわけか、評価し、成績を書き留め、実際にどれだけ時間がかかったかを確認する必要があります。 さまざまなトレーラー/アプリケーションが時間の記録に役立ちます。 または、数日後に覚えておいてください。 自分で理解したら、チームに教えることができます。 評価するようにチームを説得しようとするとき、これらの評価のためにそれをscらないことが非常に重要です。 ほとんどの場合、人々はあなたが彼らの欠陥を見つけることができることを恐れているので、評価したくない。 すべてが修正されるまで、彼らはあなたに何も借りていません。



不正確な評価は、それを持たないよりも良いことを従業員に説明します。 それ以外の場合、テストリードとして、あなたは何も知らず、リソースなどを相関させることはできません。 彼らが間違いを犯した場合でも賞賛してください。 説明：「あなたは2回間違えました。 しかし、私は3でミスを犯しました！」 しかし、ミスを見逃さないで、座って、どれだけの計画が立てられていたか、実際にどれだけ時間がかかったか、大きな失敗があった場所、そして最も時間がかかったものを比較してください。 最も重要なことは、この分析であり、その人自身が考慮していないことに気づくときです。 ここでは、何も忘れないように作品の分解が必要です。



ここで私たちを助けることができます- 「テスターのために私を忘れないでください 。 」



1.習熟/研究;

2.監査仕様。

3.テストドキュメント（チェックリスト、テストケース）の作成。

4.データの準備;

5.テストの実行+プログラマーからの推奨。

6.バッファー/リスク。



私たちが最初にしたことは、職場の全員にそれを掛けることでした。 バグの評価とタスクの評価に適しています。 トップレベルであり、グローバルなタスクに適しています。



そして、これは、特に明日までに20の大きなタスクのプロジェクトを評価する必要がある場合に、非常に大きなタスクを評価するテストリードと専門家向けです。







すべてのテスターに​​行くのではなく、最初に経験したテスターに​​行き、「これがどれくらいかかるかを見積もろう」と尋ねます。 何も忘れないように、このような推定チェックリスト（評価用チェックリスト）。 プロジェクトごとに、彼は自分のプロジェクトを持っています。 使用するすべてのタイプとテストのリストを投げるので、要件の分析、クライアント、プログラマーとのコミュニケーション、文書化、テストケースの作成、テスト計画-に費やす時間を考慮してください。 そして、必要なものと不要なものをチェックシートに記入します。



次の問題は、 評価したくないということです。 これらの人々と何をすべきか、しかしあなたは本当に必要ですか？



すべての評価を自分で行い、計画に使用します。 スキルを向上させる+どれだけうまく予測できるかを知るのは興味深い。 タスクを見て評価するほど、評価が上がれば上がるほど、テストリードにとってより重要になります。 チームを驚かせて、チームが知らないことを予測できることを示してください！



計画は評価以外のリソースの最適な割り当てであると考えてみましょう。 評価なし-計画は意味がありません。



計画-目標を達成するためのリソースの最適な割り当て、将来の目標とアクションの設定に関連する一連のプロセス。 （c） ウィキペディア



誰が評価を行うかが重要です。 不確実性は、あなたとあなたのテストリード、マネージャー、製品マネージャーに非常に影響します。これらの要因はすべてプロジェクトの完了時間に影響します。







テストリーダーとして、どのように財政を担当していますか？ すべてが非常に簡単です。 プロジェクトに4人のテスターを含める場合、給与は4人に支払わなければなりません。3人であれば、それよりも少なくなります。 これは平凡なレベルですが、あなたの会社が期限切れのプロジェクトのために罰金を科せられると、そこの財務指標は非常に大きくなります。 したがって、これらの各インジケータはプロジェクトの終了時間に影響します。



したがって、これらの各インジケータはプロジェクトの終了時間に影響します。 そして、そのような状況で、私はそのような難しい質問に答えるのに役立つ何かを持っていたいです。



ここでは、ネットワークスケジュールとガントチャートが役立ちます。







スライド上の作業スケジュールは、期間とタスクで構成されています。 これは、タブレットをじっと見る必要がないように作業を視覚化するための図です。 作業しやすい美しい図を見る方が便利です。



これらすべてが一緒になって、クリティカルパスメソッドを作成するのに役立ちます。







グラフの理論があります-これは、最も重い重みでパスを渡す方法です。 この場合、「スケール」は推定値です。 パスは作業で構成されています。



プロジェクト管理の方法でこれを最大化すると、プロジェクトの開始からプロジェクトの終了までの一連のタスクになり、時間に余裕がありません。 赤はクリティカルパスです。 これらの作業を完了するための期限に少なくとも1時間違反すると、リリースは1時間遅れます。2日間であれば、リリースは2日間遅れます。 なぜこれが必要なのですか？ テスターがパスの途中であなたのところに来て休みを求めるので、このパスにあるタスクを理解することはあなたにとって重要です。 クリティカルパス法は、プロジェクトで何が起こっているかを理解するために、このようなクリティカルな作業の開始を予測する機会を与えてくれます。







計画を立てるためにとる主なステップを説明しましょう。



1.テストするものを決定します。

2.見積もりを行います。

3.ネットワーク作業スケジュールを記入し、ガントチャートを作成します。

4.作業間の論理的な接続を停止します。

5.リソースを割り当てます。

6.クリティカルパスを特定します。

7.リソースリンクを添付します。

8.リソース（パフォーマーの数）を最適化します。



これを理解することは非常に重要です。 多くの場合、このようなスケジュールにより、リソースの関係と、4時間で100人のテスターに​​よる400時間の計画を完了することができないことを理解できます。 データの準備、プロジェクトの調査、要件の分析、プログラマーとのコミュニケーションに時間がかかります。



さまざまなプログラムのグラフオプション。



















私たちは皆考慮に入れましたか？ そうでない場合、何が残っているのか、どこでそれを考慮するのか？



忘れないでください：



休日、休日;

虫

• 機関の時間;
• 回帰時間;
• 統計的近似;

緩衝液

• タスクまたはプロジェクトですか？
• ％？

リスク

出演者

• 分離;
• 経験;

バージョンが最初でない場合。



マネージャーはこれを自分のバッファーで考慮します。 また、テスト環境がないという事実も含まれている可能性があり、プログラマはバグを修正するために別の技術を使用しました。



多くの場合、テスト用のプロジェクトが既にバッファなしで提供されている場合に問題が発生するため、プログラマとテスタ用のバッファを個別に計算すると、誰がそれを使用したかが明確になります。



すでに計画している人は、リソースを共有している場合、プロジェクトのグループにガントチャートを使用できないことに注意してください。







共通のアーキテクトがいて、すべてのプロジェクトで彼が必要な場合、これはうまくいかないかもしれません。



リソースがすべてのプロジェクトで同時に交差しない場合の利点。 それらの多くがあるので、あなたはあなたのリソースを管理し、それらがどこにあるかを理解できます。 しかし、これがあなたの会社にとって意味があるかどうかはあなたにとって重要です。



メリット

• 数値推定に基づいて、プロジェクトのコストと条件を計算できます。
• リソース使用率のアイデアを提供します。
• プロジェクト間でリソースをより効率的に分配できます。
• プロジェクト用語を最適化するためのツール。
• これは、管理者と顧客向けの視覚的な文書です。
• 顧客が視覚的なチャートの使用に興味を持っている場合、あなたは彼への義務を遵守する方が簡単だと言うことができます、あなたは明確な議論を持っています。

顧客が興味を持っている場合 ：

• 義務を順守します。
• 損失は​​発生しません。
• 機会の拡大。
• 品質を節約しません。
• 品質テストのフルタイムとなり、恥ずかしくないような製品を提供します。

顧客が興味がない場合：

• リダの神経を救います。
• チームを開発します。
• チップを紹介します。
• イニシアチブを開発します。
• 品質をお楽しみください。
• 品質を改善し、チームの改善に時間を費やし、テストクラブ、社内トレーニングプロジェクトから誰かを招待し、最終的にドキュメントを作成できます。

非常に明確に管理する必要があります。 この計画の変更にはどれくらい時間がかかりますか？ これは柔軟な計画なので、変更は週に1回行う必要があります。 これが自動化されている場合、時間は最適化のみに費やされます。 このプロセスが自動化されていない企業では、「タスクにどれだけの時間が残っていますか？」という質問があります。 彼らは何がそれを妨げたのか興味がなく、残り時間と計画の変更方法が重要です。 したがって、テスターが20人いる場合は、20行を変更する必要があります。



さて、 結論 ：



1.計画-以下の一連のプロセス

• a。 テスト戦略の作成。
• b。 人件費の見積もり;
• c。 予測のタイムライン。
• d。 リソースの割り当てと最適化。
• e。 制御タスク。

2. 人件費の評価と期間の見積もり-同じことではありません 。



3.ほとんどのステップは自動化できます。



すべてが自動化できるため、 計画は素晴らしいです。スケジュールのスケジュールと人件費の見積もりは同じではないことに注意してください