テスターは職業以上のものです

テストの分野での仕事中に、私はジュニアテスター（ジュニアテスター）の立場からテスト部門の長（テストマネージャー）に至るまで、この分野に関する独自の意見を作成しました。 そして、一般的に、この意見はこの素晴らしい職業に対する愛と敬意の分かち合いで非常に重要です。

はじめに

私はテスターに​​なるつもりはありませんでした-開発にもっと興味がありました。 学校から、クラスメートとクラスメートがすでに実行しているプログラムを作成しました。問題の解決と物事の活性化に興味があり、ユーザーがそれらについて知らせた後、問題とバグの解決に取り組みました。 私はマイナーな数字をバージョンに帰しました...そして、機能と品質のバランスをとって、プログラムは永遠に残り、新しいプロジェクトやプログラムに取って代わりました。



将来的には、これがプロジェクト管理を成功させる鍵の一部であり、製品開発のコストと品質のバランスを見つけることが重要だと思います。 すべての製品は生物に似ており、その形成において、1人ではなく、多くの人が直接または間接的に参加しています。 すべての利害関係者は、優れた製品の形成に参加し、それぞれが共通の原因に大きく貢献する必要があります。 しかし、驚いたことに、テスターはこの点で特別なニッチを占めています。第一に、彼らはプロセスのリンクであり、第二に、製品バージョンのリリースを拒否する権利を持つ唯一のエンジニアです。



開発者の野心が衰えることなく、テスターとして最初にこのことについてすべてを学びました。 まず、製品管理へのアクセスを獲得する機会に魅了されました。これはあまり期待していなかった力です。 別の機能を書くことよりも素晴らしいことでした。 第二に、職業の特性により、テスターは製品のプロセスと目標をより深く理解し、部分的にビジネス目標を開発者に伝え、開発者の結果をマネージャーに伝えます。 残念ながら、世界、特にロシアでは、テスターの役割の考え方は非常に混oticとしており、その重要性は大幅に低下しています。 そして、まだ傾向にある企業は、テストと品質管理の分野を開発しようとしていますが、「過失をすべて見つけ、テストを通じて開発コストを最小限に抑える」という過大評価された目標を設定しています。



主にさまざまな企業とのコミュニケーションに基づいて書かれたこの記事は、彼らの質問に対する答えの真髄です。 第二に、初心者のテスターと、内部キッチンの観点からテストの詳細を学びたい人々を対象としています。 第三に、それはもっぱら私の（主観的な）経験に基づいています。

論文1：テスターはサルではない

Android SDKには、MonkeyRunnerという素晴らしいツールが含まれています。これにより、ソースコードなしで、プログラミング言語の特別な知識なしで（理想的にはスクリプト言語の一般的な知識で十分）Androidアプリケーションのテストプロセスを自動化でき、最も重要なのは、実際のユーザーの動作をシミュレートできることです。 その結果、アプリケーションを突いたり、印刷したり、読んだりするスクリプトモンキーのようなものになります。 まさにあなたが車を「アウトソース」できること。 私にとって、このようなテストの理解は当たり前です。 しかし、驚いたことに、テスターとしての最初のポジションの後に初めて仕事を探していたとき、（今日まで）「マニュアル」テスターと「自動」テスター、さらにははしごに奇妙な区分があったことが判明しましたグレードとまったく混合し、伸ばすようにあなたは疑問に思う。 会社ごとに同じポジションが異なる職務を暗示するという事実は言うまでもありませんが、これは特に上級職に当てはまります。



私の仕事には、テスト設計のコンパイル、テストケース、テスト戦略（自分に割り当てられたプロジェクトの場合）、バグの報告、ドキュメントの確認、テストドキュメントの作成が含まれていました。 これは私にとって当然のことでしたが、西洋の同僚がこれらの責任を共有していることはいくぶん驚くべきことでした。 市場では、CTE / UML（せいぜい）テストリード/シニアテスター/テストデザイナーを使用してデザインを記述することは非常に一般的であることが判明しました。 テストケース（さまざまな境界検証戦略、フロントエンドテスト、負荷テスト、ベンチケース）-シニアテスター。 そして最後に、「パフォーマー」の低い位置があります-テスター。 一部の企業および部門では、その数は最大20人以上に達することがあります！ 言い換えれば、プロジェクトのスタッフには、せいぜいコンピューターユーザーのスキルと何らかの製品を持っているサルが含まれていました。



