Badoo Bird's Eye Testing

自動テストの作成方法、使用するテクノロジー、開発者の単体テストパフォーマンスの支援方法などについて何度も話しました。 しかし、手動のテストプロセスを含むテストプロセス全体の戦略について書いたことはありません。 このギャップを埋める時が来ました。

テスト戦略は異なります。 それらは多くの要因に依存します：選択された技術、ビジネスの焦点、アプリケーションロジック、企業文化など。 組み込みシステムに適したものは、モバイルアプリケーションに適さない場合があり、会計で適切に機能するものは、航空機用ソフトウェアの生産に必ずしも根付かない場合があります。

誰もがすべてを文書化する問題に非常に慎重にアプローチし、コードはよく読まれるべきであると信じています。これで十分です。 多くの人が正しいと言えます。受け入れられた方法論と実践が社内でうまく機能するなら、まさにそれが彼らが必要とするものです。

Badooの場合も同じです。私たちが使用するアプローチの多くは、私たちの文化やスタートアップ後の世界でうまく機能します。会社の爆発的な成長により、さまざまなレーキを踏んで多くのコーンを獲得しました。 当初の基本的な価値のために、私たちが基礎としてとったものの多くが依然としてうまく機能し、完璧にスケーリングすることを非常に嬉しく思います。

チームの1つ、たとえばモバイルWebチームを使用して、プロセスについて説明します。 これは、特別なプロトコルを使用してサーバーと通信するモバイルブラウザーで本格的なHTML5アプリケーションをダウンロードするときに、Webとモバイルの接合部にあるプラットフォームです。 ところで、デスクトップWebを含む他のすべてのBadooクライアントアプリケーションは、同様の方法でサーバーと対話します。

第一に、このプロセスは、製品を製造するすべてのチーム（多少の例外はあります）で多かれ少なかれ一般的です。

プロセス

他の多くのBadooチームと同様に、モバイルWebのタスクはPRD（製品要件ドキュメント）から始まります。 これは、プロダクトマネージャーがコンパイルし、開発で要求された変更がどのように見えるかを説明するドキュメントです。 既存の機能の動作を変更する新しい機能-「機能」という用語を使用して、これらすべてを示します。 PRDには、デザイナーからのインターフェイスデザイン、ビジネスロジック、機能のリリース後の分析要件などが含まれています。 これは、製品と開発の相互作用の基礎です。

次に、チームのテクニカルリーダーが入力された要件を解析し、ドキュメントの全部または一部（機能が非常に大きい場合）を開発者に渡します。 この時点から、この機能には所有者がいます-機能の実装だけでなく、その実装のタイミングにも責任を負い、実装の過程で、必要に応じて他のチームと相互作用します（PRD、設計などを指定します）。

複数の人がプロジェクトに取り組んでいる場合、そのような開発からのマイクロプロジェクトマネージャーはその1人で、通常は最も経験豊富な人です。 そのため、彼らが言うように、七人の乳母には目がない子がいない。 一般に、これは集団的責任の状況を回避しようとする方法です。 結局のところ、誰もが何かに責任がある場合、事実上誰も責任を負いません。

開発を開始する前に、計画を立てます。これは、機能の開発、テスト、リリースの方法、発売後の分析に必要なビジネス指標、最終的な発売前に必要な実験などの一般的なシナリオです。 この計画は、KickOffと呼ばれる特別会議で製品によって承認されます。全体の概要を評価し、必要に応じてニュアンスを明確にし、修正し、計画に従って実装に青信号を出します。

さらに、開発者は技術計画を（独立して、または同僚とマネージャーの助けを借りて）準備します。 これは本質的に、以前に承認されたのと同じ計画ですが、各段階での技術的な実装について明確化されています：既存の機能、使用するテクノロジーとメカニズム、リリースされる順序などと必要なものを最適に組み合わせる方法さらに。 ほぼ予測可能な実装期間が現れるのはこの段階です。 その開発者は自分自身を決定し、リーダーに同意し、その後、それを明確に維持しようとします。

