Lean Startup方法論からのすべてのベスト、およびテスターの生き方

「これは昨日行う必要があります」、「できるだけ早くテストする」、「開発の開始から本番稼働までの時間は最小限に抑える必要があり、可能であればさらに短くする必要があります。 そして、私たち（テスター）は開発チェーンの最後のリンクの1つですが、ほとんどの場合、機能の出力速度と品質のバランスを取る必要があります。



この記事では、（私たちのプロジェクトの多くが完全に形成され落ち着いているという事実にもかかわらず）私たちの会社でLean Startupから成功したプラクティスを適用する方法、この方法論を使用するときにテスターが直面する問題とこれらの困難に対処する方法を共有したいと思います。



私自身に関するいくつかの言葉：私はテスターであり、さまざまな規模のプロジェクトの経験があり、プロジェクトの唯一のテスターであり、さまざまなアプローチと方法論を使用するチームで働いていました。 私の経験では、リーンスタートアップでの作業はクールですが、事前に知っておくとよいテストの落とし穴があります。



まず、私たちの会社が何をしているかについて少し話をする価値があります。 Tutu.ru-鉄道、航空、バスのチケット、ツアー、旅行に関連するその他のもののオンライン購入サービス。 私たちのプロジェクトの1つである「 ツアー 」は、まだ活発な開発の段階にあり、非常に動的で、機能は急速に変化しています。 PO（製品オーバー）はリーンスタートアップを実践しており、特に多くの実験を行っています。

リーンスタートアップ、マネージャーの要望、シンプルなテスターの現実

もちろん、私たちはまったくスタートアップではありませんが、リーンスタートアップのコンセプトには、私たちを含む多くの興味深いことがあります。 Lean Startupは何を意味しますか？

1. 不要なコストを最小限に抑え、あらゆる手段を節約します。
2. 各従業員の製品を作成するプロセスへの関与。 言い換えれば、この決定にかかる費用。 より速くできる場合、および-機能を追加し、結果を慎重に確認する場合-マネージャー、RO、または他の神話上の人々だけでなく、私たち自身も考えるべきです。 私たち一人一人。 テストする前に、次のことを自問する必要があります。機能/プロジェクトの目的は何ですか？ テストプロセスのためにテストするのではなく、いくつかの目標、機能に従ってテストします。
3. ユーザーオリエンテーションおよび単位時間あたりの顧客情報の最大量の取得。 はい、私たちはユーザーのことを考え、気にしています。 私たちは、技術的な面からエンジニアだけでなく、彼らにとっても、つまり最終製品を使用する人々にとっても便利なようにしています。

また、ユーザーが誰であるか、何を望んでいるか、何が好きで何が好きでないかを理解するために、高速の反復で実験を行います。



このすべてのポイントは、最低限実行可能な機能を作成し、仮説をテストし、分析の結果に基づいて、この仮説（機能）をさらに開発する必要があるかどうかを調べることです。 実験により、誰も必要としない機能を開発するリスクを軽減します。 同時に、必要な情報を可能な限り迅速に取得し、受信したデータに応じてすべてを完了させるために、できるだけ早く、可能な限り短い反復を必要とします。



管理の観点から-もちろん、これはすべて非常に楽しく健康的です。必要な機能をすばやく見、仮説とオプションをすばやく確認し、結果に応じて機能をすばやく変更します。 しかし、テスターはこれらすべてで何をしますか？ 私たちが絶えず聞くとき：「より速く、さらに速く！ この機能は、昨日実稼働する予定でした！」



さまざまな手法を適用し、カバレッジを無期限に増やすことができます。その後、最高レベルの品質を確保します。 そしてもちろん、私たちのプロジェクトと新しい機能が最高品質で最高のものであることを望んでいます。 しかし、これにはすべて、特定のリソース（労力、お金、時間）がかかることを理解する必要があります。



頻繁な実験の状況では、通常これらのリソースはありません。迅速に行われた結果をリリースして分析する必要があります。 さらに、この段階では、プロジェクトは、夢や秘密の欲求で提供したい最高レベルの品質を必要としないかもしれません 。 同時に、新しい機能は特定のレベルまで高品質である必要があるため、テストボリュームを完全に廃棄したり、大幅に削減したりすることはできません。 しかし、この境界線はどこにありますか？ このバランスを保つ方法は？ プロジェクトのニーズに合わせてテストを拡張する方法は？



