こんにちは 私の名前はダーシャです。iOSで2GISモバイルアプリをテストしています。 機能管理プロセスを共有したいので、時間を節約できるだけでなく、個人のスキルも向上します。 記事を読んで、製品、デザイナー、開発を同じコンテキストに維持する方法を確認してください。 すべての関係者が最初のテストアセンブリをレビューすることで、実際に作業が楽になると信じています。 そして、コミュニケーションは機能を管理するための鍵です。
私たちの痛み
他社のテスターとコミュニケーションをとるとき、彼らの機能をテストすることはなんとなく面倒で構造化されていないことにしばしば気付きます。 このため、時間が無駄になり、開発に携わる人々の力が失われます。 人々は悪になり、同僚を憎み始め、ポーチで彼らを待ちます。
以前は、似たようなものもありました。スプリントを計画するとき、タスクが飛び込み、スプリントの開始時にそれが開発に取り入れられ、私たちはすでにプロセスの中でタスクを解決しました。 他のチームとのやり取りについて質問がある場合は、製品にアクセスしました。 いくつかのチームでは、仕事がすでに本格的に行われていることがよくありました。誰もがリリースを楽しみにしていました。 他のチームでは、その存在すら知りませんでした。 そのようなプロセスは効果がなく、多くの時間/努力を費やし、混乱をもたらしました。
その結果、彼らはそのように生きることは不可能であることに気づき、新しいプロセスを構築し始めました。 彼はすでに誰かの神経、そしておそらく命を救うのを手伝っています。
チームについて
私たちのチームは、9人の開発者、6人のテスター、製品とデザイナーで構成されています。 反復を計画するとき（今後4か月以内に行うこと）、現在の期間にリリースする機能がコンパイルされます。 リストがコンパイルされると、開発およびテストのチームからの機能ごとに1つの機能が割り当てられ、最初から最後まで機能が使用されます。
私たちにとって、フィーチャーされているのは、TKからリリースまでの機能とともに生きている人です。 彼は機能全体に何が起こるかについての最新情報を持ち、他のチームの人々のために機能に取り組むことに関する質問のエントリーポイントとして機能します。 Sasha Kartavtsevによるレポートの最後に、機能の詳細が記載されています。 この用語を覚えておいてください。そうすれば、それは複数回発見されます。
9段階でリリース
機能をリリースするプロセス全体は、9つの主要な段階に分けることができます。 わかりやすくするために、最近リリースされた「報酬」の機能を取り上げ、9つのステージすべてでどのように実施したかを説明します。
賞は、製品への貢献に対するユーザーの報酬です。 ユーザーは、レビューを書いたり、写真をアップロードしたり、新しい会社をディレクトリに追加したりするためにそれらを取得します。 これらは「My 2GIS」タブで見ることができます。
ステージ1-TK開発プロセス
機能を使い始める前に、私たちはゆったりとしたチャットルームを作成し、そこに関係するすべての人に電話をかけました。 その中で、リリースのコースに影響を与える可能性のあるチャット参加者の生活の中での機能とイベントに関するすべての問題を議論することに同意しました。 私が牛乳に行ったと言うことは必要ではありませんが、休日/病気休暇について話をする必要があります。そうしないと、あなたは応答しないために憎しみにぶつかる危険を冒します。
まず、開発とテストの機能は、他の機能の経験に基づいて、TK /設計、質問、改善案を検討しました。 24時間以内に質問に回答できるように、極端な機能が監視されました。 締め切りが遅れた場合、これらの同じ人は製品/責任者に時計が刻々と過ぎていることをほのめかし、すでに答えておくといいでしょう。
TKの開発プロセスは、すべての主要な問題が解決し、最終設計が完了した時点で完了したと見なされます。開発には機能の実装に関する質問はありません。
最初の段階では、機能のプロトタイプを作成してTKの開発に使用することは非常にクールです。初期段階で機能をデバイスで感じて欠陥を特定し、テストのケースを見つけるのに役立ちます。 製品は、プラットフォームでの開発が開始される前であっても、ロジックを変更できます。
ステージ2-チェックリストの作成
ToRの開発プロセスでは、テストの機能として、私はTestRailの機能のテストケースを作成しました。この機能はその後、機能の検証に使用されました。 さらなる自動化のための優先順位付けされたケース。 この機能にはバックエンドがあるため、テストプランにチェックを追加しました。どのフィールドを送信し、どのフィールドを受信し、ナンセンスがここに来るとどうなるかを確認します。 機能からの期待を同期するために、完成したチェックリストを開発と製品に与えて、テストが1つのことを考え、製品が別のことを期待し、開発者が別のことをすることが起こらないようにします。
ステージ3-開発
ToRの開発後、機能の開発が始まりました。 その時点でのテストは、ToRとチャットルームでの未解決の問題を解決/議論し、新しい要件、新しいデザイン、新しいテキスト、その他のすべての変更の開発を通知しました。開発はすべてを認識している必要があります。そうでなければ、戦いを避ける方法はありません
ステージ4-最初のフィーチャーアセンブリのレビュー
最初のアセンブリを受け取った後、私たちはそれを機能チャットに投入し、製品とデザイナーにレビューを依頼しました。 テストは、アセンブリが表示され、フィードバックが与えられることを制御しました-より速く、より良い。 これは初期段階で行われるため、後の不快な状況は発生しません。
不快な状況の例
夜は家で静かに座ります。誰にも触れないでください。 あなたはすべてが遅れていると思います、明日機能は戦いに行きます。 しかし、朝の1時に、悪意のある製品があなたの家（私の上の3階に住んでいるので、これは本当です）またはデザイナー（これはすでにそれほど現実的ではありません、彼は私の遠くに住んでいますが、彼は車を持っています）に緊急にフォントを修正する要件があります/色/パディング、そうでなければ「リリースしないでください！ あなたはそのように外出することはできません」と午前中にPR会社はすでに概説されていました、そしてそれはそれです、それはすべてドレインの下にあります。 そして今、あなたは午前2時に座り、開発者に電話して、チケットを開始します。 一般的に、適切な人からタイムリーに受け取ったフィードバックは貴重です。 最初に入手しても、この側面からのリリースを締めることはできません。
ステージ5 —プラットフォームテスト
最初のアセンブリのレビューと並行して、以前にコンパイルされたテストケースを使用して、プラットフォームでテストが開始されました。 テストプロセス中に、リリースを中断する恐れのある問題を見つけた場合、または何か改善できると気付いた場合、チャットに機能を追加したり、TORにコメントを残したりします。 私たちは、質問が開かれたままになっていないのを見ました。
同じ段階で、機能のロジックに変更がありました（たとえば、UI）-また、製品と設計者にアセンブリを提供して、期待と現実が一致することを確認するためのレビューを行いました。
ステージ6-統合テスト
この項目は、携帯電話以外のチームが機能の開発に参加する場合に必要です。 たとえば、携帯電話+バックエンド。 アイコンのフォントまたは色を置き換えた場合、もちろん統合は行われません。 ただし、Rewardsの例では、バックエンドが関係しています-統合が不可欠でした。
最初に行うことは、Confluenceでドックを作成することでした。 原則として、最初に1人がこれに従事します。
この文書は次を規定しています：
-実施日;
-参加者-チームが視覚的にヒーローを知っているため、ヒーローはこの事実に反論することはできません。
-チェックのリスト。
-ケースのリスト-特定の条件でシナリオをチェックします。
ドックをコンパイルした後、私はそれを機能チャットに投入し、すべての統合参加者にケースのレビュー/補足を奨励しました。
X日目に、統合参加者は1つのオフィスに集まり、統合ドックからすべてのシナリオをチェックしました。 バックエンドチームと共同で統合することは素晴らしいことです。すべての問題をその場ですぐに解決し、すべての奇妙な点を明確にします。
ステージ7-サポートブリーフィング
リリース前に、彼らはサポートが機能がすぐにリリースされることをサポートに通知しました、それは準備ができている時間です。 ダリはTK、ポケアセンブリを読みます。 彼らは、どのチャットを書くべきか、そしてユーザーからフィードバックを受け取った場合に誰に連絡するべきかを報告しました。
ステージ8-リリース
機能の展開を開始し、チャットについて通知し、並行してCrashlytics、ストアおよびサポートでのフィードバックを見ました。 私たちは、最高の飲んだバレリアンを望みました。 リワードではすべてが順調に進みましたが、ロールアウト中にプラットフォーム側で重大なバグが見つかった場合、すぐに修正プログラムを作成し、機能チャットの全員に通知する準備ができました。
ステージ9-リリース後の機能のサポート
機能が戦闘に入った後、私たちの役割は情報提供になりました。彼らは入ってくる質問に答え、プロンプトを出し、プラットフォームの問題を整理し、問題がバックエンドにあると理解したら、それらを渡しました。 リリース後、リワードチェックのケースをテストトレイルのメインケースストレージに注ぎ、将来再利用できるようにしました。
そして簡単に
- 常に全員を同じコンテキストに保ちます。 重要な変更を報告します。
- 機能付きのアセンブリが表示されたらすぐに、すべての関係者による最初のアセンブリのレビューを整理します。
- いずれかの段階で機能のロジックに変更が生じた場合は、レビューも整理します。
- 答えを得る：あなたが応答するまで、書く、電話する、蹴る。
- 新機能のサポートを準備し、起動後にサポートします。
このプロセスで得た知識と経験は、仕事でも人生でも役立ちます。 コミュニケーション、独立性、責任を高め、チームの仕事を超えて製品に没頭しました。 ちなみに、チームも幸せです-ファカプの場合、彼は今ではバレリアンではなくワインを飲みます。