明らかに、この場合の用語は、ユーザーが新しい機能を利用できるようになる日付として理解されます。「プログラムに3時間必要です」ではなく、「朝のリリースで8月3日にタスクを投稿します」。 当然、そのような期間を決定するためには、多くのニュアンスを考慮し、プロセスに参加するすべての人と通信し、依存関係（特に外部のもの）について考え、他の部門と用語とリソースを調整し、もちろんテスターでテストの時間を確認する必要があります。

この段階では、テストの時間を見積もるQAのテクニカルリードが、1回の反復（再開を除く）のテストに必要な時間の見積もり、つまり、現在のタスクの品質を評価するのに必要な工数を知っていることが重要です。 なぜ1つの反復について話しているのですか？ 簡単です。バグがいくつあるか、修正する必要がある回数を予測できないためです。

長期的には、用語を制御することは難しいことは明らかです。 したがって、現在の状況を修正するために、タスクでSituationフィールドを使用し、さまざまな間隔でさまざまなチームのタイミングを調整します。 期限を変更または指定する場合、プロジェクトをさらに（振り返って）分析し、次回より正確な予測を行うことができるようにするために、これを行った原因を修正する必要があることに留意することが重要です。

この段階の後でのみ、開発者はプログラミングを開始できます。

開発者は、機能またはその一部の実装を完了し、準備ができていると確信した後、Visual QAを編成します。 これは、プロダクトマネージャーとの特別な会議であり、開発者は彼がしたことを実演します。 製品は、機能を受け入れるか、必要に応じて要件を明確にすることができます（この場合、機能が完成し、すべての段階が再び繰り返されます）。 このステップでは、開発者自身が少なくともアプリケーションを使用する肯定的なシナリオをチェックし、バグがあればそれを修正することも保証します。 そうでなければ、彼は製品を何を見せますか？

製品のVisual QAが成功した後にのみ、タスクがCode Reviewに送信されます。 なぜ前に？ 製品に追加の要件がある場合、プロセスの他の参加者（レビューア、テスターなど）の時間を無駄にするためです。

コードレビューは、品質保証プロセスの非常に重要なステップです。 この段階では、開発者はコードを設計および一般的な合意のために分析するだけでなく、目と頭で文字通り「テスト」し、別の開発者によってプログラムされたスクリプトに従うことが望ましい。 追加の「整理された」外観は、非常に多くの基本的なミスを回避するのに役立ちます。

プロセスの次のステップはQAです。 私たちとのテストは、さまざまな環境での複数のステージで構成され、システムのさまざまなレベルと要素の手動および自動テストが含まれます（テストの実施方法については、以下で説明します）。

そして最後に、機能リリース。 多くのタスクでは、これは最終段階ではないため、さまざまな改善、A / Bテスト、ユーザー行動の分析、機能の最適化が行われる可能性があります。 ビジネスおよびアプリケーション全体に対する機能の有用性の回顧と分析。 「離陸しない」機能があります。 アプリケーションから変更または削除します。これは通常の方法です。 そして、以前のすべての段階を正常に通過したこれらの機能は、アプリケーションの主要な機能になります。

これは、説明したプロセスの完全な図の外観です。

テスト中

プロセスの説明から、機能のライフサイクルがどのようなものか、どの段階から構成されているかが明らかです。 そして、私の経験では、これらの段階のほとんどは、プロセスのすべての参加者によって正しく理解されています（プラスまたはマイナス）。 PRDの外観、タスクの分散方法、コードレビューの実行方法など-これらはすべて明確であり、多くの人がそれをチームで使用しています。

しかし、QAとなると、完全な不和が始まります。 さまざまなレベルのさまざまな人々が、「QAからのこれらの奇妙な人たち」の仕事について絶対に素晴らしいアイデアを持っていることがあります。 「彼らはそこで何かをし、クリックし、バグをもたらす」と状況を理解するのは良いことです。 また、開発者自身が作業の結果を慎重に確認し、「テスターは必要ありません。製品の品質は確かです」と述べていることもあります。 しかし、そのようなケースはほとんどありません。

