導入
ハブロフスク在住の皆さん、こんにちは。ちょうど今、私はフィンテック企業の QA リード欠員のテスト タスクを解いていました。最初のタスクは、電気ケトルをテストするための完全なチェックリストとテスト ケースの例を含むテスト計画を作成することで、簡単に解決できます。
完全なチェックリストを備えたこれより優れたテスト計画を考えるのは困難です。
しかし、2 番目の部分は、「テスター全員の効率的な作業を妨げる、すべてのテスターに共通する問題はありますか?」という質問であることが判明しました。
最初に思いついたのは、テスト中に遭遇した多かれ少なかれ顕著な問題をすべてリストアップし、小さな問題を取り除き、残りを要約することでした。しかし、帰納法では「全員」には当てはまらず、せいぜい「大多数」のテスターにしか当てはまらない質問に答えることができることにすぐに気づきました。そこで、演繹的に反対側からアプローチしてみようと考えた結果、こうなりました。
定義します
新しい問題を解決するときに私が通常最初に行うことは、その問題が何であるかを理解しようとすることです。そのためには、問題を提起する単語の意味を理解する必要があります。理解すべきキーワードは次のとおりです。
- 問題
- テスター
- テスターの仕事
- テスターの効率
ウィキペディアと常識に目を向けてみましょう。
(古代ギリシャ語 πρόβλημα) 広い意味では、研究と解決を必要とする複雑な理論的または実践的な問題。科学において - あらゆる現象、物体、プロセスの説明において対立する立場の形で現れ、それを解決するには適切な理論を必要とする矛盾した状況。人生において、問題は人々が理解できる形式で定式化されます。「何を知っているが、どうやって得るべきかは分からない」、つまり、何を取得する必要があるかはわかっていますが、それをどのように行うかはわかりません。 。遅い時間から来ます。緯度。問題、ギリシャ語から。 πρόβλημα 「前方に投げられ、前に置かれる」。 προβάλλωより「前に投げて、前に置きます。非難"。
実際、「問題」=「対処する必要があるもの」というのはあまり意味がありません。
- コンポーネントまたはシステムのテストに参加するスペシャリスト (すべてのテスターに関心があるため、タイプには分けません)。その結果は次のとおりです。
— テストに関連する一連のアクティビティ。
(緯度有効) - 達成された結果と使用されたリソースとの関係 (：2015）
- 定性的または定量的に表現された、一連のアクション (結果) またはイベントの結果。考えられる結果には、有利、不利、利得、損失、価値、勝利が含まれます。
「問題」もそうですが、仕事の結果出てきたものにはあまり意味がありません。
- 一人または複数の人々が何らかの活動を行う定量的に測定可能な可能性。特定の変換を使用して目的の結果を得ることができる条件。テスターは個人であり、重要資源の理論によれば、各人は 4 つの経済資産の所有者です。
現金（収入）は再生可能な資源です。
エネルギー（生命力）は部分的に再生可能な資源です。
時間は固定された資源であり、基本的に再生不可能です。
知識（情報）は再生可能な資源であり、成長することも破壊されることもある人的資本の一部です。.
この場合の効率の定義は完全に正しいわけではないことに注意してください。使用する知識が増えるほど効率は低下します。したがって、私は効率を「達成された結果と費やしたリソースの比率」として再定義します。その場合、すべてが正しいことになります。作業中に知識が無駄になることはありませんが、テスト担当者の唯一基本的に再生不可能なリソース、つまり時間のコストが削減されます。
ソリューション
そこで、私たちはテスターの作業の有効性を損なう、テスターの全体的な問題を探しています。
テスターの作業に費やされる最も重要なリソースは時間です (残りは何らかの方法で時間に還元できます)。効率の正しい計算について話すためには、結果も時間に還元する必要があります。 。
これを行うには、テスターが作業を通じて実行可能性を保証するシステムを考えてみましょう。このようなシステムは、チームにテスターが含まれるプロジェクトです。プロジェクトのライフサイクルは、次のアルゴリズムで大まかに表すことができます。
- 要件の処理
- 技術仕様の策定
- 開発
- テスト
- 本番環境へのリリース
- サポート (項目 1 に移動)
この場合、プロジェクト全体を、同じライフサイクルを持つサブプロジェクト (機能) に再帰的に分割できます。
プロジェクトの観点から見ると、プロジェクトに費やす時間が短いほど、その実装はより効果的になります。
したがって、プロジェクトの観点からテスターの可能な最大効率の定義にたどり着きます。これは、テスト時間がゼロのときのプロジェクトの状態です。すべてのテスターに共通する問題は、この時間を達成できないことです。
これに対処する方法は？
結論は非常に明白であり、長い間多くの人によって使用されてきました。
- 開発とテストはほぼ同時に開始および終了する必要があります (これは通常、部門によって行われます) ）。理想的なオプションは、開発中のすべての機能が、準備が整うまでに自動テストですでにカバーされており、ある種の .
- プロジェクトの機能が増えるほど (複雑になるほど)、新しい機能が古い機能を壊さないことを確認するために費やす時間が長くなります。したがって、プロジェクトが複雑になればなるほど、より多くの自動化が必要になります。 .
- 運用環境でバグを見逃し、ユーザーがそれを見つけるたびに、ポイント 1 (要件 (この場合はユーザー) への対応) から始まるプロジェクトのライフ サイクルをたどるのに追加の時間を費やす必要があります。バグが見逃される理由は一般に不明であるため、残された最適化パスは XNUMX つだけです。ユーザーが発見したすべてのバグは回帰テストに含めて、バグが再び出現しないことを確認する必要があります。
出所： habr.com