私は最近、これを行う方法を尋ねられました、具体的には:
組織はRails on Railsを開発プラットフォームとして広く使用しています
注:私は長い回答を自分で投稿していますが、追加の良い回答にも賛成票を投じます(そしておそらく私の回答にそれらを組み込みます)。
品質保証は、コード品質からサーバー環境、ユーザーエクスペリエンスに至るまで、製品開発のすべてのレベルで行われます。組織にQAを導入するということは、関連するすべての領域を調べ、QAプロセスとアプローチが製品品質を向上させる方法を確認することを意味します。
OK、これはもっと核心にかかっています。これを4つの部分に分けます。
コード品質は、いくつかのツールとプロセスを使用して実現できます。
標準とガイドライン。たとえば、Rubyのコードでは、5行のメソッド、最大100行のクラス、最大4つのパラメーターなどのSandi Metzガイドラインをコーディングします。これは直接適用されます。機能、バグ、雑用のコードを書いている開発チームのメンバーに、開発者のコードレビューペアの人とコードを受け入れる前に、コードレビューを通じて確認する必要があります。
コードの品質。コードの品質を向上させるために使用できるツールと使用すべきツールがいくつかあります。たとえば、Ruby space'reek 'は、コードの臭いを探すのに最適なツールです。これらのツールは、開発チームメンバーが使用でき、コードをレビューするときにコードチームリーダーが使用する必要があります。チームメンバーと。
新しいコードの単体テスト。新しいコードには、開発の一部として単体テストを含める必要があり、所要時間のすべての時間見積もりに含める必要があります。この領域でコードがカバーされていることを確認するのに役立つツールには、simple_cov、Rails_best_practices、rubocopなどがあります。コード品質と同様に、これらのツールは開発チームメンバーが使用でき、コードチームリーダーは次の場合に使用する必要があります。コードを確認しています。
ユーザーエクスペリエンスと統合テスト。これは、開発チームと展開チームが、新しい変更がエンドユーザーに対して機能し、すべてのブラウザーとデバイスで期待どおりに機能することを確認する場所です。この分野で非常に役立つツールとサービスがいくつかあります。
Rubyの場合、Cucumberは、エンドユーザーのシナリオをまとめるために使用できる高レベルのツールです。キュウリのテストは、ユーザーのドメインを反映した言語を使用して、製品チームと緊密に協議して開発されたものです。
実際のブラウザーでのテストの場合、長期的な目標は、自由に実行できる自動テストスイートを構築することです。これを行うための好ましいツールはSeleniumです。 Seleniumテストは、2つの方法(広範囲)で記述できます。まず、開発者が選択した言語で作成できます。実際、これは小規模な組織ではめったに行われません。また、無料のFirefox IDEプラグインを使用して開発することもできます。これは、低レベルの開発者がブラウザベースのテストを簡単に作成するための優れたツールです。これを使用する開発者は、cssに関するトレーニングが必要です。 xpath、IDE詳細と組織。対処すべきもう1つの項目は、開発チームとのフィードバックに対処する方法です。たとえば、「ログインユーザー名フィールドにデータ属性が必要です」に対処する方法です。時間の経過とともに、Seleniumテストは、変更後に製品が期待どおりに機能することを確認する回帰スイートを形成するために蓄積されます。Seleniumテストは、多くの場合、QAグループの排他的なドメインであり、メインのコード開発者によって開発されません。
デバイス/ブラウザのテストに最適な(無料の)OSエミュレーションツールはVirtual Boxで、ie6、ie7、ie8、ie9のテストに非常に役立ちます。 Virtual Boxは、「古いブラウザ」のビューを確認したい開発者に適しています。私の経験では、製品が正常に機能することを確認するために古いブラウザを調べる必要があるQA /配信チームにとって最も役立ちました。もちろん、携帯電話やiPadなどのデバイスもチェックする必要があります。このために、iPad Peek、iPhoneテスター、携帯電話エミュレーター、MobiReady、Responsivepx、Screenflyなどのツールが多数あります。これは、製品とツールの急速に変化する分野です。複数のデバイスに対してテストを実行するのに役立つSaucelabsなどの外部サービスもあります。
これは、製品と開発チームがインターフェイスする場所です。製品チームは、アプリがどのように使用されているか、どこで使用されているか、どのデバイスで使用されているか、組織の使命に関連するアプリケーション機能の重要性と優先度についてよく理解しています。 QAチームと開発者は、Ruby、Selenium、その他のツールでコードとテストを作成するのにかかる時間をよりよく理解しています。 2組の情報をマージすると、何をテストするかについての回答が得られます。
品質とQAプロセスを検討する場合、主な検討事項は、開発プロセスのどの部分にこれらのプロセスを適用するかです。ほとんどの場合、ソフトウェア開発の品質は、主に内部プロセスとアプローチに関するものです。これらの多くを開発チームの外部にアウトソーシングすることは困難で扱いにくいです。これは、「ビルド対購入」の決定ではなく、「ビルド対ウィングイット」の決定につながります。これはまた、QAの方向性とガイダンスが経営陣から来る必要があることを意味します。
最終結果は、「焼き付けられた」品質になるはずです。
あなたの割り当て1 成功のための具体的または測定可能な目標がないため、良いものではありません2。目標を定義すると、残りのプロセスが実行されます。
従うプロセスは次のとおりです。
デモのために、いくつかのサンプルメトリックを選択します4:
1.この質問は、既存の部門に新しいQAプロセスを採用することに関するものだと思います。
2.品質が「焼き付けられる」とはどういう意味ですか?
3.奇妙なことに、何かを測定し、それに明確な注意を払うことで問題が解決することがわかるかもしれません。
4.プロセスがどのように機能するかを示すために、これらをランダムに選択しました。
これは、目標ごとに1つの変更を加えてから、結果を測定する手順です。
ここには多くのオプションがあります。各変更を擁護し、その効果を証明するために一人を選ぶことを選択するかもしれません。
ダウンタイムを減らすために、以下を実装できます。
実装できる回帰バグを減らすために:
これが最初のステップです。 QAが必要なのは、改善しようとしているメトリックが関連付けられているものです。
プロセスの開始時に購入できるものについて考え始めないでください。変更を加えて、一部のメトリックが改善されたことを確認した後でのみ、その変更の自動化を検討してください。
投稿のフォーマットが私より上手な人は、上記のものを自由に変更してください。