実際、これは...やや間違っています。 テスターはサルではないからです。 そうでない場合は、会社として、正式な煙テストを実行することで、その後のサポートと品質なしに、短時間でさまざまな製品をリリースするか、マネージャーまたはアーキテクトが雄羊です。





テストの自動化のコストはすぐには報われません。



テストの理論に精通している人（実際にはそれほど多くない）については、自動化の必要性がプロジェクトの詳細（タイミング、サポート、再現性など）に大きく依存することは明らかです。 場合によっては、プロセスを複雑にするよりも、煙テストとユーザーベータテストに合格し、製品の所有者を通じて承認する方がはるかに望ましい場合があります。 製品受け入れの明確な理解も必要です：トップレベルとローレベル。 最初のケースでは、プロジェクト内で役割を定義し、製品を製品所有者に渡すことができます。2番目のケースでは、要件が許せば、開発エンジニア自身によるリリースノートの受け入れを制限することができます。 それでもテストが分離されている場合、管理者またはエンジニアのチームが製品の展開とテストのタスクを個別にカバーできる製品と人のライフサイクルプロセスを設定する方がはるかに簡単で効率的です。つまり、先験的にフィールド、ツールを知っている人開発者や1人のプロジェクトマネージャーにかかっていた猿の群れではありません。

論文＃2：テスターは工学の専門家です

猿とのミッシュマッシュのために、テスターの職業には、エンジニアリングの領域から遠く、時には適切な技術教育さえも持たない十分な人々がいます。 これは本当に悲しいことです。なぜなら今日のテスターの市場には十分な資格のあるリソースがないからです-有能なスペシャリストは開発に参加することを好みます（せいぜい、トピックに近いアナリスト）。テストおよびプログラミング言語。



私の意見では、テスターに​​は技術的な知識、自信のある知識、およびアプリケーションと一般的なOSの管理に関する少なくとも基本的なスキルが必要です。 さらに、テスターは少なくともプログラミング言語の基本的な理解を持ち、少なくとも直感的なレベルでコードを読むことができ、また新しい言語とプログラム/環境にすばやく適応できる必要があります。 一般に、テスターの主な機能は柔軟性と学習能力です。 したがって、プログラミングの経験があり、スクリプト言語と高レベル言語の一般的な理解があれば、特別な問題なしに学習して適応することができます。 理想的には、スクリプト言語と、プロジェクトの基になっている開発言語の基礎に関する知識が必要です。



このすべてから、テスターはコードを操作できる必要があります。 理想的には、良いプロセスはブラックボックスモデルに従う必要があります。 それでも、このPandoraのボックスでは、テスターは開発者が問題に対処し、対処することを恐れる必要はありません。 つまり、バグトラッカーだけでなく、コードバージョン管理のシステムでも、水中の魚のようになり、コードレビューを実施できるようになります。



ほとんどの場合、コードレビュー、デバッグ（デバッグ）、および単体テストのプロセスは開発者の特権であるという意見を耳にしますが、これは間違ったアプローチであると主張する自由を取ります。 問題は、テスターの不十分な資格と、ソフトウェアライフサイクルの不適切な管理にあります。 このアプローチは小規模なTDDプロジェクトでうまく機能する可能性がありますが、高品質の製品を確保する主な強みと能力は、影響の範囲、責任を分解し、相違点の原則を保証することです。これにより、開発プロセスがより透明で追跡可能になり、 »開発者にとって、「トリック」を避けるため。

論文3：チームワークがなければ指標はナンセンス

テストマネージャーポジションのほぼすべてのインタビューの中で、申請者がテストプロセスをどのように構築するのか、プロジェクトからどのようなメトリックを取得するのか、どのメトリックを自分に対して使用するのかについての質問を聞くことができます。 実際、メトリクスには多くのオプション（定量的および定性的）がありますが、プロジェクトでチームの効率が上がるまではあまり意味がありません。 広義のチーム、つまり、部門/テストチーム内、およびビジネスの開発者や顧客のチームとやり取りする場合の両方。



