2

私たちはスクラムで作業しており、正しい方向に進んでいると思いますが、1 つ気になる点があります。テスターはまだ開発サイクルに参加していないということです。現在、開発チームにテスターをどのように巻き込むかを考えています。現在は分離されており、テスターは「独自の」スプリントを持っています。

現在、CI環境があります。開発者はユーザー ストーリーを完了するたびにコードをチェックインし、チェックインのたびにビルド サーバーがコードをビルドします。

私が望むのは、ユーザー ストーリーが実装されているのと同じスプリントでテスターがユーザー ストーリーをテストすることです。しかし、私はこれをどのように設定するかについて苦労しています。

私の主な質問は、テスターはどこでユーザー ストーリーをテストできるかということです。チェックインのたびに新しいビルドが作成され、多くのチェックインがあるため、ビルド サーバーでテストすることはできません。したがって、それはオプションではありません。では、テスターが自分で展開できる別のサーバーを作成する必要がありますか? または..

私の質問は、皆さんはこれをどのように設定しましたか? テスターを開発プロセスにどのように統合しましたか?

4

5 に答える 5

2

私の現在のプロジェクトでは、4 つの小さなチームがあり、それぞれに 1 人のテスターが割り当てられています。テスターは、デイリー スタンドアップ、スプリント計画ミーティングなどに参加します。テスターは独自のデイリー スタンドアップも持っているため、調整などを行うことができます。

スプリント計画会議 2 では、受け入れ基準 / 例 / テスト ケース (呼び方は自由)を一緒に(テスター、開発者、PO) 作成します。その意図は、ユーザー ストーリーの共通理解を作成し、正しい方向性を得て、それをより小さな機能 (シナリオ/テスト ケース)、たとえば特定のハッピー パスなどに分割することです。これにより、テスターがテストできるよりも小さな動作機能を提供することができます。その間に、ユーザー ストーリーの次の部分を実装できます。さらに、自動化された受け入れテストが必要なストーリーと、どのレベル (ユニット、統合、GUI テスト) が最も適切かを判断します。

すでに OakNinja が述べたように :) テスター用に少なくとも 1 つの追加環境が必要です。私たちの場合、これらの環境は品質ゲートではなく、開発段階です。そのため、開発者は何らかの機能を終了するたびに、必要に応じて再デプロイできることをテスターに​​伝えます。

ユーザー ストーリーが完成すると、ステージング サーバーに展開され、そこでユーザー ストーリーの承認が行われます。

展開プロセス:

開発 + テスト => ステージング (受け入れに使用) => デモ (2 週ごとにユーザー ストーリーのデモに使用) => SIT および End2End テスト環境 (2 週ごとに展開) => 本番 (ほぼ 6 か月間すべて展開)

于 2012-12-18T09:45:19.453 に答える
2

ステージング サーバーが必要で、時々ビルドをデプロイします。それが私たちのやり方です: CI->Dev->Staging->Live

編集: 私はいつもウィキリンクを投稿する嫌いな人のように感じますが、マルチステージ CI に関するこの記事は良いです: http://en.m.wikipedia.org/wiki/Multi-stage_continuous_integration

于 2012-12-18T08:16:53.050 に答える
2

見積もり、計画など、スプリント全体に関与する QA リソースがあります。開発者が最初にコーディングを開始すると、チームの QA メンバーがテスト ケースの作成を開始します。コードがチェックインされると、QA がスプリント中にテストを実行できるように、スケジュールに基づいて (または必要に応じて) 別の環境にデプロイされます。QA は、ストーリーがほぼ完成した後の回帰にも関与します。

私たちのセットアップでは、プロジェクトに応じて、TFS または TeamCity のビルド構成を使用して自動展開を使用します。私たちの環境は次のように分割されています。

  1. ローカル開発サーバー。開発者は、独自のソース コード、IIS、およびデータベース (必要な場合) を使用して、作業中にそれらを相互に分離し、QA を行います。
  2. サーバーを構築します。CI、自動展開に使用されます。ここには Web サイトや DB はありません。
  3. Daily Build 環境(別名「Dev」または「Dev Test」)。スプリント中に行われている作業を QA がレビューし、フィードバックを提供できる、完全に機能するサイト。
  4. QA ラボ(別名「回帰」または「UAT」)。回帰テスト、デモ、および UAT 用の独立したラボ。

これらを最新の状態に保つために、ビルド構成を使用します。

  1. ローカル開発者からのチェックインを処理するためのチェックイン上の CI ビルド。
  2. 毎日スケジュールされたビルドと、Daily Build 環境への自動デプロイ。開発者または QA は、必要に応じてプッシュするために、これを手動でトリガーすることもできます。
  3. QA 環境にデプロイするための手動トリガー。
于 2012-12-18T15:39:03.297 に答える
1

上記の説明には 1 つのポイントが欠けています。テスターを SCRUM プロセスに追加する最良の方法は、テスターがスクラム チームの一員であることを確認し、スプリントでチームの他のメンバー (開発者、PO など) と協力することです。 . ほとんどの場合、これは実際には行われず、最終的には (最良の場合) ミニ ウォーターフォール プロセスだけになります。

では、説明しましょう。上記の広範なハードウェアと環境の説明に追加することはほとんどありません。ステージングされたサーバーで作業することも、テスターが必要なときに独自の環境を作成できるようにするスクリプトを配置することを内部機能にすることもできます ( CI フレームワークの可能性を使用している場合、そこに必要なすべてのパーツが既に含まれています)。

私を悩ませているのは、テスターが「独自の」スプリントを持っていると言ったことです。

テスターを SCRUM プロセスに参加させるときに私が目にした主な問題は、彼らが実際にはプロセス自体の一部ではないということです。開発者の近くで作業するほど技術的ではないと感じる場合もあれば、開発者がテスターに​​自分のしていることを説明することに煩わされたくない場合もあります (完了するまで - 完了していません!)。これは単に、これがチームに期待されていることを経営陣が説明していない場合です。

簡単に言えば、各ユーザー ストーリーには技術所有者とテスト所有者が必要です。それらは常に連携して動作し、開発者環境での短い「非公式のクリーンアップ テスト」であっても、できるだけ早くテストを開始する必要があります。結局のところ、その過程で不要な官僚主義をすべて排除することで、お役所仕事を削減することが目的です。

また、テスターは、機能を試すことができることを QA に伝える前に、行うべきテストの種類を開発者に説明する必要があります。手動テストは、テスターと同じくらい開発者の責任です。

要するに、開発の一環としてテスターを配置したい場合は、適切なインフラストラクチャを配置することよりもさらに重要であり、適切な考え方を配置する必要があります。これは、ゲームのルールや多くのルールを変更することを意味します。チームの各人が自分のタスクと責任をどのように認識しているかを示します。

この件については、私のブログにいくつか記事を書きました。

Tシャツを変えるほど簡単ではなく、アジャイルに切り替える

アジャイルテストの代わりにアジャイル思考

于 2012-12-19T06:50:48.180 に答える
0

ClemensReijnenによる「スクラムスプリントでソフトウェアテストを実行するための5つのヒント」の記事を読むことをお勧めします。彼は、スクラムスプリント中にソフトウェアテストチームとプラクティスを統合する方法を説明します。

于 2013-01-03T10:13:43.883 に答える