私の実務では、開発者がテスターが「あまりにも多くのバグを見つけてリリースされないようにする」と信じている状況がありました。 開発者が「すべてのバグを見つけて、それを修正します、それだけです」または「私たちの製品がどのように機能するかを私よりよく知っている」と言うかもしれません。 問題はすぐに発生します。どのように機能するかわからない場合、どのようにコードを記述しましたか？

一般に、テストプロセスがどのように進むかを本当に理解している人はほとんどいません。 それを理解してみましょう。

品質とは？

まず、すべてのバグが見つからないことに同意する必要があります。 これは、最も頑固な個人でさえ同意する公理です-常識はだまされません。

ある期間にわたる「バグチャート」を想像すると、次のようなスキームが得られます。

発見されたバグの数（B）は最初は少ない-システムに精通するか、環境を準備する間。 その後、アプリケーションの「病気」の部分を見つけたときに、単位時間（t）ごとに成長することさえできます。 しかし、ある時点で、使用するメカニズムや方法に関係なく、バグが少なくなります。 その結果、時間は無限になり、すべてのシステムバグはまだ見つかりません。

時間に制限がなく、無制限のリソースがある状況を想像できますが、言葉遣いから、そのような状況は非常に総合的であることがすでに明らかです：あまりにも多くの仮定があり、過酷な現実との関連がない。 スタートアップと競争の激しい現実の世界では、大半の人が最短時間で利益を得ようとしていますが、タスクは次のように設定されています。できるだけ短い時間でできるだけ多くのバグを見つけることです。

バグを見つける速度などの重要な概念があります：S = B / t。 条件付きですが、多くの人がすぐに最適化しようとします。 どうやら、それは直感的だからです。 そのため、スモックテスト、自動テスト（はい、リグレッションテストだけでなく）のようなものが発生し、潜在的に危険な製品の場所（ 同等クラスなど ）をより正確に特定できるツールと方法論が開発されます。 そして最も重要なことは、製品の品質に関する最も完全な評価をできるだけ早く提供することです。

そして、すべてのバグを見つけることは不可能であり、時間が限られていることにすぐに同意したため、グラフのどこかに、質問に答えるために製品品質の現在の状態を示す交点Bとtがあるはずです。テストするか、続行する必要がありますか？

それでは、この理想値はβ=ƒ（B、t）ですか？

しかし、理想的ではありません-すべてのプロジェクトで異なります。 さらに、単一の適切に調整されたチーム内であっても、タスクごとに異なります。 それは、実装技術、特定の各チーム内の文化から始まり、マーケティングイベント、締め切り、そして顧客の「さあ、そうする」という決定で終わる外部条件の質量に依存します。

βの最小「ユニバーサル」値も不明である場合、すべてがさらに悲しいものになります。 しかし、それは存在し、誰でも簡単に理解できるように定式化されています：「ユーザーが喜んで購入すれば、その製品は十分な品質を備えています。」 そして、私はお金のために購入するだけでなく、ユーザーがあなたの製品を使用する準備ができている場合、彼が再びそれを開き、アプリケーションがクラッシュした後にそれを使い続ける準備ができている場合、それは良いβが達成されたことを意味します。

しかし、さらに多くの追加条件が施行されます。 あなたの製品には市場に競合他社がいますか？ どのカテゴリのユーザーが製品を使用しますか？ 完全主義に投資する準備はできていますか？ 新しい素晴らしいアイデアを示す記者会見はありますか？ 負荷の増加はいつ計画されますか？ などなど。

誰が品質を「作る」のですか？

お気づきの方は、前のセクションの最初からテスターに​​ついて言及したことはありません。 QAのような構造が社内にない場合でも、βの必要なレベルはかなり達成可能であるため、意図的にこれを行いました。 品質の最低レベルについては何も言うことはありません-開発者が提供する必要があります。

