今日は、モバイルゲームを3年間リリースしている小さな会社の例を使用して、テスト部門を作成することについてお話します。 特徴は、会社がスポンサーに依存せず、稼いだお金で生活していることです。 そして、従業員として、私たちの意見では、ユーザーが好きなことをすることが重要です。 視聴者のために実験して作業する機会がありますが、同時に、製品開発の時間ははるかに少なくなります。
QA部門の必要性は1年前に現れ、リリーススケジュールを破ることなくテストプロセスを構築する必要がありました。
モバイルゲーム開発のテスト：何が問題で何が問題か
モバイル開発のQAは、ちょっとした秘密のサービスです。 うまく機能していますが、テストが行われていることに誰も気づきません。 しかし、見逃すことは少なくとも一度はAkellaの価値があり、ゲームに関するコメントには怒りの程度の異なるメッセージがいっぱいです。 本質的に、モバイルテスターのタスクは、アプリケーションに目立つバグを最小限に抑え、開発チームが各リリースの意味を明確に理解し、結果を達成するために取り組むことです。
テストは製品の改善に役立つ要因ですが、不適切に使用された場合、システムの負荷要素にもなり、リリースが大幅に遅れます。 当社では、ゲームをテストするために2営業日が設けられています。1日目-製品のテストと完成。 2日目-ゲームは最後のチェックに合格し、市場に行きます。
テストプロセスでは、次の問題に直面します。
- テスト自動化なし
- 完全なテストと機能テストへの異なるアプローチ
- 他の部門への依存。 他の従業員からの締め切りに間に合わないと、混雑に影響します。 リリースがまったくない週と週が交互に重なる週
- ゲームデザインまたはUIの欠陥を見つける方法を学ぶ必要性。 テスト段階が無駄なゲームを放棄するのに役立つ状況があります。
プロセスと結果。 すべてを変えるが、何も壊さない方法
私が入社する前に、チーム内でテストが行われました。 今、これは時間を置く必要がある別の段階です。 しばらくの間、すべては「最初に合格した人がテストされる」という原則に基づいて行われました。 各リリースの重要性を理解していないため、リリースを転送したくありませんでした。 この形式の欠点は、週の終わりに頻繁に処理されることと、週の初めに雇用がなくなることです。
プロセスを均一にすることになった最初のツールは、テストの日付を設定するタイムスケジュールでした。 これは、ワークロードが均一になるように行われました。 計画によれば、週末までに出てくる時間がなかったすべてのリリースは、来週の初めに雇用を創出することでした。 この制限は機能しましたが、優先順位が混乱したり、より重要なリリースの前に待機できるゲームがリリースされたりする場合がありました。
プロセスと、テストに入るすべてのタスクの視覚化が必要でした。 Jiraでかんばんボードを開始しました。 それが何であるか理解していない人は、デビッド・アンダースの本「カンバン。 アジャイルの代替方法。」
1週間に1回、月曜日に、短い計画でヘムデザイナーと会いました。その結果、1週間の計画と優先順位が設定されました。 メインプランに追加されるプロジェクトは個別に議論され、次の週に自動的に終了するか、スケジュールに「ウィンドウ」が表示された場合にのみテストに該当しました。
ワークロードはより明確になり、より透明になりましたが、残念ながら、より均一にはなりませんでした。 かんばんは、テストの問題だけでなく、部門と個々の専門家間のコミュニケーションにおける一般的な問題も示しました。 さらに、懸念の新たな原因が現れました。同僚と話すことの重要性が忘れられています。 誰もが自分の仕事をうまくやり遂げたが、他の人を見ない状況がありました。 その結果、分析期間が終了するという事実のためにサポートされ、緊急の更新を必要とするプロジェクトの1つが3日間延期されました。 もちろん、これらは金銭的な損失と情報の損失です。
その状況から学んだ主な教訓の1つは、次のように自分で定式化することです。
“ . - . , . , ”.
相互作用に加えて、雇用の分布を調整することは私たちに残っています。 解決策は、当初見られたよりも簡単であることが判明しました。水曜日の夜に集会を追加しました。 その結果、月曜日に1週間の優先順位を設定し、水曜日に金曜日のリリーススケジュールについて話し合います。 今、すでに週の半ばには、ほぼ確実に誰もが何が起こるか、何がうまくいかないかを知っており、誰もが時間通りに家を出ることができます。 チームはより具体的に内部期限を設定します。
計画外の集会を1つまとめて15分間過ごすのは、結果として全員が単純に正しく解釈しなかったプロセスに3日間従うよりもはるかに簡単です。 結果は、すべての従業員が自分の仕事をうまくやるには不十分であると認識している場合にのみ得られます。 この仕事がなぜ行われているのかを常に考え、他の人が同じことをするのを助けてください。
近い将来、「fakapを使用した自己テスト」に基づいた最新のテストシステムを導入します。 ポイントは、チームが必要性を証明した場合、QA部門をバイパスしてゲームをリリースできることです。 つまり、彼らはリリースが必要であることを明確に理解しますが、遅延のために、メインのテストグリッドに落ちません。 もちろん、彼自身の責任の下で。 この場合、チームが自分の遅延のために余分な仕事をすることは最も望ましいケースではないため、チームはより冷静に彼らの強さを評価するため、部門の負担を軽減し、全体的な労働規律を高めることができるという仮説があります。
最後のお別れ
生産的な部門を作成するには、古典的なテストに加えて、「品質管理」と呼ばれるものに正しく対処する必要があります。 ゲームがそのようなものだけでなく、特定の目的のために出てくることを確認してください。 また、現代のダイナミックな市場で視聴者とビジネスのニーズを調査することも不必要ではありません。
自動化の欠如は、制限と機会の両方を提供します。 一方では、より基本的なことを自分で確認する必要があります。 しかし、一方で、ビジネスの追加の側面を探求する時間ははるかに多く残されています。 また、テストをより効果的に実行できるツールがたくさんあります。 「ヒューリスティック」または正しく構成された「チェックリスト」のみが別の記事に値します。 ただし、これについては個別に話す必要があります。
部門とそのプロセスを構築するとき、次の2つのことを覚えて理解することが重要であり、必要です。
他の従業員の利益を侵害しないように作業プロセスを整理する方法。
プロセスの中断に適切に対応する方法。 目標と結果は、厳密な遵守よりもはるかに重要です。