これを行うには、次の方法とツールを使用します。

1. ビジネス分析タスク
2. リスク管理
3. 品質のグラデーション
4. 開発者チェックリスト
5. 「遅延」ドキュメントの作成

次に、これらの各ポイントをより詳細に検討します。

ビジネス分析タスク

もちろん、私たち（テスター）が本格的なビジネス分析を実施しているとは言えません。最終的には、このための特別な人がおり、タスクは非常に広範囲に及びます。 しかし、私たちはこれを私たちの現実と状況に当てはめようとします。 私たちはプロジェクトの目標に焦点を当てています。



たとえば、大人2人と2人の幼児（2歳未満の子供）のツアーを購入するユーザーの数がゼロになる傾向があることがわかっている場合-この場合、ツアーオペレーターが提供する部屋の種類を確認することはほとんどありません。これは誰にもなりません。 しかし同時に、大人2人と子供1人の検索と提案されたタイプの部屋を確実にチェックします-そのような話ははるかに頻繁に起こり、子供と一緒に検索すると間違いがしばしば観察されるため-このケースは境界であると言えます



または、たとえば、新しいプロバイダーを接続するためのAPIをテストするとき、ビジネスクラスのフライトでのツアーの価格に特別な注意を払うことはありません（主なことは、経済クラスの代わりにデフォルトで置き換えられないことです！） 、このセクションの全期間を希望した観光客は1人だけでした。



テスターに​​とって難しいケースをテストする誘惑は常に素晴らしいものですが、主なことは現実を忘れないことです。

リスク管理

品質保証の目標は、リスクを減らすことです。 無制限のリソースを所有していても、すべてのリスクを完全に排除することはできませんでした。

時間、お金、またはその他のものによって制限されている場合、リスクを2つのグループに分けます。

1. 有効な
2. 無効です

最初のカテゴリには、動作しない可能性のあるもの、正しく動作しないもの、それらに何か問題があることさえ知らない場合があります（これは最悪のことです！）-これは正常です。 タスクを高速化するため、または別の目標のためにこれらのリスクを取ることができます。



ここで何ができますか？ いくつかの追加シナリオ、統計によると、「ほとんど誰も突かない」（たとえば、ユーザーの0.1％）、人気のないブラウザーなどで動作する場所



2番目のカテゴリ -許容できないリスク-には、確実に機能するものと確信すべきものが含まれます。 ユーザーに最小限の機能を提供する必要があります。 ユーザーが渓谷を通過し、最終的にブリッジの半分を解放するのに役立つ機能を作成する場合、ユーザーの問題を解決しないため、これは適切ではありません。 そのような実験は常に否定的な結果を示し、これは許容できないリスクに適用されます。 そして、峡谷の両側のロープでロープを引くと、反対側に切り替えることができます。これは、ユーザーの問題を解決できることを意味します。



許容できるリスクを管理し、許容できないリスクを減らします。

品質のグラデーション

全体としてのグラデーションは前の段落から続き、テスターとROの両方の便宜のために作成されました。 彼らは私たちの間のゲームのルールに同意します。 品質には5段階のグラデーションがあり、それぞれが特定の数の物に対応しています。







たとえば、グラデーション2では、ユーザーの間で最も人気のある1つのブラウザーで機能が適切に動作し、基本的なユーザースクリプトが実行され、主要なビジネス機能が動作することを確認する必要があります。



品質レベル5では、上記のすべてに加えて、次のことに注意を払っています。

• 追加のユーザーシナリオとビジネス機能
• UI
• サポートされているすべてのブラウザーおよびモバイルデバイスで表示します。
• メインおよび追加のユーザーシナリオの自動化の最大レベル。
• テスト容易性。

また、プロジェクトやタスクごとに異なる明確に定義された品質レベルを設定できるという点でも便利です。



実験的なタスクの場合、品質レベルは低く設定され、そのようなタスクがさらに発展することが決定されると、品質のグラデーションはそれらとともに大きくなります。 たとえば、近隣の日と月、および類似国（現在の検索と比較して）の価格をユーザーに提供すると、ユーザーにとって興味深く有用であると想定します。 しかし、技術的にはこのタスクは非常に複雑なので、ユーザーからの関心があるかどうかを確認するために、いわばデモモードで実行します。 このフォームで、タスクがテストに該当するとします。 そして、検索が2人（デフォルトオプション、最も人気のある）に対して実行された場合、次の月の価格は同様の国に適切であり、嘘をつかないことが突然わかります。 しかし、2つではなく3つまたは1つを検索する場合-ここでは「ああ」-すべてがバラ色ではありません。 そしてこの段階で、テスターとして、開発者と相談し、編集に非常に時間がかかることを知った後、タスクをそのままリリースすることにします。