モバイルWebチームでは、Visual QAのトリックによってさらに制御される最小のベータを達成しました。 プロセスの次の参加者にタスクを転送する前に、開発者自身が製品マネージャーに来て、彼の仕事の結果を見せなければなりません。 そして、彼の製品の最初の慎重なユーザーは、PRDを書いた顧客自身です。

この段階で製品と通信することによる追加のボーナスは、重要でないものを遮断できることです。 たとえば、新しいアイデアの最初の立ち上げでは、彼はコンセプトを試してみる準備ができているかもしれません-理想、すべてのピクセルに検証されていないが、かなり受け入れられ、「半完成品」のアイデアの実行可能性を実証する美しいインターフェイスです。 また、ビジュアルQAプロセスでは、可用性の基準を調整できます。 主なことは、プロセスの他の参加者がこの不一致に驚かないように、PRDにこれを反映することを忘れないことです。

Badooに着いたとき、私たちはすぐに同意しました。当社では、開発者が品質に責任を負っています。 今日までのこの素晴らしい原則は、古い従業員を定期的に思い出させ、新しい従業員から伝えられています。 そして、多くの議論において、この議論は、私がそうする必要があり、そうでないことを異なるレベルの人々に納得させるのに役立ちます。

開発者を選ぶ理由 では、なぜテスターが必要なのでしょうか？ 正しくしましょう。

まず第一に、テスターはバグを作成しません。製品にバグがあるか、そうでないかのどちらかです。 数を減らしてプロセスに影響を与え、エンジニアリングカルチャーを改善し、一般的なルールと推奨事項を使用できます（コードの書式設定は、冗長性（タブまたはスペース、kekeke）に関係なく、鮮明な例です）。最終製品の品質に大きな影響を与えます。

しかし、そうであっても、開発者はコードに直接手を入れ、バグがそこにあるかどうかに依存します。 次のステップで、テスターは単純にそれらを見つけることができます。 そして、たとえファッショナブルなアプローチや最新バージョンのツールをすべて適用しても、彼らはそれを見つけられないかもしれません。

テスターは、アクロバットサーカス保険のようなものです。 アクロバットはすべての懸命な作業を行い、空中ブランコで回転し、保険会社はその下に立ち、「何もしません」（テスターのように）。 アクロバットは保険なしで彼のトリックを実行する可能性がありますが、保険があると彼ははるかに落ち着き、エラーが発生した場合に転倒を許されないことを知っています。 これが彼らが言うときの意味です：「私たちは1つのチームであり、私たちは同じことを一緒に取り組んでいます」など。チームは1つです。これは本当ですが、責任と主なことは保険が必要かどうかの決定です-アクロバットの肩の上にあります。 そして、私たちの場合-開発者の肩の上に。

さらに、開発者に品質のせいにすることで、私たちは時々非常に快適な状況を避けます-責任を負うべきものを見つけるために。 「誰のせいですか？」-「ヴァシャ。 バグが見つからなかったからです。」 実際、有罪者を探すのは意味がありません。 これは誰にとっても簡単にはなりません-構造が必要です。 そして、コンストラクトはこれだけです：これが再び起こらないようにするために、次に何をすべきか？ さらに、開発者自身が問題の主な原因としてこの質問への回答を提供する必要があります。今回は何が彼を妨げたのか、そして次回この「何か」が彼に干渉しなかったことを確認する方法は？ この場合、決定が信頼できるものでなければならないという事実に重点を置く必要があります。 「次回はより慎重になるようにVasyaに依頼する」という決定は、悪い決定です。 それは何も保証しません：私たちはすべて人間であり、Vasyaが今のように間違いを犯す可能性があります。 ただし、「この領域を自動テストで覆う」または「特定のタイプのパラメータのみを受け入れるようにメソッドを書き換える」という決定は非常に効果的です。

したがって、テストは、開発者の豊富なセットの追加ツールとしての指標と見なされる必要があります。これは、本番用にコードをレイアウトする準備ができているか、まだ準備ができていないかという質問に答えるのに役立ちます。 そして、角度を誤って測定した分度器を非難することは、少なくとも非構造的です。

