メニュー

テストする時間が足りない場合はどうすればよいですか？

what do when there isn t enough time test

問題を排除するために楽器を試してください

テストサイクルの途中で、テストするのに十分な時間がないことに気付くことがよくありますか？そもそもすべてを管理していましたが、すぐに緊急時対応計画の「テストする時間が十分にない場合はどうすればよいですか？」に到達します。セクション。

私も行ったことがありますが、面白くありません。 :)

私はこれについて長くて一生懸命考えました。どうしてこんなにうまく始まったものが、こんなにひどく、こんなに早く下がるのだろう。そして、これが私の分析です。

=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください

学習内容：

テスト時間はどこに行きましたか？

テストする時間が足りない

Chromeに最適なポップアップブロッカーは何ですか

まず、なぜこれが起こるのですか？多くの理由–そのいくつかは次のとおりです。

＃1）誤った見積もり ：

不正確な期待から始めた場合、物事は必ず失敗します。適切なテスト見積もりでは、次のことを考慮に入れる必要があります。

  • 準備作業の時間– 次のようなタスクについて話します。
    • 回帰スイートを特定してまとめる
    • テストデータの作成
    • テストの準備状況を判断する時間（例：煙/健全性テスト）など。
  • テストケースのメンテナンス ：テストケースは長期使用資産です。実行中に必ずマイナーアップデートが行われます。新製品の場合、テスト実行時間の最大30％をこれらのマイナーなメンテナンスタスクに割り当てることをお勧めします。すべてのチームとプロジェクトが30％を必要としない場合もありますが、このタスクにはある程度の時間と労力を割り当てます。
  • これに /探索的テスト –スクリプト化されたテストの数は、テスト推定数の主要な分母です。ただし、この世界のテストチームは、モデルが主にスクリプト化されている場合でも、ソフトウェアの探索を拒否することはありません。
  • 報告/コミュニケーション –これには、トリアージ/スタンドアップミーティング、作業管理ツールの更新などが含まれます。
  • 不測の事態の要因： 標準では、元の見積もりに対して25〜30％のバッファを推奨しています。しかし、チームがそれを買う余裕はめったにありません。それでも、可能であれば、少し呼吸の余地を残してください。
  • チームとその機能： 新しいチームがある場合、またはチームが初めてツールを使用する場合は、トレーニングのために時間を取っておく必要があるかもしれません。作業しているチームに基づいて見積もりを調整します。

おすすめの読み物=> テスト見積もりの​​成功と方法の詳細については、これを確認してください

＃2）不安定なビルドおよびその他の技術的な問題：

  • 煙/健全性テストの失敗 ：QA環境への展開後にAUTの基本テストが失敗した場合、QAチームがテストの実行に向けてできることはほとんどありません。これが発生している間、他のタスクに取り組むことができるのは事実ですが、それでも テストサイクル 時間。したがって、これは時間の浪費の主な原因です。
  • テストデータ 利用できません ：本番環境のようなデータは、すべてのテストプロジェクトに必須です。これをQA環境に時間どおりに導入できないことも、もう1つの阻害要因です。テスターはこれを回避できる場合があります 独自のテストデータの作成と管理 、ただし、時間がかかり、常に適切であるとは限りません。
  • 環境問題 –ビルドが失敗したデプロイメント、サーバーがタイムアウトし続ける、そのような問題の多くがテストサイクルを食いつぶします。これはおそらく、一部の企業（すべてではない）が効果的なQAのための優れた生きたような環境の重要性を損なうという事実に起因しています。彼らはしばしば、容量の少ないサーバーやmake-doセットアップを回避しようとします。これは本当に短時間の修正であり、誰にも有利にはなりません。実際、テストの品質と貴重なテスト時間の損失を犠牲にする可能性があります。

＃3）関係するすべての当事者間の合意の欠如：

これは、アジャイルまたは 安全 サークルが緊密であるため、多くのチームは、Dev、Ops、およびQAが相互に成果物を受け取ることになっている時期について、意見の不一致や誤解に苦しんでいます。したがって、遅延します。

