「自動化は簡単」という考え方に対処する方法は?


12

タイトルはそれをすべて言います。当社の一部の従業員は、自動化されたテストは「簡単」であり、COMおよびUIテストのスイートを作成するには「1日かかる」と考えています。これに対抗するために何ができますか?

注:自動化を促進する方法については質問していません。それは問題ではありません。ここでは常に自動化されたテストとプロセスが促進され、要求されています。問題は、一部の個人は、自動化が「簡単」でも「高速」でもないことを理解していないことです。


25
これらの人々のいずれかが彼らの主張を証明するために招待されましたか?
Blrfl

2
この種の認識は多くの業界に存在し、変更することはできません。多くの人が従業員を教育するためのアプローチに答えるかもしれませんが、唯一の真の答えはどこかで働くことです。他人の仕事に対する価値が低いと感じる人は決して良いことではありません。
Reactgular

7
関連する可能性がある:督促クルーガー効果
サイモンベルゴ

3
「一度にできると思ったら、席に座り、これをどのように実装するかを教えてください。そうすれば、私はあなたからテストを書く方法を学ぶことができます。この"。
Doc Brown

回答:


5

次回リクエストを受け取ったら、自動化プロセスの多くを時間の塊に分解してみてください。テキストフィールドまたはボタンを押すごとに5分かかることを理解すると、どれだけ時間がかかるかを認識し始めると思います。

たとえば、フィールドに相互依存関係が導入されるようになるのは、たとえば、これが満たされている場合にのみ続行でき、これがそうでない場合は、次の場合を除きます...

なぜ時間がかかるが、「学習」プロセスでそれらを失うほどではないのかを教育してください。


4

私の役割では、特に開発プロジェクトで多くの「xは簡単」な人に出くわしました。私の考えでは、これには3つの理由があります。

1)彼らは自分が話していることを本当に理解していないが、彼らがするように聞こえるのが非常に好きだ。

2)彼らは数冊の本を読んで、何を話しているのか知っていると思う

3)最後に、コンピューターは高速であるため、コンピューターが高速でテストを実行していると考えられます。

これに対抗する確実な方法の1つは、ユーザーを定期的に関与させることです。プロジェクトのコミュニケーション戦略が重要です。有益なことができます。これは、ドキュメント、ワークショップ、または次回の通過時に友好的なチャットで行うことができます。

これらの「x is easy」人の中で最も声高なBAを見つけて、部門で1日間招待するだけで、彼らはあなたが何をしているのかをもっと理解するか、彼らが「神は、私が本当に何について話しているのか本当にわからない、私は間違っていたと思う」と考えて去ります。


2

ソフトウェアは、物事を自動化するビジネスです。

退屈で繰り返しの多い労働集約的なタスクを簡単にするソフトウェアを作成します。レポートの作成、データの収集、他者との通信などを自動化するソフトウェアを作成します。自動テストの作成は、実際にソフトウェアを作成して、他のソフトウェアが期待どおりに動作することを確認するだけです。

同僚がソフトウェアの作成が難しくて時間がかかることを理解している場合、ソフトウェアの作成が難しくて時間がかかることを示すのはかなり簡単です。自動化のすべての利点を無料で入手できればいいのですが、いつものように、後で利点を得るために作業を前もって行う必要があります。

彼らがそれを理解していないなら、あなたは彼らにそれを教えることに取り組むか、履歴書を磨く必要があります。


2
writing software is hard and takes time。小さなコマンドラインアプリの作成は簡単です。スカイネットIAを書くのは難しいです。そのような一般的な声明を伝えることは誰にも納得させません。
サイモンベルゴ

3
@サイモン-それは十分に公正な声明です。これまでに作成されたすべてのソフトウェアが必ずしも難しいわけではありません。私が書いて支払われたソフトウェアの大部分は自明でないもののためのものだともっと考えていました。単純なCRUDアプリのようなものであっても、適切な検証、エラー処理、セキュリティ、レポートなどを確実に行うために時間と労力がかかります。これを書いている間、OPの同僚が非-技術/管理者。これは正しくない場合があり、「ハード」、「簡単」、「高速」のすべての解釈方法に影響します。
Becuzz