テストプロセスはどうですか？

そのため、タスクはプロセスの前のすべてのステージを正常にパスし、テストに進みました。 次は？ このような問題は、テストに直接関与していない人々だけでなく、専門家自身の間でもしばしば発生します。 特に、テストの種類、方法論、黒灰色のボックス、ユニット統合システムのテストなどについて非常にカラフルに語ったいくつかのコースの後。チェックを整理する方法は？ どこから始めますか？

重要な問題は、修正のためにタスクを返す必要がある瞬間でもあります。 最初のバグの後？ それとも10日後？ または、すべてのシナリオを完全にチェックした後ですか？ ビジネスの観点から、βの値を最適なレベルに保ちたいことも明らかです（覚えておいてください：バグの最大数を見つけるために最短時間で？）。

一部の企業では、テストケースの固定セットを使用しています。 これらのスクリプトを自分で、または他の（多くの場合資格の低い）テスターの助けを借りて作成するテストアナリストさえいます。

一連のステップや、それらが導く結果のリストなどのシナリオ。 多くの場合、スクリプトはGiven-When-Thenの形式にすることができますが、これはオプションです。 管理者権限を持つユーザーとしてメニューの特定のセクションに移動し、緑色のボタンをクリックして、結果としてそのような画面を取得し、「Hello、world」が表示されていることを確認します。

このアプローチは、従業員の質を節約する意思がある場合に正当化される可能性があります。 コンピュータでの作業経験が非常に低い人を募集することができます。携帯電話では、ほとんどの人が電話を持っているため、完全に「外出」しています。

しかし同時に、このアプローチにはいくつかの欠点があります。 明らかに、最適なβを確保するために、このアプローチは有害ですらあります。 スクリプトの実行時間はテストセッションの間は一定であり、リストに新しいスクリプトが出現したため、増加するだけです。 さらに、このアプローチには素人の心理学に関連する欠陥があります。一方で、視野角を前述の角度に狭め、基本的なものでさえ、スクリプトの形で記録されないために見逃され始めます。 一方、人々は1つのシナリオをチェックすることで、同様のシナリオを検証済みとしてマークすることでプロパティを持っています（「電子メールで承認をチェックしただけで、機能します。電話番号で承認もチェックする必要があります。決してなかった」）。

私の以前の会社の1つでは、タスクを再発見するアプローチは次のとおりでした。バグが見つかりました-修正のためにタスクを送信します。 私のリーダーが作成した正式な規制文書さえありました。そこには物事のリストがあり、その後タスクを再発見する必要がありました。

1. タスク内のコードはコーディング標準によってフレーム化されていませんか？ 改訂のために！
2. 単体テストはありませんか？ 改訂のために！
3. 単体テストは失敗しますか？ 改訂のために！
4. 画面上のテキストは、タスク内のテキストとは異なる形式で作成されていますか？ 改訂のために！
5. 製品のインターフェースがレイアウトと一致していませんか？ 改訂のために！
6. ?????
7. 利益！

このアプローチは、パラメーターβに関しても最適ではありません。 毎回、各欠陥の後に開発者の時間が追加されるため、タスクの全体的なテスト期間が長くなります。 現在実行しているタスクからコンテキストを切り替える。 他のタスクのキューでタスクを待っている間。 もう1つのステップコードレビュー。 常に正当化されるわけではない他の多くの相互作用。 さて、タスクが再びテストに戻った後、再度テストする必要があります。つまり、既に実行されたすべてのチェックを繰り返す必要があります。これがテスターの時間です。 したがって、テストプロセス全体に必要な時間tは、タスクを再検出するたびに2倍、3倍などになります。 また、定義済みのテストスクリプトも同時に使用すると、完全に惨事になります。

