QA best practices
1.0.0
これは、Futuriceが使用するQAプラクティスの要約であり、使用することをお勧めします。それは詳細な説明であるとは想定されておらず、すべてのタスクで完全に使用することはできませんが、最も重要なQAプロセスの概要として、および使用すべき優れたプラクティスのリストとして使用できます。
明確な目的のために、このドキュメントはエラーまたはインシデントプロセスを説明していません（つまり、生産から新しいバグが見つかります）。
Futuriceチームの全員が、QAマネージャーまたはQAの専門家が指名されていても、QAの責任を負っています。 Futurice QAにとっては3つのことを意味します。
高レベルでは、QA作業と実践を2つのプロセスに分けることができます。
さらに、他のQAアクションがあります。
Futuriceは、該当する場合、TDDおよびATDD（受け入れテスト駆動型開発）メソッドを使用します。
メソッドは、実装を強制してアーキテクチャに従い、使用されるモジュールを検討します。実装は、最初に自動化されたテストを作成し、次に機能を実装してテストに合格することから始まります。
Futuriceは、該当する場合はペアプログラミング方法を使用します。これは、開発中のプロジェクトとソフトウェアに関する知識と経験を共有するための非常に便利な方法です。
コードのレビューは、他のチームメンバーが特定の機能の情報を取得するのに役立ち、責任者にフィードバックを提供する可能性を与え、またチームメンバー間の知識共有を保証します。
手動テストは主に探索的テストの方法論を使用して行われ、発見されたエラーはすぐに固定されているか、タスク/ストーリー/エラー管理ツールに優先順位を付けられて記録されます。アプリまたはサービスの探索は、機能的なものが「準備ができている」後すぐに開始できます。
探索的テストは、システム全体がテストによってカバーされている場所で非常に強力なツールです。メソッドでは、テスターはテストケースで定義できるものを超えて、ユーザーのような思考を適用し、さまざまなエラーシナリオでシステムを破ろうとし、テストで「完了」しないようにします。
機能的要件とテストの周りには、通常、ローカリゼーション、使いやすさ、パフォーマンス、負荷テストを適用してテストできる非機能要件があります。ニーズとツールはプロジェクト固有のものです。ユーザビリティテストのために、Futuriceには使用するモバイルユーザビリティラボがあります。パフォーマンステストのために、FuturiceはBrowsermobなどのWebベースのサービスを使用して1つの名前を付けています。負荷テスト用LoadUIおよびJメーターは、トラフィックの高いサービス機能を検証し、可能なサービスボトルネックを見つけるために積極的に使用されています。
見つかった問題は、優先度、環境（ソフトウェアおよびデバイス情報）、再現する手順、期待される結果、時間と日付、スクリーンショットなどの情報を含む特定のツールまたはボードに記録されます。 Jira、Trello、Pivotaltracker、Request Trackerなどのツールは、エラー追跡にも積極的に使用されています。
アジャイルの原則の1つは、マスターコードブランチが常に跳ね返る可能性があることです。つまり、常に生産品質である必要があります。これは、次の手段によって達成されます。
各ユーザーストーリー（または機能）は、独自の機能ブランチで個別に開発されています。これの目的は、マスターブランチへの各更新が同時に同時に1）可能な限り小さいことを保証することです。
機能ブランチをマスターブランチにマージする前に、DONE（DOD）の定義と呼ばれるアクション、要件、および実践のリストを渡す必要があります。これは、顧客POおよび開発チームとともに定義され、プロジェクトのニーズが変化した場合、プロジェクト中に変更できます。
提案されたDODの次の項目は大胆にされています
展開プロセスは、新しいリリース（またはマスターブランチのバージョン）が生産に展開される方法のプロセスです。このプロセスには、関連する3つの環境があります。
継続的な統合（CI）サーバーは、自動化されたテストと環境へのコードの展開に使用されます。自動テストは、これらの環境のいずれかが更新されたときに常に実行されます。
マスターブランチが更新されるたびに、テスト環境はCIによって自動的に更新されます。これは、マスターブランチが更新されたときに自動化されたテストケースも自動的に実行されることを意味します。
テスト環境は、Futuriceの主要なテストサーバーです。ここでテストされたリリースは、QAまたは生産にプッシュされる準備ができていることが予想されます（これは、プロジェクトで使用される用語と統合に応じて）。
テストを更新するときは、手動回帰テストケースを実行する必要はありません。探索的検査に費やされる時間は、より多くの場合、より有益です。ただし、これらのテストをスプリントごとに少なくとも1回実行することをお勧めします。
QA環境は、受け入れテスト、デモ、またはサードパーティのテストまたは監査（セキュリティ、ローカリゼーション、負荷、使いやすさなど）の環境として使用する必要があります。これは、Futuriceの主要なテストサーバーではありません（テストIS）。 QAの更新は、顧客とFuturiceのPMSの間で常に合意されています。
2つのテスト環境（テストとQA）を持つ主な理由は、セキュリティと統合の要件に従うことです。テストにより、Futuriceはアジャイル原則を使用してサービスを開発できます。 QAを使用すると、顧客が現在のQAプロセスを実行できるようになります。
リリースがテスト環境でテストに合格していない限り、QAを更新しないでください。
製品環境は、ライブサイト（生産）の環境です。
Good Practiceは、製品に更新をプッシュする前に、少なくともQAで自動テストを展開および実行することです。ただし、製品では、展開するたびに主要な機能を確認する必要があります。
POは、QAでテストせずに更新をProDにプッシュする権利も持つことをお勧めします（バージョンがテストで渡された場合）。これは、更新が非常に小さくても単純な場合に関連しています。
最終的には、サービスが継続的に開発されているときに、アジャイル開発において、目標はまた、多くの小さなアップデートを作成することです。すなわち、展開プロセスが防弾よりも無駄のない迅速であることがより重要です。バグフリーサービスを使用するよりも、修正を迅速に作成できることが重要であると考えられています（明らかにDODと自動テストで品質も高いはずです）。 Futuriceは、このアプローチからすぐに開始することをお勧めしません。ただし、これは両方の組織が行きたい方向でなければなりません。
各モバイルプラットフォームには、特定のSDK、ツールセット、Futuriceのベストプラクティスがあります。
Android https://github.com/futurice/android-best-practicsの場合
iOS https://github.com/futurice/ios-good-practicsの場合
Windows Phoneの場合https://github.com/futurice/windows-app-development-best-practics
モバイルプラットフォームは、SDK内のエミュレータを提供します。
実装中に、開発者はシミュレーション /エミュレートデバイスを使用して変更を検証できますが、タッチスクリーンと統合メモリからモバイルプロセッサまでのシステム全体が考慮される場所では、実際のデバイステストに勝るものはありません。
モバイルブラウザは、Browserstackなどのクラウドベースのサービスでテストすることもできます。
Futuriceには、基本的な携帯電話から高度なタブレットまで、デバイスライブラリにさまざまなさまざまなデバイスとオペレーティングシステムバージョンがあります。
重いデータトラフィックアプリケーションのテストとパフォーマンス検証のために、FuturiceはELISA Test Labを使用しています（ELISAはフィンランドのモバイルサービスプロバイダーです）。実験室環境内では、高価で効果的なフィールドテストセッションではなく、制御 /孤立した環境で異なる負荷と速度をテストできます。
通常、モバイルアプリはモバイルネットワークを介してバックエンドサービスに接続します。テストを最大限に活用するには、テスターは、異なるエンドテストシナリオの準備と実行のために、モバイルアプリケーションが接続されているバックエンドを完全に制御する必要があります。
モバイルデバイスでは、テストビルドのインストールを行うことができます。テストFlightやHockeyAppなどのビルド配信ツールを介して、開発SDKツールをワイヤレスで制御した開発を使用してケーブルでローカルにケーブルを使用します。リリースフレームワークは通常、クラッシュログの収集とバージョンのデータをサポートします。 Dev、Alpha、およびBetaリリースは、ストアへのアプリケーションをリリースする前にフィードバックを収集するために提供することもできます。 Google Playストアには、特定のアプリがグループメンバーのみが利用できるアルファおよびベータテストグループをセットアップするオプションがあります
最新のモバイルアプリケーションでは、分析とデータ収集は、テストも必要な重要な機能を表しています。 Futuriceは、これを機能テストの重要な部分であると考えています。
事実、モバイルアプリの更新プロセスがWebアプリのプロセスとは異なるため、Analyticsのセットアップは最初の試みから正しく取得する必要があります。更新プロセスはアプリケーションストアの手順を介して行われますが、更新が行われるかどうかは、ユーザーの設定とアクティビティ次第です。したがって、最初のバージョンがいくつかの重要な分析機能を見逃し、一部のユーザーがアプリケーションを更新しない場合、そのデータは見逃されます。ソリューションはアップグレードされている場合があります。ユーザーが利用可能な最新バージョンに更新されるまでアプリが使用できなくなりますが、手遅れになる可能性があります。