次に、分析を収集し、訪問者の約40％がこの新しいブロックを使用することを理解しています。 次に、タスクの次のイテレーションを開始します。ここでは品質の段階がより高くなります。機能を開発する必要があり、異なる人数を検索するときに「間違った価格」を支払う余裕がないことに気付きました。



ここで、この場合の主なシナリオは何か、追加のシナリオは何かについて、疑問が残る場合があります。







リーンに戻ると、すべては私たちがいるプロジェクトの段階に大きく依存します。



左側のこの図は、リーン分析プロジェクトの段階と、いわゆる「ゲート」（右側）を示しています。これらの段階を経て次の段階に進む必要があります。 これらの手順の簡単な説明を次に示します。

• 共感 この段階の目標は、潜在的な購入者に製品開発と実験について知らせることです。 この場合のゲートは、実際の関連するまだ解決されていない問題の明確な定義です。 これで決定したので、先に進むことができます。
• べたつき。 ユーザーが戻ってくるような機能を実行してください。 ゲートは、彼らが支払う準備ができている問題を解決するための定式化された方法論です。
• バイラリティ ユーザー数を最大化します（有料の方法を使用するか、使用しないことが望ましい）。 ゲート-ユーザーの数、および機能の品質と関連性が高まっています。
• 収益。 このプロジェクトはお金をもたらすはずであり、あなたがそれ以上に使う必要があります。 ゲート-あなたは市場で自分のニッチを見つけて占有しました。

したがって、どのシナリオが現在補完的かつ基本的であると考えられているかを理解するには、プロジェクトが現在どの段階にあるのかを検討する価値があります。



たとえば、スティッキーネスステージでは、さまざまな「機能」と特徴的な機能が重要になります。バイラリティステージでは、SEOなしではできません。現在プロジェクトの内容がわかっていれば、品質保証プロセスにさらに効果的に取り組み、利益」それが本当に必要な場合にのみ。

開発者用のチェックリスト（受け入れ基準）。

ここでは、タスクの作業サイクル全体の速度を上げることについて説明します。



理想的な世界では、各チームメンバーが品質に責任を負います。 未処理のタスクはテストでは受信されません。 テスターは重大なバグを見つけません。なぜなら、 開発者はすでにすべてを考慮しています。 私たちの世界は完璧ではありません。 私たちは、タスクが明らかなバグで私たちにやってきたという事実に直面しました。 しかし、明らかなものはありません。 そのような状況は私たちだけに透過的でした-テスター。



開発者の考え方は異なります-これは正常で自然なことです。 そして、それがプロジェクトの「私たちのビジョン」をできるだけ早く、できればテスト自体の開始前であっても導入したい理由です。



この方法を見つけました。いわゆる「開発者向けチェックリスト」（受け入れ基準）を使用しています。



このチェックリストは、特定のパラメーター、データ、リンク、およびオブジェクトの予想される動作の説明を含むチェックのリストです。 同時に、チェックリストが使いやすく、速く、楽しくなるように、パスの数を最小化し、チェックの最大数を配置しようとします。 チェックリストは、開発者がそこから項目をスキップしないように、十分にシンプルで簡潔でなければなりません。 ネガティブチェックが含まれることはほとんどありません。 開発者がタスクを完了していないときにのみチェックリストを作成するのは理にかなっています。なぜなら、目標はタスクからタスクへの切り替えの最小数だからです。 この時点までにチェックリストを作成する時間がなかった場合は、まったく作成しません。



さらに、開発者がチェックリストに合格した場合、これはテスト中にチェックリストに記載されているものを調べる必要がないという意味ではありません。 万が一に備えて、それらを常にすばやく確認する必要があります。 ここで、製品に対する私たちの認識の違いが役割を果たします。



チェックリストからの抜粋の例：