そのため、Badooでは、タスクを再開するためにカウンターを監視し、その値が常に減少するようにします。 タスクを再発見することは、プロセスのすべての参加者の時間コストの観点から高価です（テスターの快適さの観点からのみ状況を見ると、このアプローチは非常に魅力的に見えます）。

しかし、理由を説明することなく、部下に再発見者の最小数を要求するリーダーに悲惨です。 この場合、目標の代替が機能する可能性があり、病気の原因を排除する代わりに、症状を治療します。 エンジニアリング文化を改善し、次にこの熊手を踏まないようにする方法を考え出す代わりに、数字がそれ自体で終わりになる状況に陥ることがあります。 これが作業にどのように影響するかは明らかです。開発者はシステムをだまそうとしています。 彼はタスクをテスターに​​転送しませんが、「ポケ、またはあなたはそれを再び開くと、私を罰します」とlaに尋ねます、そしてβインジケータは再び苦しみます-テストは不透明であるだけでなく、この場合にも制御されます難しい。 時間tは未定義になります。 一般的に、これには非常に注意してください。

別の大規模で有名な会社では、時間tは一般に巧妙に最小化されました。 エラーには予算がありますが、テストはまったくありません。 仕事の最初の日から、開発者は誰でも本番環境でコードをレイアウトすることができ、すべてをチェックし、自分自身を越えて神に祈り、特定の瞬間に自分の製品をユーザーに直接送信します。 その後、彼はもちろん、何が起こっているかを監視し、何かが壊れている場合、変更をロールバックし、問題に対処し、プロセスを繰り返します。 予算が特定の期間に完全に費やされていない場合、経営陣は従業員に「より多くのリスクを負わなければならない」ことを思い出させると聞きました。

私は内部からプロセスを見たことがないので、これが良いか悪いかについてコメントするつもりはありません。 しかし、ある種のビジネスでは、一定の寛容さと厚手の管理が行われているため、このアプローチは非常に適切です。 さらに、この会社は市場で非常に活気があり、一般に業界のリーダーであるという事実は、すべてに完全に満足していることを示唆しています。

当社では、探索的テスト（研究テスト）とアドホックテスト（直観的テスト）を非常に広く使用しています。 これは、テスト中のテスターが製品または機能を研究し、以前に蓄積された経験と基本的な知識を使用して、テストする製品のどのコーナーを調べ、どのように行動するかを決定するときです。 このおかげで、私たちのチームは「フレア」とテスターの才能を持つ専門家に非常によく慣れていますが、一方で、これは「通りから」人々を雇う可能性を排除します。 テスターは、大文字の専門家であり、市場では高価です。 これはおそらく、品質を節約しようとする一部の企業にとってマイナスになる可能性があります。

テストケースの定義済みリストはありません。 代わりに、2つのアプローチを使用します。 まず、可能なすべてを自動化します。 次に、チェックリストを使用します。 自動テストは、機能、特にリグレッションの検証に必要な時間tを最小限に抑えるのに役立ち、チェックリストを使用すると、研究テスト中に製品の重要な部分を覚えることができます。 チェックリストが「そこに行って、そのようなボタンをクリックして、黄色のダイが現れたことを確認する」という形式で書かれていないことが重要です。 「赤い車を探しながら80年間ジンバブエからユーザーをチェックします」、「女の子は男の子のために隠されたコメントを見ます」、「承認フォームが変更されました-Cookieをクリアして確認します」-これらは、アプリケーションの脆弱な部分を非宣言的に示す良いリマインダーです。あなたの想像力を完全に活用してください。

タスクを再検出する正しい時間を決定するために、次のピラミッドを使用することをお勧めします。

まず、すべての肯定的なシナリオを確認します。 アプリケーションは主張されていることを行いますか？ 述べられているとおりに動作しますか？ 実際、開発者がオンラインストアのウェブサイトに新しいバスケットを作成し、このバスケットに何も入れられない場合、これは機能が機能しないことを意味し、彼の週末の夜遅くまで働いていて非常に疲れていたとしても、彼の作品の価格は0ルーブル0コペックです。 ユーザーはそのような「製品」に興味がなく、競争の激しい環境では彼は去り、二度と戻りません。