コミュニケーションの微妙さを理解するには、これを確認してください => ビジネス、開発、QAがどのように連携してプロジェクトを完了することができるか

問題がわかったので、これを修正するいくつかの方法があります。

テスターはどのようにしてテストに十分な時間を得ることができますか？

＃1）正確に見積もります。 疑わしい場合は、妥当なマージンで過大評価しますが、過小評価しないでください。チーム、ツール、プロセスに基づいて見積もりを調整することを忘れないでください。完了したら、公式の承認を求めて、全員が気づき、ループにとどまるようにします。

＃二） 履歴データを考慮に入れる– テスト管理ツールはあなたの親友です 。

  • 以前のリリースのテストサイクルにはどのくらい時間がかかりましたか？
  • どのような問題が前のテストサイクルの中断を引き起こしましたか？
  • ほとんどのテストケースは、合格するまでに何回実行されましたか？
  • どのような欠陥が報告されましたか？
  • テストが中断された原因となった欠陥は何ですか？

＃3）これらの質問をし、それに応じてクランチタイムに計画します。

  • あなたのプロジェクトは重要な機能ですか？
  • プロジェクトのハイリスクモジュールを見つけますか？
  • ユーザーに最もよく見える機能はどれですか？
  • 安全性に最大の影響を与える機能はどれですか？
  • ユーザーに最大の経済的影響を与える機能はどれですか？
  • アプリケーションのどの側面が顧客にとって最も重要ですか？
  • コードのどの部分が最も複雑で、したがって最もエラーが発生しやすいですか？
  • アプリケーションのどの部分がラッシュモードまたはパニックモードで開発されましたか？
  • 開発者は、アプリケーションの最もリスクの高い側面は何だと思いますか？
  • どのような問題が最悪の宣伝を引き起こすでしょうか？
  • どのような問題が最もカスタマーサービスの苦情を引き起こすでしょうか？
  • どのような種類のテストで複数の機能を簡単にカバーできますか？

これらの点を考慮すると、時間の制約が少なくてもプロジェクトがリリースされるリスクを大幅に減らすことができます。

＃4）テスト管理ツールを使用します。 これにより、準備、レポート、およびメンテナンスの時間と労力が大幅に削減されます。

=> 最も人気のあるテスト管理ツールの選択肢のリストについては 、 ここをチェックしてください ：

Webアプリケーションのパフォーマンステストツール

＃5） 誤ったビルド/技術的な問題についてできることはあまりありませんが、役立つ1つのことは、ユニットテストの結果を確認することです。これにより、ビルドが成功したかどうか、どのようなテストが失敗したかがわかります。そのため、車輪の再発明は行いません。

もしあなたの テスト管理ツールはサポートします CI統合 、その情報を手間をかけずに利用できるので、アプリケーションの安定性をよりよく理解できます。

＃6）生産性と進捗状況を頻繁に測定する 。外部チームの利益のためだけにステータスレポートを成果物にしないでください。毎日の目標とそれを達成する能力を注意深く監視していることを確認してください。

また、「速度と品質」という古典的な難問に陥らないように注意してください。たとえば、1日に50個のバグを報告すると、非常に生産的であるように見える可能性があるためです。しかし、それらのほとんどが無効なものとして戻ってきた場合は、問題が発生しています。

だから、もう少し監視し、監視し、監視します:)

結論：

最後に、すべての予防策と対策にもかかわらず、まだ時間に追われていることに気付いた場合は、 助けを求める 。

ほとんどのチームは、物事を軌道に戻すために戦争室のセッションに参加する用意があります。

著者について： これらの役立つテストのヒントは、STHチームメンバーのSwatiSによって提供されます。

さて、時間通りに滞在し、品質テストサービスを提供するためのあなたの秘訣は何ですか？また、上記の記事のどの点があなたに共感しますか？

私たちはあなたのフィードバックに感謝し、あなたの読者を大切にします。読んでくれてありがとう！

=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください

推奨読書

^