プロローグ
この投稿では、ロシアのITにおけるソフトウェアテストプロセスの形成と成長に関する個人的な印象を共有します。 運命の意志で、これは私の目の前で、小さな会社のジュニアテスターから数百万ドルの売上高を持つ評判の良い会社の品質ディレクターまでの道のりでこの職業を習得する過程で起こったと言うことができます。
読者の現在の状態でのテストに対する認識を無視して、これが過去にどのように起こったかを理解するために、「はい、それはすべて明らかです」、「これらは長い間知られている事実であり、それについて書いてください」と感嘆して記事を却下しないようにすることをお勧めしますなど 歩き方についてはお話しするつもりはありませんが、私たちがかつて自分自身を歩くことを学んだ方法と、私たち全員がこれを行うことを学んだ方法についてお話したいだけです。
むかしむかし
約8年前、ソフトウェアテストを始めたばかりのとき、これは「見せる」仕事であるように思えました。ユーザーに配布する前にソフトウェアをテストすることはクールでファッショナブルで、一般に良いと言っていたからですそれが必要です。 ところで、業界自体も、このプロセスについて同様の意見を持っていました。 もちろん、欧米企業のソフトウェアの巨人や駐在員事務所はありましたが、特に品質保証とテストの文化は、ロシア連邦の産業のまさに発展の成果になるのではなく、外部に課され、与えられたように知覚された可能性が高くなりました。
私はゲーム開発者から始めましたが、それはある意味ではテストに対する態度という点で西洋企業を代表するようなものでした。 品質管理は不可欠な部分でしたが、多くの場合、理由と目的を理解するためではなく、「西側でテストが行われているため、テストが行われます」という理由がありました。外国のゲームの最大のディストリビューターの1つ。 当時、すべてがすでに「深刻」でした-10人の専門家のチーム、数人の主要な専門家、部門の長、つまり 「ビルド-テスト-バグ-修正-リリース」の精神で、独自の階層、順序、およびシステムプロセスのいくつかの基礎。 もちろん、誰もがそこで働いた理由を「理解」しました-「ユーザーがエラーを見つけられないようにエラーを探します」、少なくとも与党の一般的な線はそれまで減りました。
数年後、Web開発に向けて出発する前に、社内で体系的なアプローチの始まりを見ました。最初のチェックリスト、テストケース、そしてテスト結果の概要レポートです。 しかし、それらのすべてがまだ「私たちがテストするから...」という単一のパズルになっていない。
年が過ぎました
多数の非常に人気のあるWebプロジェクトを開発している大規模なメディア会社に移った後、自分自身とテストに対する認識だけでなく、このテストを取り巻くプロセスにも変化があることに気付きました。 開発は開発とプロジェクト管理の両方に関するものでした。いいえ、スクラムやその他のアジャイルについて話すのは時期尚早でしたが、すでに最初の答えが「なぜテストが必要なのですか？」「どのように実装できますか？」「開発レベルで改善できますか？」
これらは「製品がより良くなるようにテストする」、「製品をより良くするためにテストする」、および同様の結論のレベルでのささやかな努力でした。
5〜6年前、テスト計画、チェックリスト、テストケースが大量に出現し始めました。テストプロセスを高速化し、予測可能、標準化、および管理可能にすることができると理解されたためです。 最後に、一時的な工数ではなく、非常に具体的な数値でカバレッジを測定することが可能になりました。ただし、テストの量とコードテストによるカバレッジの割合に関する実際のデータは近似的ではあります。
プッシュモンキーではなく、プロのテスターがますます多くなり、一部はコミュニティで迷子になり、テーマ別のWebサイトやフォーラムを募集しました。同時に、熱狂者の小さなグループがテストと品質保証に関する最初の、そして今や非常に有名な会議を開催しました。
その後、初めて機能テストのレベルで自動化のテストについて話し始めました。私は個人的にTestCompleteとSeleniumのR＆Dを行いました（これは世界中の何百何千もの自動化エンジニアの手に渡る恐るべき武器ではありませんでしたが、使用された最初のパブリックベータ版のみを受け取りましたウェブ開発の世界からの絶望的な愛好家）。 これらは、テストプロセスを新しいレベルに引き上げる最初の試みであり、そのプロセスが必須かつ不可欠な開発の一部となり、それなしではリリースが1つも通過しませんでした。 テストは、不当な手間やライブでの編集（またはソフトウェアを使用する場合はパッチのリロード）のリスクから開発を保護するのに役立ち、完璧主義者が原則として仕事をより良くするのに役立つことが理解されるようになりました。
同時にどこかでフリーランスを発見しましたが、これらは本格的なプロジェクトや分散チームなどよりもまれな攻撃でした。 むしろ、大企業が数年前に西洋を模倣したように、それは大企業を模倣するための一種の類推でした。 時折、VIPの顧客の場合、これはイメージの問題でした。Webスタジオは、実行中のテストに関する美しいラインを商業的な提案で書きました。
昨日
中小企業は、テスターの助けを借りて品質を求めて戦い始めましたが、開発、苦しみ、リスクを救うためではなく、利益を目指しています。 より正確に言うと、最終的には、テスターが企業に多くのお金を節約できるという理解が明らかになり始めました。
判明したように（奇跡ではないでしょうか？）、バグは会社に直接的な損失を被ります。巧妙なクラッカーが大企業のアカウントの顧客ベースを引っ張った脆弱性、標的の聴衆を怖がらせる不正に作られたオンラインストアレイアウト、さらには彼らの不十分さの結果として、彼らは長時間リソースを投入し、それによって間接的なイメージ構築と直接的な経済的損失を引き起こしました。
当時、多くの人が考えていたように、3-4年前、私は堅実なキャリアポイントに達し、数人の雇用主を変え、以前はテスターとして働いていた最大のメディア企業に戻りましたが、今では人気のある大規模なPMになりましたプロジェクト。 プロジェクト管理の分野で開発したいという願望ではなく、その役割に行きましたが、PMを理解する方法を学び、鳥の視点からプロセスを見るために、彼らは言います（詳細は説明しませんが、これは別の投稿のトピックです「私がプロジェクト管理をやめ、「テスターに格下げ」された理由」の精神で。
一方では、テスターの実が取るに足らないものである理由と、テスターがPMに「Operaに重大なバグがあり、それをリリースすることはできません」と叫ぶと、懐疑的に顔を手で覆うと、「必要だ！」今日はまだパートナーとの交渉、顧客とのプロモーションの議論、モデレーションのための20,000コンテンツユニット、3つのタスクの設定、来週の6つの機能の実行があります。
叙情的な余談：
「プロジェクトを管理するために来たとき、2〜3年前にテスターとして自分自身に設定したバグを含む、自分に割り当てられたチケットシステムに500のチケットを見ました。 これらのバグで最初にしたことは...優先度を下げました。 結局のところ、プロジェクトにこれらのバグが2〜3年間存在した場合、それらは本当に重要ではありません。」
一方、テストの深さの不足や自動化の欠如により、サイトが莫大なお金を失ったり、半日落ちたりする反対のケースがありました。これは10万人のホストのプロジェクトでは受け入れられませんでした。
たとえば、そのような場合がありました
「3月1日の00:00から、ユーザーの個人カードが2月30日から31日の偽の誕生日を示すことができたため、サイトは午前12時まで（開発者による修正前）ダウンしました。これは、運命の意志により、ブロック内のユーザー名出力プロセッサによって誤って検証されました「今日は誕生日」：3月1日に出生リストを明確に切り取り、メインページに限られた数のユーザー名を表示しましたが、この日付に移動した偽物はカットしませんでした。
「突然、データを保存するための分散サーバーシステムが失敗し、文字「P」によるアカウントの登録が停止したことが判明しました。 すべて順調ですが、1日あたり4,500の登録がありました。 つまり 平均データによると、毎日200人が登録中に説明できない問題に直面しました。残りの半分（100人）を想定すると、会社は毎日約30ドルを失いました。統計によると、3人に1人が登録時に「プレミアムアカウント1ドル」を購入したためです。 損失はわずかですが、この領域の自動テストの対象範囲が不完全であるため、このバグは6か月後にのみ検出されました。 このような些細なことで、会社は約5,000ドルの純額を失いました」
自動化は、「ファッショナブル」であり、収益性が高いと思われるため、完全に、時には非常に無頓着に導入されました。 繰り返しますが、テストの実装における過去のマイルストーンでのアプローチのスマックなどです。
フリーランスの注文はさらに多くありましたが、企業はテスターチームに参加することで画像と経済的損失も節約できることに気付きました（テストサーバーにコードをアップロードしてから30分後にバグを修正することと、クライアントのライブプロジェクトで修正することは別のことです）実際には既に配信されています）。
それはテスターの背中が大幅に節約された時代でした。テスターへの入場の閾値は低いままであったため、テスターに対する大量の需要は供給を減らしませんでした。 企業とトレーナーは職業の基礎を教えているように見え、人々はテストを開発の世界への扉として使い始め、企業は製品全体の開発プロセスを最適化する比較的安価な方法としてテスターを使用し始めました。
きょう
2年前にプロジェクト管理を品質管理に任せ、品質のディレクターになって、基本的にテストプロセス（フェーズに分割、指示、テンプレート、メトリックなどを作成）だけでなく、開発プロセス、さらにはアナリスト全般。 したがって、エラーのコストをさらに削減し、コードの記述ではなく思考レベルでのエラーの出現を予測できます。 以前の間違いが戦場で事実上修正された場合、品質保証プロセスにより、プログラマーは問題のステートメントでそれらを修正するコードの最初の行を書く前に、アナリストが頭に入ることができます。 そして、開発者は、有能な単体テストを作成して、手元から出てくるコードがテスターだけでなく、単体テスト、コードレビューに合格すること、開発者自身によるクロステストを受けることを奨励されるべきです。
コミュニティは成長し、新兵の列が補充され、雨天後のキノコのようなアウトソーシングテストプロジェクトが登場し、トレーニングセンター、テスターの会議はすでに定期的になり、年に2回数百人の熱心なリスナーが集まっています。
多くの企業の品質保証と品質管理のプロセスは、経済的な観点から保証するだけでなく、低品質の開発によるストレスを回避するだけでなく、市場で競争力のある製品を作成するのにも役立つため、現在非常に重要な場所を占めています。 今日の製品の品質が、製品を選択する際の決定的な特徴の1つであることは誰にとっても秘密ではありません。
そして、多くの企業のテスターこそが、当然の栄誉である表彰台の品質を高め、すべてのプロセスを前進させ、製品だけでなく、この世界をより良くする原動力です。
明日は何が待っていますか？
私は占い師ではありません。私は自分の職業における成長の道筋に沿って、テストの開発の小さな歴史的なセクションを作りました。 したがって、私は有名な映画から言葉を言います：
「未来は前もって決められておらず、私たちが創り出す運命以外の運命はありません。」