実際には、これは開発されたテストの数（これは進行状況の測定基準）、発見されたバグ（最悪の場合）テストチームの有効性の指標、回帰率、プロジェクトの合成測定基準（重要度と労力の基準を使用）を考慮することは意味がないことを意味しますばかげたものについて（しかし、KSLOC \時間テストチームにまだ使用されています）。 プロジェクトマネージャーにとっては、プロジェクトKPIとして優れたCPI / SPIメトリックである場合があります。これは、テストマネージャーによって示され収集されたすべてのメトリックに基づくことができます。 つまり、費やされた努力と得られた結果に応じて、かなり抽象的で高レベルの評価です。 ただし、チームが単一の有機体として機能する場合。



テスターに​​とって、これはプロセスの接続、駆動ホイールであることを意味し、ソフトウェアを実行可能かつ関連性のあるものにします。 テストプロセスでは、これは、テスト自体と、再現性、文書化可能性、考えられる問題、問題の解決策のテスト（テスト側から見える場合、十分な資格がある場合）、およびダブルチェックテスト（VoV）の両方を意味します。 言い換えると、テストのタスクは、すべての可能な状態を再実行して再確認し、（必要かつ十分な場合）完全なテスト戦略とテスト計画（少なくともQuality Gatesに示されているもの）をカバーし、バグを発行し、それらを解決することですソフトウェア開発者と仕様を通じて。 つまり、バグをチェックして検出した瞬間から、その責任は開発者に「広まる」ことはありませんが、バグが解決するまでテスターが伴います。 大まかに言えば、テスターがバグを担当し、開発者が機能を担当します。



ここでは、テスターと開発者の主な違いについて説明します。これは私の記事では非常に似ており、似ています。 ただし、作業スタイルにより、開発者は通常、完全主義者または「機能」（コード、機能、およびアルゴリズムのためにコードを作成したい）のいずれかです。 テスターは、物足りない人または自動化エンジニアです（自動化を自動化しようとしています）。 したがって、プロジェクトでは、テスターはそれを正しく行う方法を知っており、開発者はその方法を知っています。



これに基づいて、主なことは、単一のチームに依存する結果であり、設計開発などの1つの進捗状況の指標だけではないことを繰り返します。 そして、プロセスがさらに低下する場合-問題はそこにあり、実際のメトリックはそこにあります。これは、すでに相乗効果のあるプロジェクトのコンテキストで意味があります。 テストの長期にわたる開発は設計者のせいではない可能性がありますが、要件を変更したアナリストのせいは非常に困難です。

論文4：テスター-ソフトウェア開発プロセスの中心

ソフトウェア開発のVモデルは、テスターがライフサイクルのすべての段階に関与していることを明確に示しています。



開発者とテスターの類似性、質の良い地域のぼやけた境界は、テスターの仕事に関心のある主要な指標です。 もちろん、ブラックボックスをテストする場合の製品への関与とその品質は動機付けの要因であると主張することができますが、私の意見では、技術、エンジニアリングの分野に来た人は、自分で開発して作業したいという欲求で、これを意識的に行いました。 したがって、視野を広げ、製品の品質（小さなものでも）に影響を与え、アクティブになり、テスターからの製品のリリースを拒否する能力は、私が思うに、この職​​業にとってより重要な議論です。 もしそうなら、良いテスターがサルではなく、研究エンジニア、ライフサイクルのほぼすべての段階に参加する専門家である場合（アナリスト、デザイナー、開発者、テクニカルライターの役割とは対照的に）、製品の品質を担当しますプロセス、それはQAのためです。したがって、「製品品質」とは、宣言および承認された要件と標準、チェックリストなどを順守することを意味します。 彼は製品を改善する方法を知っています。 開発エンジニアと他のチーム、さらには企業の両方の動きを開始するために、何が「十分」であり、どのようにそれを行うか、製品またはプロセスを知っています。 たとえば、どのプロジェクトでも、経営陣が許容できるダウンタイムの瞬間があります。 通常、この時点で、従業員は個人的な問題を解決するか、独学に従事しています。 作業に関しては、開発者はリファクタリングを行い、アルゴリズムを学び、自分のプロジェクトに転送できます。 テスターは何をすべきですか？ 新しいテストツールをマスターしますか？ 彼は開発者/アナリストからの最初のパッケージなしでは何もしません。 実際、彼はインフラや開発者から遠く離れていても、活動の自動化を行ったり、使用する製品を改善したりすることができます。

