こんにちは
ビジネスは測定するのが大好きで、経営陣は透明性が大好きです。従業員はこのペーパーワークがすべて好きではありません。特に、彼らが何を望んでいるか分からない場合は... 最も頻繁に発生する5つのリスクを与えます。これらのリスクは過小評価できず、すべてのテストとプロジェクトの失敗につながる可能性があります。 また、メトリックの例を示します。メトリックのフェアユースは、あなた、上司、およびビジネスを落ち着かせます。
これらのリスクに加えて、グローバルなものがあります：テスト戦略の間違った選択、フレームワークとテストの作成におけるOOPの欠如...しかし、それらは最初のリスクとは異なり、テストのコストの増加のみをもたらし、プロセスとして、プロセスとして、イデオロギーとして、ツールとして失敗しません製品の品質を確保し、最終的に顧客ロイヤルティを確保して収益を上げます。 スペシャリストとしてこれを経営陣に説明し、開発者から敬意を払うことができれば（獲得する必要があります:)）、選択したアプローチと戦略の正確性を全員に確信させることができれば、あなたは正しい道を歩みます。
リスク：
1.テストの自動化が必要でない場合にテストの自動化を組織する場合、多額の資金を投入します
これは、あらゆるプロセスの何よりもまずのリスクです。 特にソビエト後の国々の指導者は、柔軟性に欠けることがほとんどありません。 私の頭の中に、テストの自動化が祝福であるという考えがあれば、それは必要なところと必要でないところに押し込まれます。 テスト自動化への実際の投資収益率は、せいぜい2回目のリリースから生じることを完全に忘れています。 すべての自動化が高品質のカバレッジを提供するわけではなく、モチベーション、時間、お金が単に廃棄されることをビジネスに説明する方法を学ぶ必要があります。
2.クラウドでCIを追跡する何万ものテストを作成する場合、品質の問題で自分自身を欺きます。
これは最も一般的なアンチパターンです。 これについて詳しく説明します-他のパターンとアンチパターンについてはこちらで読むことができます -青色のセクションは、単体テストを作成するすべての人にとって最も興味深いものになります。 これらは、すでに公理に起因している可能性のある長い定式化されたアンチパターンです。
冗談はありません-重いテストや嘘つきテストなどを許可すると、プロジェクトに失敗することになります。 何度も、さまざまな企業のテストプロセスの監査に参加して、この現象に遭遇し、テストのために自動化エンジニアと管理者がテストを書くことを思いとどまらせました。 一部の人は耳を傾け、実装前に多くの悪いことをすくい取り、一部の人は耳を傾けませんでした-同じ日に3つのプロジェクトがクラッシュしましたが、それぞれ約8,000千のグリーンテストがありました。
CI in the cloud-はい、私はこのトピックが大好きです。 すべてのテストを10分間実行する場合、継続的統合サーバーで機能テストを実行する理由は何ですか？ リリースが1日に1回ではなく1か月に1回リリースされる場合、なぜCIなのか？..テスト自動化の専門家と同様に、TeamCityでこの奇跡をすべて実行するスクリプトを作成するスキルを習得しましたが、どのチームに所属していても、ユニットテストをビルドして実行する以外にCIを使用する必要はありませんでした。 すべての機能テストは、コミット後ではなく、コミット前に追跡する必要があります。 私はこれを確信しています...このアプローチでは、チーム間の作業に問題があります。 しかし、それらはプロセスの有能な組織によって解決されます。
3.隔離された入力をテストに使用する場合、本番環境の重大なバグをスキップします
前の記事で、彼らは単体テストと機能的な自動テストを分離することを提案しました。 私はまだやろうと試みますが、ほとんどの場合、データを分離すべきではないと思います。 テストの入力動作にランダム性を導入できる場合、それを含める必要があります。 ユーザー（メソッドの呼び出し側、単体テストに関しては）は常に平均して、特定の範囲のデータでアクションを実行します。 この分布に依存する入力データプロバイダーを作成して、すべてを現実に近づけることができます。
たとえば、私は最近、「特徴」に遭遇しましたが、これは私たちの国ではっきりと表れています。 支払い要求に応じて、銀行が16文字を超えるカード番号を受け取った場合、システムはひざまずきました。 はい、もちろん、これは16桁のカードの世界では非現実的ですが、すみません、銀行の顧客がカードを再発行し、サービスの通常の顧客を次第に競合他社に任せ始めると、ビジネスはお金を失うことになりますそうではありません。
レム：Javaを愛する人にとっては、リフレクションを使用すると、最終的にはプリミティブのツリーにすぎないため、あらゆるクラスのオブジェクトの初期化子を作成できることは明らかです。 知っている人はほとんどいませんが、長い間、すべてが素晴らしいpodamライブラリに実装されています。 以下に使用例を示します。
PodamFactory factory = new PodamFactoryImpl(); // MyClass myPojo = factory.manufacturePojo(MyClass.class);
注釈を使用して値の範囲を設定し、独自の生成戦略を作成することもできます。 一般的に、魂が望むものすべて。 ツリー全体でセッターを呼び出し、RandomおよびRandomUtilsを使用してオブジェクトにデータを入力するよりもはるかに便利です。 MockitoでPodamを使用すると、スタブによって返されるオブジェクトの簡潔な初期化に関して驚くべき結果が得られます。
4.テスト用に間違ったツールを選択すると、テクノロジーと専門家に依存するようになります。
スズメを撃つ銃の愛好家がいます。 習得しにくい技術を選択することはできますが、これらすべてをサポートできる専門家を見つけることは、事実上非現実的です。 テストの専門家がフレームワーク、ツール、スクリプトロゼンジ、あいまいなクリッカー、クラウドサービスの使用を開始する場合...これらに追加された場合、これらのテクノロジーは有料であり、購入する必要があります...常に開始することが判明しないかどうか自問してくださいこれらすべての良いことに、これらの専門家に依存していますか？ このイデオロギーを継続できる市場の人々、トレーニングの費用などを見つけることができますか？
5.開発者がテストの自動化が必要な理由を理解していない場合、これらの問題に協力せず、すべてを義務と見なすと、テストの自動化は無効になります。
監査するとき、私は常に開発者との会話から始めます。 5人の開発者のうち3人が、これらのテスター（手動でも自動でもかまいません）が給与を食い尽くしていることを確信しています。 「なぜあなたはそう思いますか？」という質問に対して、答えは常に異なりますが、本質は同じです-「私たちはとても美しいので、それは必要ありません」。 5人中1人の開発者は、テストの自動化が必要であり、社内で既にこれらの質問を100回提起しているが、同僚からのサポートが得られないと考えています。 もう1つは既に長い間送られており、彼は自分でテストを書いています。彼はそれを必要だと考え、誰にも何も押し付けたくないからです。 そのため、彼は仕事の質を確保しています。 そのような環境では、自信のある開発者のテストに対する態度をやり直すことから始める必要があります。 そうしないと、テストが追跡されないため、テスト自動化プロセスを設定することさえできない場合があり、たとえそうであっても、誰も結果に注意を払いません。
指標
テスト自動化のメトリックは、基準を満たす必要があります。
- 客観性
- 測定可能性
- 理にかなっているはず
- 簡単にアクセスできるデータに基づいて
- テスト自動化を改善するための指示を見つけるのに役立ちます
- シンプルでなければなりません
始まった。 100％の乗算は省略します-怒らないでください。
1.自動テストの割合。
はい...残念ながら、すべてを自動化する必要はなく、すべてを自動化できるわけでもありません。 自動化するテストのリストがある場合は、測定するのが論理的です
PA（％）=自動化できるテストの数/合計テストの数。
2.自動化プロモーションの割合
AP（％）=自動テストの数/自動化できるテストの数。
このメトリックは、長期にわたる自動化プロセスを検討する際に非常に役立ちます。 この割合が新しいスプリントごとに低下する場合、これが起こる理由について考える必要があります。ビュー、アーキテクチャを修正し、必要に応じてチームに人を追加するなど。 もちろん、私たちは100％のためにここで努力しています
3.プロモーションテスト
TP =書き込まれたテストの数/期間
パフォーマンスの変化を判断し、プランのカバレッジのタイミングを推定するための便利なメトリック。 パフォーマンスが範囲内で変動する場合-これは正常です。 急に落ちたり、突然飛び出した場合は、質問する価値があります。 最初のケースでは、専門家がモチベーションを失ったか、作業の複雑さの評価に体系的なエラーがある可能性があります。 第二に、作品の外観は、小切手の強い粉砕の結果として作成される可能性がありますが、これも良くありません。
4.カバレッジの割合
TC（％）=筆記テストの数/要件の数
カバレッジの深さを評価することになると、あいまいだが有用なメトリック。 割合として逆比例を採用するのがおそらくもっと良いでしょう...例えば、アジャイルの機能テストなどで正しく使用すれば、数か月以内にいくつのテストが行われるかを見積もることができるだけでなく、何かを最適化する時期であることも理解できますこれらの同じテストの実行に必要な時間を短縮します。
5.欠陥の密度
TC（％）=オープン欠陥の数/製品の合計サイズ
製品のサイズを評価する合理的な機会がないために無視されている非常に重要な指標。 平均して3行のコードにそれぞれ1つの欠陥があるという古典的な考え方があります。 私にとっては、これはナンセンスです。もしそうであれば、テストは役に立たないでしょう:)一般に、スクラムプロセスでは、この製品自体のサイズに合わせてストーリーポイントを追加できます。 いずれにせよ、これは特に製品が外出する準備をしているとき、チーム内と外部の両方で非常に有用な指標です。 一般に、アジャイルテストの自動化は別の歌です。 興味がある人はここでそれについて読むことができます。
6.欠陥の除去の効率
DRE（％）=テスト中に見つかった欠陥/（テスト中に見つかった欠陥+実稼働中のユーザーが発見した欠陥）
非常に重要なメトリック、それなしではどこにもありません。 自動テストの実行結果に従って、たとえば15の欠陥がある場合、それらを修正し、ユーザーにロールアウトした後、さらに15の新しい陰湿なものに気づいた場合、悲しみは上記の指標に従わなかったことを意味します...この割合を受け取ったので、それを上げる必要があります100％ そのため、このメトリックは、展開後の時間内に考慮する必要があります。 新たに発生した欠陥のテストはすぐに記述し、合格するのではなく、合格する必要があります:)
結論：
管理者用ではなく、自分用の指標を考えてください。 自分だけでなく他の人にも、自動化プロセスの改善がどのように行われるかを説明できるようにしてください。 これらまたはこれらの技術が提供するものを、他と比較して、テスト自動化で何も理解していない人が理解できる数でこれを定式化してください。
2013年2月6日、Journal of Mathematical Sciences（ニューヨーク）、2013年、188：6、758–760に記事を公開しました。 ここで要約と始まりを見ることができます 。
詳細については説明しませんが、定理の1つの結果として、失敗したプロジェクトで頻繁に現れる例を示します-開いている欠陥の数の以前の最大値= xがxのオーダーの値に達する場合2、プロジェクトは欠陥の数の均一な分布の状態にあります。 つまり、この傾向を確認したら、すべての機能が機能しなくなるという事実に備えて、非常に迅速に準備してください。 このパターンは実際に何度も確認されており、最大の欠陥があるだけでなく...
率直に言って、技術サポート契約を結んでおり、顧客に他の代替手段がないという事実から多くのお金を稼いでいるので、品質が悪いほど良い会社を知っています。 このような企業は、テストの自動化、メトリック、および品質を必要としません。 この記事は、競争でロイヤルティとユーザーマネーの権利を獲得しようとしている他のすべての企業を対象としています。