1. 背景
ビジネスの反復が速いため、開発セルフテスト要件と QA テスト要件の割合は同じですが、開発セルフテスト要件については、要件の品質を制御できず、セルフテスト要件の増加に伴い、QA のビジネスへの精通も不十分であるように見えます。
ビジネスの一部は全体として安定しており、イテレーションが少なくなりましたが、時折、オンラインで過去の問題が発生し、関連機能を使用する際に運用学生が開発学生に一時的に対処するよう依頼することがあります。
ビジネス注文の継続的な増加に伴い、NPS にもますます注目するようになりました。エクスペリエンスの問題はユーザー エクスペリエンスに深刻な影響を及ぼし、NPS を低下させます。優れたインタラクティブ エクスペリエンスは、NPS の向上とユーザーの維持に役立ちます。
上記課題を踏まえ、開発学生を定期的に組織し、一緒に業務監査を実施し、業務監査を通じて課題の解決、システム可用性の向上、オンライントラブルの軽減を目指します、監査を通じて誰もがユーザーの視点でサービスを理解し、体験することでユーザーエクスペリエンスを向上させ、最終的には監査を通じて全員の品質意識を向上させ、全員で品質に責任を持ちます！
2. 検査方法
検査を組織する前に、私たちは 2 つの問題、つまり、全員が検査にもっと積極的に参加するにはどうすればよいか、検査の効率を高めるにはどうすればよいかを考えてきました。「自分に合ったものが一番」という言葉の通り、最終的には事業特性に応じて検査の形態を分けることにしました。そこで、検査方法をご紹介する前に、私が担当している2つの事業について簡単に紹介させていただきます（以下、それぞれA事業、B事業と呼びます）。
2.1.ビジネス
1) ビジネスプロセス
２）事業の特徴
ビジネス プロセスは比較的短く単一であり、フロントエンドの対話型機能が多数あります。
3) 事業状況
全体的なビジネスは主に運用に基づいて安定しており、プロジェクトの繰り返しは比較的少なく、機能全体に若干の変更が加えられています。
2.2.B ビジネス
1) ビジネスプロセス
３）事業の特徴
プロセスは複雑かつ多様で、各ブランチは個別のビジネス ロジックです
4) 事業状況
ビジネスは急速な発展段階にあり、反復サイクルが短く、機能が頻繁に変更されます。
要約すると、両者のビジネス特性に応じて、A 社のビジネスプロセスが比較的単純であり、場合によっては全員の思考を制限する場合があることを考慮して、ユーザーの使用習慣をより適切にシミュレートして問題点を発見できる無償検査の方法を採用することを最終的に決定しました。B社の業務プロセスはさらに複雑で、無償点検ではすべてのプロセスをカバーできない可能性があるため、最終的には事例提供という手法を採用し、できるだけ多くのシナリオを全員がカバーできるように誘導し、ビジネスの観点からより適切な問題を発見するようにしています。
3. 集中力
この検査は主に機能、ページ、インタラクションなどに焦点を当てています。
- 機能：各機能の完成度
- ページ: 完全な表示、オクルージョンなし
- インタラクション: ユーザーの観点から見たページと機能間のインタラクション、それが受け入れられるかどうか、最適化の余地があるかどうか
4. 検査計画
4.1. 検査範囲の明確化
まずはメインプロセスの精度を確保した上で、業務モジュールごとに分割し、検査範囲を整理し、モジュールに応じて注目すべき機能モジュールの導入効果を絞り込む必要がある。
分割された業務モジュールと検査対象範囲は以下のとおりです。
モジュールが分割された後、特定のモジュールが分類され、検査方法ごとに異なる分類が実行されます。
4.2. 事前の事業仕分け
ビジネス：
A事業者では無償検査という手法を採用していますが、全員が各モジュールに精通していないため、検査前に事前に業務プロセスを整理・共有することで、検査前に業務を熟知し、より深い業務プロセスの検査を行うことができます。
ビジネスB:
事業Bの検査ケースを事前に整理し、検査前に全員に異なる検査ケースのテスト計画を作成し、検査プロセス中に参考にして、1つずつ検証します。
4.3. 点検頻度
集中検査は週に 1 回、1 ～ 2 時間行われ、QA、RD、FE が一緒に参加します。
4.4. QAの責任
巡回検査ごとに 2 名の常駐 QA が配置され、主に事件への回答と検査の問題点の記録を担当し、検査後に提出された問題点を追跡、解決、検証します。
5. 問題の記録
問題記録: バグの形式で記録し、対応する開発学生に提出します。
問題のフォローアップ: 問題解決の進捗状況に注意を払い、回帰を検証します。
問題の概要: 定期的に問題の種類を要約し、原因を分析し、経験を要約することで、将来同様の機能を実装するときに、どの点に注目する必要があるかを把握し、同じ落とし穴を何度も繰り返さないようにするのに便利です。
問題の概要を通じて、問題は主にコーディング エラー、ユーザー エクスペリエンス、製品設計、システム互換性に焦点を当てているのに対し、ユーザー エクスペリエンスの問題は主に小さなプログラムに焦点を当てていることがわかります。そのため、事後検討段階では、製品設計の合理性をより重視し、日常業務を避けて小規模プログラムの検証を強化し、経験上の問題の発生を低減します。
6. 収穫
検査中の最大の利点は、役割の変更です。まず第一に、QA 学生として、各機能の正確さと整合性を確保する必要があります。2つ目は、私たちもユーザーですので、ユーザーの視点から製品の合理性を考える必要があります。業務検査については、オンライン上の問題を簡単に手放さず、フォローアップを継続し、最終的な製品の品質を確保します。
最後に:熱心なファンに恩返しするために、完全なソフトウェア テスト ビデオ学習チュートリアルを作成しました。必要な場合は、無料で入手できます。【保证100%免费】
ソフトウェアテストの面接ドキュメント
「私たちは高給の仕事を見つけるために勉強しなければなりません。以下の面接の質問は、アリババ、テンセント、バイトなどの一流インターネット企業の最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。この一連の面接資料を読めば、誰もが満足のいく仕事を見つけることができると信じています。」
