本格的ではあるが非常に簡単なソフトウェアプロジェクトのトレーニングの難しさや成功する防衛については英語で説明しませんが、研究の結果については説明します。 トレーニングの最後に、仕事にうんざりしていて、まったく違うものが欲しいと思いました。 ご存知のように、時には夢がかなうこともあり、1つの大規模なITオフィスで給与の高いテストエンジニアの地位で3か月のインターンシップを提供されました。 普通の人は拒否しました...
...しかし、私はほぼ1年間そこでそこで働くことを決めました。 私にとって今年は、IT分野における成長、進歩、開発、そして新しい興味深い発見の年でした。 今日、私は別の、ITに劣らない場所で働いていますが、経験は残っています。 そして、私はそれを共有したい。 Habréには、テストについての記事、テストでコードをカバーすること、自動化についての記事、テストに来たばかりで、尊厳を持って仕事をしたり、自動テストやユーティリティを書きたいと思っている初心者向けの情報がほとんどありません。 彼らのために、私は仕事から抜け出すことができた20の原則の概要を説明します。これにより、最短時間でチームリーダーの1人になれました。
1. テスト対象を確認します。 プログラムが属する業界、そのコンポーネントが記述されている手段と言語、使用されているデータベース、使用されているプロトコルを特定します。 使用する国を必ず指定してください。 たとえば、電気通信ソフトウェアをテストして世界中で販売している場合、北米のNANP番号計画について尋ねると便利です。
2. 顧客またはエンドユーザーが誰かを確認します。 自分でエンドユーザーになります。 ITから完全に離れた人々がソフトウェアを使用できることを忘れないでください。彼らの作業スタイルはまったく異なります。 ユーザー自身が何を変更できるか、どのアクセス権を設定できるか、そして理論的にはこれらの権利がプログラムで破られる可能性があることを確認してください。
3.ソフトウェアが相互作用できるデバイスのマップを作成し 、これらのデバイスの組み合わせを整理します。 明らかに、今日のソフトウェアは、さまざまなオペレーティングシステム、さまざまな画面解像度、制御システムなどで実行されているさまざまなデバイスで動作します。ソフトウェアが実行されるデバイスのマップを作成し、主要な技術仕様を書き留め、鉄の可能な組み合わせを考えますおよびソフトウェア。 これにより、作業が大幅に容易になります。
4. プログラムを分割します。 些細なことはありません。 プログラムを徹底的に調べてください：終了ボタンから最新の機能まで。 接続されているすべてのモジュールの原則と依存関係を知っておく必要があります。これは環境をテストしているため、合格すると確実にクライアント側になる膨大な数のバグを特定できます。 たとえば、プログラムのバージョンの1つが終了ボタンに応答せず、十字でのみ閉じられた場合がありました。 バグは見逃され、クライアントのケースとともに返されました。
5. テストの種類について学びます 。 あなたを助ける同僚、本、ウィキペディアがあります。 機能、回帰、健全性、負荷などがあります。 テスト。 遅かれ早かれ、すべての種類に触れ、それぞれの利点を理解することになります。したがって、前世代によって蓄積された原則と秘密に関する知識は害になりません。
6. バグ追跡システムについて知る。 必要なフィールドを表示し、トライアルバグを設定し、責任あるものを調査します。これにより、将来の時間を節約し、100の明確な質問で戻ってこないケースを作成できます。
7. バグトラッカーを読みます。 これはテストの最高の軍事百科事典であり、狭い問題に関する経験が正確に蓄積されています。 問題が最も頻繁に発生する場所を確認し、重要度と労働集約度で分類します。 これは、職業に精通するための優れたツールです。
8.実際にバグではない場合でも、発生したすべての脆弱性を記録します。 そのような場所は、しばしばプログラムにエラーを引き起こす可能性があります。 次のバージョンのテストを開始するたびに、独自の経験の参考書を開いて補足します。
9. 重大な状況を再現します。 バグを喜ばないでください。 最初に、それを数回再生し、考えられる原因を分析し、再生条件（機器、時間、手順）を慎重に説明します。 これは、開発者がエラーを再現し、発生の原因を理解するのに役立ちます。
10. ログがある場合は、 監視します。 テスト対象のプログラムが書き込めるログを必ず収集してください。 これらは必ずしもコンソールの複数ページのログではなく、Webのハングページ、エラーウィンドウ、エラーコードのある行です。 情報をコピーまたはダウンロードできない場合は、スクリーンショットを撮ります。 ケースで受け取ったすべての情報を添付ファイルの形式で作成します。開発者は、どのようなウィンドウが表示されたのかを知る必要はありません。 さらに、バグが再生されない場合、スクリーンショットまたはドロップのあるログが存在することが理由のあるケースになります。
11. 広く考えます。 可能であれば、ソフトウェアは別のクリーンなコンピューターやガジェットで研究生活を送ったり、競合他社を調べたりしないことを忘れないでください。 おそらく、他の誰かの機能を研究した後、外部からは自明ではなく魅力的な何かがより見えるようになります。 または、良い機能を実装することだけを提案できます。
12.テスター、開発者、マネージャーなどの同僚と相談してください 。 彼らは著者であり、ユーザーおよび専門家としての経験の源です。 特定の何か（ハードウェア設定など）がわからない場合は、Googleよりも同僚に尋ねたほうがよいでしょう。同僚はこれを繰り返し行っており、確かに役立つでしょう。 私を信じてください。たとえば、間違って構成された機器がDHCPを介して新しいIPによって突然全員に配布された場合、さらに悪化する可能性があります。
13. 新しいテストの機会を探ります。 本やコミュニティ（同じHabr）を読んで、開発を止めずに、簡単なスクリプトを書いて、テストの自動化について詳しく学んでください。
14. バグを修正した後、機能を再チェックするのを怠らないでください。 とにかくこれを行うように求められますが、突然そのようなケースがないことがわかった場合は、怠けすぎないでください-無料の分を選択して確認してください。 ケースは、テスト計画に追加することを意図的または意図せずに忘れられた可能性があり、バグの再現は不快です。
15. 負荷を作成できる場合は作成します。 負荷とは、たとえば、大量の電話や相互接続だけでなく、大量のデータや複数のユーザーなどがいる状況も意味します。同僚に助けを求めてください。 必要に応じて、さらにテストデータを取得し、マルチメディアを追加します。 マネージャーに連絡してください-従業員にできるだけ近い条件でソフトウェアをテストできる不要なテストクライアントデータがある可能性が非常に高いです。
16. オペレーティングシステムとプログラミング言語を学びます。 深刻なコードブロックを記述できない場合でも、プログラムのアーキテクチャをよりよく理解し、問題が発生する可能性のある場所とそれらに関連するものを予測します。
17. ドキュメントを調べて確認します。 ドキュメントは、テスト中のソフトウェアの一部です。 そのようなケースに出会わなかった場合は、喜ばないでください。逆に、必ず読んでください。そこで、ソフトウェアを操作する新しい機会が見つかります。おそらく、矛盾や明白なエラーに遭遇するでしょう。
18. 経験を共有します。 テスト部門は、人々が頻繁に変更するように配置されています。 必ず新しい人を助けてください：質問を説明するとき、あなたは知識を統合するだけでなく、近かったが見つけられなかった解決策も見るでしょう。
19. 計画。 もちろん、考案された時間のテスト計画があります。 しかし、主な計画は、品質基準を使用して自分でコンパイルしたものです。 計画的に作業内容をマークし、作業の進行状況を確認し、時間がない場合は助けを求めます。 時間の正しい編成は驚異的に働き、独学に従事することを可能にします。あるいは、仕事志向であるが無関係なものによって時間に気を取られることさえ可能にします。
20. 他人を信頼しないでください。 奇妙なことに、しかしそれはそうです。 現在のバージョンが同僚によってテストされる前のバージョンの特定または類似のケースが見つかった場合、彼の結論とテスト計画を完全に信頼せず、それらに基づいて独自の操作を行ってください。 ポイント20までに、不信の理由が明らかになると思います。
テストエンジニア、テスター、テスターは、しばしば、笑され、模倣され、動機付けを行い、ITジョークを私たちに付けます。 だから彼らは必要です。 プログラムの安定性、成功したリリースのリリース、顧客の不満の欠如。 本当のテスターは問題から離れることはありません。それはチームの一員であり、トレンディなアジャイルと古い機能階層のどちらでもかまいません。
テストは知識、責任、そして少しの幸運です。 幸運を祈ります！