さらに、ご存知のように、当社では開発者が品質に責任を負っています。 さらに、最小限のタスクの再発見に努めています。 したがって、開発者はポジティブなシナリオを個別に検証する必要があります。 そして、ビジュアルQAがこれを再び助けてくれます。 プロセスの次の参加者（コードレビュー、テストなど）にタスクを与える前に、開発者はプロダクトマネージャーに来て、彼の作業の結果を見せなければなりません。 明らかに、彼はPRDのプロダクトマネージャーが示したように機能するすべてに興味を持っています。

したがって、テスト中に肯定的な使用シナリオで欠陥が見つかった場合、タスクは再発見されます。 これがタスクを再発見する最初の理由です。

自動テスト-タスク用でない場合、またはパスしない場合-これは、タスクの再開につながる可能性がある検証の段階でもあります。 テストの一般的なリストではシナリオが異なっていることは明らかであり、その中には否定的なものもあります。 しかし、自動化されたテストは迅速に合格し（最適化に絶えず取り組んでいます）、手動チェックと並行して実行できます。つまり、一般的な目標-βを最適化する-は、この段階ですでに非常にうまく機能しています。 したがって、開発者は、テストが自分のタスクのブランチでパスすることも確認する必要があります。

肯定的なシナリオを確認した後、否定的なシナリオに進みます。 ピラミッドのこのセクションの領域は大きくなります。したがって、これらのシナリオをテストするための時間がさらに必要になる場合があります。 この段階で、非標準のユーザーの動作を確認します。 どこかで、彼は計画された購入シナリオで間違いを犯したかもしれず、システムは彼にこれを許しました。 どこかで間違って間違ったものを突いてしまい、ログアウトしました。 電話番号のフィールドに姓を入力しました-アプリケーションがクラッシュしました。 一般的に、私たちはあらゆる可能な方法で「システムを壊し」、「愚か者からの保護」を感じようとしています。 ところで、情報セキュリティチェックもこのカテゴリに属します。

タスクを再開する方法はそれぞれ次のとおりです。ネガティブシナリオをチェックし、チケットで見つかったすべてを収集し、タスクを再発見しました。

ネガティブなシナリオをチェックするとき、私たちは常識に導かれ、最も可能性の高いシナリオをチェックしようとします。 ピラミッドの次の部分の場合-私たちはそれらを呼ぶコーナーケース-それらとネガティブシナリオの間の線はそれほど明白ではありません。 これには、ユーザーの観点から非常に具体的な瞬間が含まれている必要があり、時には物議を醸すことさえあります。 たとえば、iOSの[排他的タッチ]オプションが設定されているかどうかを確認します。 または、画面を数回ひねり、元々Android用に画面を開いたときとは異なる画面の向きから戻ります。 このタイプのテストは非常に時間がかかり、一部の企業にとっては法外に高価です。

それでも、多くのチームで定期的にコーナーケースをチェックしています。 さらに、場合によっては、タスクごとに繰り返されるエラーが発生し、開発者、テスター、ユーザーがリリースに苦しみ、リリースを延期するたびに、チェックの初期段階に進みました。 , , , , Code Review. - , , . / , , - . , , – , , .

自動化

. .

, β , S, . Mobile Web, , ( , ).

.

, - , , «» ? , , , .

, – . , . AIDA . , , , . , AIDA , .

. – , S, – . , ? , , « » .

, , . – , . – . , , , . – , , , – .

, . , « » , , , , . . , – . , , .

, . , « ». , - , . : ( ), , . , - , ? : « , «» «», – . . , , « » — , , .

( ) ( Automation Pyramid , Page Object , Data-driven-testing , Model-based-testing . .). , , – , . , , , . – .

おわりに

, , . , , , . , « » .

, , , β – , , . , S . . – .

, , , , β, , . « ?». , , , ( - , , ).

. , , . , , . , . , .

ご清聴ありがとうございました！