1. /ホテル/ 3442 /（検索パラメーターのないページ）に移動します
2. 「ツアーへのリンクを送信」はありません
3. XXXに移動します（パラメーター付きのホテルページへのリンクの例）
4. ダイが存在します
5. オファー価格をクリックして、次のステップに進むことができます
6. 一部支払いの可能性とツアーに含まれるものについての碑文があります
7. それらの反対に、価格ボタンの下に、「価格が下がった場合に見つける」という擬似リンクのあるプレートがあり、そこにカーソルを合わせるとパーセンテージがアクティブになり、赤に変わります
8. 「Show N more offer」リンクをクリックします
9. サブスクリプションの下、すでにロケールの外側にある右側の列には、「このホテルへのツアーへのリンクを電子メールで送信する」というプレートがあります。

私たちは1年以上にわたってチェックリストを使用してきましたが、すでにいくつかの結論を出すことができました。 テスターも開発者も、チェックリストは非常に便利で使いやすいと言っています。 実際、プラスは何ですか？

なぜテスターはこのようになっているのですか？

• 生のタスクが少なくなります。
• テスターは以前、タスクの作業プロセスに関与しています。

開発方法論が柔軟である場合、プロジェクトには原則としてほとんどドキュメントと仕様がありません。 プロジェクトが動的であり、ROが絶えず実験している場合（私たちがそうであるように）、「予備」のドキュメントはあまり意味がありません-通常、ユーザーストーリーとサンプルソリューションしかありません。 したがって、この状況では、個別のユニットとしての「テスト要件」の段階は単に存在しません。 しかし、テスターが要件の形成に参加することは重要であり、開発者向けのチェックリストを作成する段階でこれを行います。 もちろん、タスクについて話し合ったり、レイアウトについて話し合ったりするための個別の会議もありますが、これでは十分ではありません。

• チェックリストを使用したタスクのテストは、チェックリストを使用しない同様のタスクのテストよりも時間がかかりません。
• 具体的かつ明確に策定し、製品の問題領域を強調することを学びます。
• 問題をさまざまな観点から見る機会があります。

ある人がタスクをテストしており、別の人がそのタスクにチェックリストを書いていることがよくあります。 スタイル、ビュー、テスト方法は少しずつ異なります。 「新鮮な」見た目でタスクを見ることができれば、とても健康的で便利です。

開発者はなぜこれを好むのですか？

• 検証する特定のデータを含むシナリオの明確なリスト。
• タスクの予備分析。
• 開発者は統計とフィードバックを取得します。

チェックリストで見つかったバグの性質を考慮に入れており、たとえば、誰かが特定の性質の間違いを犯していると言うことができます：ロジック、コードなど。 人々がどこが間違っているかを知っているとき、彼らは努力する何かを持っています、そして、彼らの間違いを修正することはより簡単です。



私たち全員が好きなこと：私たちは開発からタスクを10万回テストすることはしません。 チェックリストの段階で多くのことが修正されています。 そして、誰もが最初からすべてを正しく考慮し、理想的な世界に近づいています。 たぶんいつか。



マイナスのうち、タイムシートを書いて渡すにはまだ時間がかかることに注意することができます。 しかし、統計から判断すると、テストと開発の間にタスクが存在しない場合にタスクを投げるよりも時間がかかりません。 テスターは平均30分で1つのチェックリストを作成し、開発者は10〜30分でそれを確認します（タスクの複雑さに依存します）。



さらに、スプリントのすべてのタスクがチェックリストに「値する」わけではありません。 計画時に、タスクにチェックリストが必要かどうか疑問に思っています。 その結果、スプリントごとに6〜7個のチェックリストがあります（平均して、スプリントごとに約30のタスクを実行します）。 チェックリストの約67％が合格しました（開発者はチェックリストにバグを見つけませんでした）。 チェックリストのあるタスクの35％で、テスト中にバグは見つかりませんでした。

保留中のドキュメント

すべての新機能の詳細なテストケースを作成するという目標は設定していません。 そして、理由は同じです：実験タスク。 誰にも役に立たないドキュメントを書きたくありません。 機能がさらに開発されることが確実にわかっている場合は、機能を説明することをお勧めします。 保守しやすくするために、詳細をあまり記述しないケースを作成しています。 さらに、不必要な時間の損失を避けるために、ケースを書く前に何度か考えようとします。



私たちの現実の上記のツールはすべて本当に機能します-私たちはチェックしました。



これらは、品質と速度のバランスを維持するのに役立ちます。



→ SQA Days-19でのパフォーマンスに基づく



ここでパフォーマンスのビデオを見ることができます：