コンピューターのプログラミングは難しく、時間がかかります。高価だから
クリスマッコール

2

ほとんどの従業員は、会社の「フロント」(クライアント、ボス、利害関係者が直面している)部分または「バック」(「実際の」作業が行われる)のいずれかで時間を過ごします。これら2つの機能は異なり、ほぼ反対です。(そして、両方で働いた人はほとんどいません)。その結果、2つのグループの間でしばしば誤解が生じます。

たとえば「フロント」の人々を教育する最良の方法は、1人または数人に「バック」で1日を過ごすことです。「...の人生の1日」を完了すると、1日で何ができるのか、自動テストを実行するのにより多くの時間と労力がかかる理由について、より現実的なアイデアを得ることができます。同様に、「背中」の人々は、「前」で1〜2日の恩恵を受けることができます。

「裕福になる方法」で、ジョン・ポール・ゲッティ(当時の大物)は、そのような「クロストレーニング」を提唱しました。彼の見解では、製品が製造された組立ラインに時間を費やしたセールスマンは販売の仕事をはるかによくし、同様にクライアントと1日を過ごしたエンジニアは「デバッグ」の仕事をよりよくするでしょう。


2

問題は、一部の個人は、自動化が「簡単」でも「高速」でもないことを理解していないことです。

ここでのあなたの前提に同意しません。

私は、単体テスト、統合テスト、UIテストのいずれであっても、自動テストの大提唱者です。自動化されたテストを実装するために利用できる多くの優れたツールがあります。

次の例に基づいて、自動テストと手動テストを比較してみましょう。

Webアプリケーションで、ブラウザを使用して既存のユーザーの「パスワードの変更」機能をテストします。

手動テスト

  • Webアプリケーションを起動します
  • ブラウザを開きます
  • くそー、エラーがあります。どうして?ああ、データベースを起動するのを忘れました!
  • さて、ウェブアプリケーションをシャットダウンしてください
  • データベースを起動する
  • Webアプリケーションを起動します
  • ブラウザを更新する
  • うーん、テストユーザーのパスワードは何でしたか?
  • データベースを見てみる
  • ああ、usersテーブルは空です!新しいユーザーを作成する必要があります。
  • Webアプリケーションに新しいユーザーを登録する:ユーザー名、パスワード、メールアドレスを入力する
  • 新しいユーザーでログインできないのはなぜですか?ああ、メールの確認リンクをクリックする必要があります!
  • さて、ユーザーに「test@example.com」のようなメールを送信しました。データベースに移動して、「アクティブ」列を「はい」に設定します。
  • ログインする。今回は動作します!
  • うーん、何をもう一度テストしたいのですか...?

簡単?あんまり。プロセスには多くの落とし穴があります。

速い?いいえ。手作業には時間がかかります。

ここで、自動化されたテストを作成してみましょう。

  • データベースとWebサーバーを自動的に起動するためのプログラミング言語用のツールを見つける必要があります。研究と実装には時間がかかります。
  • テストを開始するとき、データベースはクリーンな状態である必要があります。スクリプトの作成には時間がかかります。
  • テストを書く必要があります。ユーザーが必要なので、テスト用に新しいユーザーを登録する必要もあります。時間がかかります。
  • 最後に、テストするものを書くことができます:ユーザーのパスワードを変更します。Browser-testing-toolを使用すると、これは以前のタスクと比較してかなり迅速に実行されます。

簡単?番号!ツールを調査し、それらを実装し、テストのいくつかのバグを修正する必要がありました。

速い?番号!手動テストを行うよりもさらに時間がかかります。

ただし、ここには大きな違いがあります。将来のテストでは、リストの最後の箇条書きであるテスト自体を書くだけで済みます。すべての調査と初期化スクリプトは、さらにテストするために行う必要はありません。