論文5：テストはキーワードを修正する場所ではない

私の意見では、最後で最も奇妙なトピックは、テストの非常に曖昧なアイデアです（実践はもちろんのこと、理論ですら）。 多くの企業では、テスト部門は期待に応えませんでした。一部の企業では、信用を失い、いくつかの要因に対する潜在的な有効性のごく一部を操作しています。 問題は、学校の欠如と管理の無能さの両方に起因します。 ITから離れた業界では、状況は非常に嘆かわしく、「お金は問題になりません」-「製品の品質を改善する」という原則に基づいてタスクが設定されています。 プロセスの一般的な考え方があるIT企業でさえ、特定の役割やツールの修正に関連する多くの問題がありますが、繰り返しますが、このアプローチはテストにはあまり適用できません。



インタビューを受けた大手投資銀行の1つでは、テストマネージャーの役​​職に「品質を向上させ、結婚を減らす」という同様の要件がありました。 どんな問題でも解決できます。 タスクのカバーの下には、さまざまな製品の部門の調整、テスト計画の作成、テストの編成、開発者との連携、ケースのベースの作成などがあります。 実際、社内の製品の品質に対する責任を「品質のディレクター」、QAディレクター、そしてテスト部門の責任者だけに負うのは論理的です。 しかし、ここでの問題は、この立場にない権力と、まったく計画されていないグループが存在しないことです（それは、それを助けることができます）。 つまり、会社にはチームのない男性オーケストラが必要です。 答えは簡単です：管理者はキーワードで検索し、略語QAの品質をすべての問題の万能薬と見なしますが、適切な権限とリソースを使用して上から下げる必要がある戦略的なトップマネジメントとプロセスの分野にあります。





理想的には、品質管理（QA）とテストは2つの独立したエンティティです。



問題はシステムの問題です。HRが「ストレステスト」、「機能的」などのキーワードを探しているのは悪くないからです。 しかし、レビュープロセスの焦点が、スキルのテストではなく、候補者の活動や柔軟性ではなく、特定のツールにある場合-これは問題です。特にテストがまったくない場合（サルのコントロールがある場合）、必要なツールがより効果的であるという事実ではありません申請者が知っていること。 問題は、習得するのに数時間かかる小さなニュアンスや楽器の知識が、プログラミング言語や理論の知識よりも最前線に置かれていることです。 インタビューの1つで、「テストに関する本に名前を付けて」という質問に答えるのは面白かったです。サムカナについては「これはわかりませんが、バグのライフサイクルについて何か読みましたか？」 それほど悲しくなければ面白いでしょう。 HRが候補者との経験不足のため拒否を発表するのは悲しいことですが、その点は強調が間違っています。



テスターエンジニアは、理想的には、ソフトウェア開発に関連する技術的な問題を解決する人であり、一種の問題解決者であるため、優れたテスターを見つけることは大きな問題です。 技術的なスキルに加えて、そのような人がマインドフルネス、探究心を持ち、アクティブであり、あらゆるレベルで考えを伝え、自分の視点を守ることができることが非常に重要です。ある意味、テスターはソフトウェア開発の世界の研究者です。 そのため、テストエンジニアの手には、バグを監視する虫眼鏡（レンズ）という簡単に認識できるシンボルがあります。 テスターの作業を可能な限り最良の方法で特徴づけます。欠陥を特定する目的と「穴を燃やす」目的の両方に使用され、火災の発生に使用でき、レンズシステム全体で星を観察することもできます。 主なことは、それをできるようにすることです。

結論の代わりに

テスターは単なる職業ではありません。これは、先を見越した生活の方法であり、実行可能で効果的な手段によってこの生活をすべての人にとってより良くしたいという願望です。製品に対するテスターの目標は、企業のビジネス目標と製品の戦略目標に最も近いと同時に、研究者として企業内の奥深くにあります。もしそうなら、その主な資質はエネルギー、知識、柔軟性です。しかし同時に、テスターの仕事は、製品の品質とサービスの品質に対する普遍的な知識と責任ではありません。テストには制限があります。一方では、プロジェクトとその要件（プロジェクト管理とプログラムの確立されたライフサイクル）によって制限され、他方ではQAが責任を負うプロセスです。しかし、QAとテストの違いはまったく異なります。