部門には4つのスクラムチームがあります。 スプリント、タイムボクシング、集会、デモ、プロダクトオーナー、顧客など 長年にわたり、コアバリューのリストが策定されてきました：
- チームの精神とチームの雰囲気-プロセスの利便性は、長年にわたって開発されてきたルールや習慣よりも重要です。
- 定期的な自動化は、大量粉砕よりも重要です。
- 迅速な意思決定は、協議、理事会、長期会議よりも重要です。
- 人々への信頼、学習の能力（そして間違いを犯すこと！）は、管理の一元化よりも重要です。
- 全員（トップマネジメントから特定のプロジェクト参加者まで）のオープン性と関与は、時間と同意の外観を瞬間的に保存するよりも重要です。
- 問題の議論における民主主義、しかし決定の実施における独裁。
- 必要最小限の規則、ただしその実装の厳密さ。
- 誰もが同じように考えるとき-誰も考えない。
- 「男が言った-男がした」、誰もが彼らの決定に責任があります。
すべては順調ですが、数年の間、テストの編成方法について考えていました。 物事の現状に至る前に、私たちは多くの実験をしました。
最初は、開発者自身によるテストを試みました。 開発者が単体テストを書くだけでなく、完全にテスターとして働くように-複雑なケースをチェックし、自分の手でテストします。 率直に言って、開発者のテスターはあまり良くありません。 独自のコードをチェックするのは苦痛です。「とにかく動作します、私はそれを書きました。」
開発チームにテスターを含めるようにしました。 これにより、開発者とテスターが集まり、お互いの問題を理解させることができます。 ときどき非常に近いため、テスターはチームの別の開発者になり、前述のように、開発者はすでに悪いテスターです。 しかし、良い点があります-開発者は製品のテスト方法について考え始めています。
プロジェクト外部のテストチームを引き付けようとしました（プロジェクトに関与していない別のテスト部門があります）。 長い間、彼らは外部チームのメンバーに、インフラストラクチャを展開したものと方法を説明し、長い間、彼らから必要なものを説明しました。 私たちは多くの時間を費やしましたが、あまり利益を得ませんでした。
その結果、実際にテストを編成するために必要なもののアイデアが現れました。
常設試験チーム
私たちに必要なのはチームでした。一緒に働き、お互いを知り、お互いを信頼し、同様の知識とスキルを持っている人たちです。 テスト自体に加えて、技術を開発し、それ自体を開発できるチーム。 現在、このような7人の専任チームがあります。
当初、彼らはすべてを行えるジェネラリストのチームを獲得したかったのです。 しかし、ステーションワゴンは原則として広大なエリアを知っていますが、表面的には知っています。 そして、私はこのエリアに飛び込みたいと思いました。 その結果、このアイデアは放棄され、機能テストと自動テストの2つの領域が特定されました。
機能テストはすべてのテスターにとって基本的なものです。 これには、要件の割り当て、テストの設計、およびそれらの即時実装が含まれます。 機能テストは、基本機能のテストと適用されたロジックのテストに分けられます。
自動テストには、手動テストの自動化、つまり特殊なタイプのテストの編成が含まれます。
いずれかの領域に割り当てられたテスターは、そこに深く潜ることができ、これによりテストの品質が向上します。
自動化に最大の焦点
自動展開、自動テスト実行、実際のユーザーアクションのシミュレーション、結果の自動修正、失敗したテストの理由、環境。
現在、システムの機能の大部分をカバーする約800のGUIテストがあります。 これらは、テスターの参加なしに起動されます。 環境が自動的に上昇し、テストに必要なデータが自動的に作成され、テストが自動的に実行されます。
自動テスト実行テーブル
（おっと、誰かが最後の実行に失敗したようです）
テストはAPIとUIを介して機能します。 APIは、ある種のテストデータを準備するために使用され、UIを使用したテストにより、実際のユーザーシナリオを確認できます。
テスト自体に加えて、システムの非機能インジケータ（操作の時間、サーバーとクライアント間のリクエスト数、トラフィック）を自動的に削除します。 測定された特性は、プロジェクトの全員がダイナミクスのグラフの形で利用できます。
トラフィックとリードタイムのグラフ
テストへの信頼
いつでも、製品の状態をテストチームに問い合わせることができます。 自動テスト、エクスプレステストの実行に基づくテストチームは、製品を実稼働に投入できるかどうか、できなければその理由を迅速に答えることができます。
この意見を信頼しています。 テストチームが承認した場合、本番環境で重大なエラーは発生しません。 私たちは、チームが理由でバージョンをリリースすることを禁止していることを知っていますが、それには理由があります。
専門試験の実施
まず、負荷テストについて話します。 他のすべてのタイプは何らかの形でカバーされます。 このようなテスト用のツールは非常に高価です。 さまざまな種類の特別なテストを実施するためのツールを作成しました。
ユーティリティの主なタスクは、システム内の多くのユーザーの作業をシミュレートすることです。 最小限の時間と労力でユーザー向けのさまざまなシナリオを作成できます。
ユーザーアクションをシミュレートするユーティリティ
完全性、機能的な利便性のテスト
テスターは、アイデア自体、製品のアイデアが正しいこと、それ以外の場合ではなく、それだけを行う必要があることを確認できません。 この問題はコリドーテストで終了しますが、これは別の記事の別のトピックです...
ただし、テスターは、この機能が使いやすいことを十分に検証できます。 正式には機能要件が満たされていることがよくありますが、ユーザーは製品の使用によって単に苦しめられます。
この場合の利便性は、ユーザーインターフェイスだけではありません。 これは、外部APIであると同時に、システムが提供するタスクを迅速かつ効率的に実装する機能です。
可能な限り開発者に近い
テスターと開発者の収束により、テスト結果をより早く取得できます。 バグが1週間で開発者に届いた場合、開発者は再びコードに飛び込み、もう一度掘り下げる必要があります。1日であれば、昨日書いた内容を覚えやすくなります。
開発者は、スプリント中に直接テストできるパーツの機能を提供し、現在準備ができているものとまだ作業中のものを伝えようとしています。 これにより、テストをすばやく開始し、まだ粗雑な機能に関する問題を見つけることができます。
開発とテストの期間のグラフ。
2番目のオプションは、用語を1/4減らします
専任のテストチームのアイデアは、作業の基本原則によく適合します。 チームは3年間プロジェクトに取り組んでおり、その有効性を示しています。
オプションが最適であることがわかりました。 しかし、スクラムプロジェクトでテストを編成した方法を教えていただけますか。専任の部門またはテストグループがありますか。そうでない場合、なぜ拒否しましたか？