そして、テストを作成したら、簡単に開始できます。数秒(またはデータベースとWebアプリケーションの起動に時間がかかる場合は数分)で、「パスワードの変更」ルーチンが機能するかどうかを確認できます。バグがある場合は、修正して、テストを再度実行します- バグが修正されたかどうかがすぐにわかります。早くて簡単

自動化されたテストの作成は、そもそも簡単でも高速でもありませんが、実行は簡単です。

そして、これは投資した時間が戻ってくるポイントです。


偉大なポストが、大きな問題:何が起こるの後にログインしますか?このロジックのほとんどは、本当に不安定になり始めます。
joshin4colours

0

一般にテストは簡単ではなく、そうすべきでもありません。ボーイングやメルセデスが製品のように厳密に製品をテストしなかった場合、訴訟のために破産するか、そのような低品質のアイテムを販売するために廃業するでしょう。ハンドルがバラバラになったり落ちなかったりすることを知って、時速70マイルで車を運転しますか?

それらの人々が誰であるか、またはその理由を理解せずに、考え方に対処する方法を提案することは非常に困難です。ほとんどのマネージャーとディレクターはコストを考え、生産物によって判断されます。この基準を使用すると、テストに時間を費やすことを正当化することが非常に難しくなります。これがあなたに当てはまる場合、長期的には有益であるとしてこのタスクを提示する方法を見つける必要があります。

ソフトウェアが有形ではないからといって、構築されたシステムが機能しないことの影響を考えずに逃げることができるというわけではありません。Amazonには自動化されたテストがあり、ウェブサイト/サービスが失敗した場合のコストへの影響をよく知っている人がいるに違いない。


0

2 +2 = 4は、誰もが理解できる最も単純なコードの1つです。そして、あなたは簡単に理解する方法を見ることができます。しかし、これは「簡単な」方程式であることを意味するものではありません。単純な方程式に到達するために必要な抽象化のレベルは非常に複雑です。ソフトウェアとソフトウェアのテスト方法でも同じことが起こります。コードを必要とする抽象化のレベルには多くの作業が必要です。

良い習慣がクラスとオブジェクトの再利用につながることは事実ですが、同様に、この状態に到達するには時間と労力を費やす必要があります。


これは質問が尋ね答えていない
GNAT

0

この質問には2つの側面があります。

あなたの側では、あなたはあなたが良い仕事をしていると思うように見え、「自動化は簡単」グループは彼らが何について話しているのか知らないようです。

彼らの側では、あなたの言うことから、彼らは自動化されたテストが(彼らの見解では)長い時間をかけて作成されるのを見る。

この距離から先に進む必要があるので、誰が「正しい」か、誰かが「正しい」かどうかはわかりません。

自動化に対処する方法は簡単です

彼らと話してください。どうすればそれを改善できるかについて、正直に意見を求めてください。それらを関与させ、関与させます。それは彼らが本当に良い何かを提供しているかどうかを知る唯一の方法です。たぶん、彼らはする価値のある貢献をしているので、あなたは勝利を獲得することができます。

プログラミングと自動化されたテストがどのように機能するのか、生産性を向上させるための現実的なアイデアがない場合は、積極的に関与して、それがどのように行われ、どこに行くかを示すことができます。謙虚で前向きで、彼らの意見やアイデアに感謝します。彼らが言ったことを考えてみてください:多分彼らの提案はあなたのために異なる考え方を引き起こすでしょう。もしそうなら、そのフィードバックを彼らに与えてください。謙虚で前向きであることで、あなたもそれを勝ち/勝ちにすることができます。

彼らと話す前に、テストをどのように構築、実行、管理するかを考えてください。どのフレームワークを使用していますか?より良いものが他にありますか?適応する「標準」ボイラープレートはありますか?テストの構築をより自動化できますか?何があなたを妨げていますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.