典型的な企業のタスクがあります-いくつかの部門、製品、またはプロジェクトのテストプラクティスを作成および開発することです。 ユニバーサルソリューションの1つとして、部門の組織を検討します。
私は効率性と合理性の問題を最前線に置いているので、テストの実践がこのセクションではなく議論されるべきかどうかの問題です。 テストを必要とせず、開発者が自分でテストを行いたい人は、これ以上読むことはできません:)
1.テスターの職業は正当化を必要とせず、人生はその必要性を証明した:)
2.独立したテストにより、複数の部門、製品、またはプロジェクトの作業を実行できます。
3.複雑なタイプのテストでは、いくつかの部門、製品、またはプロジェクトで使用(および償却)されるツールを購入するための組織フォームが必要です。
4.企業の受け入れ段階でのテストは、幅広い製品または技術に対して実施されます。
5.長いライフサイクルのテストには、参加者とグループ(個人だけでなく)の能力の互換性が必要です。たとえば、顧客または実装または保守の組織によるサポート対象システムのテストです。
Disclimer :普遍的なレシピはありません。著者は大規模なIT企業でのテストプラクティスの作成と開発の経験に基づいており、すべての場合に当てはまるとは限りません:)
何かを作成するのは簡単です。 しかし、効率を達成するためには、 長くて高価な方法をとる必要があります!
どこから始めますか? 多くのニュアンスがありますが、基本的な原則を強調し、それらを詳細にしようと思います。
何のために?
部門は次の目的で作成されます。
1.幅広いタスクのための(テスト用の)能力の専門センターの形成と開発。
2.プロジェクトまたは製品ごとのテスターグループのより柔軟な管理。
3.テストプロセスのアクションに対する法的責任の割り当て。
4.開発部門およびその他の部門からの財政的独立。
必要かつ十分な:
1.内部または外部の開発をテストするための部門(専用グループ)を編成および維持するためのリーダーシップの要望と能力。 経営者の欲求は金銭的な機会に基づくべきです-これは数年間の投資です。 従業員の給料は最も難しくありません。 最良のシナリオでは、自動テストツールと、場合によっては補助ツール(タスク/バグ追跡システム、要件管理システム)を購入または統合します。 テストベンチなどを整理するには、バージョン管理されたストレージ、機器、または仮想化システムが必要です。
2.テストマネージャーの存在-部門の長。 彼は、部門の構築の目標と目的を理解し、経営陣とすべての戦略的変更を調整し、日々テストプロセスを改善する必要があります。
3.従業員のトレーニング。
4.従業員の動機。
効率を改善するオプションの (進化する)要件:
1.企業文化の改善。
1.1。 グループ/部門の相互作用を考慮に入れた開発手法(アジャイル/スクラム、RUP、MSF)の実装。
1.2。 従業員向けの指示書の作成(形式の程度が小さいか大きい)。
1.3。 ユニット/プロジェクトチームの相互作用に関する規制の策定。
1.4。 委員会などを通じて方法を改善するためのプラクティスを作成する。 (SEPG、IT委員会など)
1.5。 関連するコースに対する従業員のリクエストを通じた、人事およびリーダーシップの継続的な機能としての従業員トレーニング。
1.6。 チームビルディング。
専用のテストを実施する必要性は次のとおりです。
1.アウトソーシング企業がフルサイクルでカスタム開発のテストを提供します。
2.受け入れテストのためのITインテグレーター(社内、サービス会社など)。
3.開発会社(少なくとも負荷テストタイプ)。
継続が計画されています...
コメントを歓迎します!