大規模なLMSをテストする秘訣

インタビュー中にあなたが恋に落ち、新しい市場を征服するときに誇りに思うプロジェクトを見つけることはめったにありません。同僚のプロ意識が最高のとき、それはさらに楽しいです、そしてあなたのチームではあなたはあなたの家族の懐の中にいるように感じます。そのようなプロジェクトを見つけただけでなく、しばらく前にそのプロジェクトのテストプロセスに影響を与え始めたのは幸運でした。最適なプロセスの理解に何が含まれているのかをお話しします。毎月のリリースに至るまでの経緯と、それらがどのように機能するか。検疫の条件にどのように適応したか。



私たちのプロジェクトは、世界のさまざまな国で700万人以上が使用している遠隔学習システム（LMS、学習管理システム）です。システムには、1000以上のWebページと約10,000のテストケースが含まれています。







現在、このプロジェクトでは、ノルウェーの顧客側とロシアのアルカディア側から、約15の開発チームを採用しています。私は8年前にQAとしてプロジェクトに参加しました。過去2年間、私はQAリードとして働いており、テストプロセスの最適化に参加しています。

最適なプロセスの概念に含まれるもの

私たちの主なタスクは、新しい機能の作成やシステムサポートなど、エンドユーザーのニーズを満たすことです。システムの速度と高負荷条件下での作業の安定性に特に注意が払われています。



開発プロセスでは、主に、時間どおりに合意されたレベルの品質で作業を行うなど、ビジネス目標の持続可能な達成を可能にする必要があります。ただし、プロセスに関与するすべての人が満足できるように、プロセスは開発チームにとっても快適である必要があります。私たちのチームでは、私たちにとって最適なプロセスを確立しました。これを実現するための手段は次のとおりです。

一般的な開発プロセス：

a）チームのニーズを満たす開発アプローチ



私たちは3週間続くスクラムとスプリントを使用して作業します。スプリントの前に、その目標の提示が行われ、このスプリントの一連の要件が形成されます。次は、すべてのタスクを評価し、スプリントに含まれる一連のタスクを決定する計画です。スプリントの最後に、スプリントレビューが行われ、完了したすべてのタスクが示され、達成された目標が発表されます。このアプローチは私たちにとって最適です。スプリントでは、十分な量の新機能を作成すると同時に、エンドユーザーからの特定の数のバグを修正してテストします。スプリント時間の10％がそのようなバグに割り当てられます。







ラインナップ：チームリーダー、開発者、テスター。私たちのチームの開発者とテスターの比率は3：1です。この比率により、スプリントの目標を均等に達成できます。プロセスの参加者の1人がアイドル状態になる期間はありません。開発者が変更を加えている間、テスターはこの変更に関連するテストケースを作成または更新します。開発が完了すると、テスターは変更を確認し、開発者はスプリントの次のタスクに進むか、テストを支援します（これは大規模な変更をテストするときに必要です）。



プロダクトオーナーは、各スプリントの開始時に目標と要件を設定し、終了時にそれらを受け入れます。また、各チームには、新たな問題の解決を支援するスクラムマスターがいます。







チームがスプリントのタスクに直接関係しないさまざまなアクティビティを実行する機会を持ち、さまざまなリスクを考慮に入れるために、スプリントのタスクを完了するために計算される時間は、チームの総作業時間の80％です。つまり、通常のスプリント中の1日2時間は、コミュニケーション、さまざまな会議、セミナー、およびスプリントで見つかったバグの修正のために予約されています。



b）明確な要件と適切な計画



これまで不明だった詳細や、スプリントプロセスですでに追加された面倒な追加変更によって計画が引きずり出されたり、スプリントが失敗したりしないようにするために、十分に明確で正確な要件を持つ変更のみをスプリントに取り入れようとしています。変更に関係するプロジェクト領域がチームにわからない場合、または計画中にプロダクトオーナーが回答できない質問が多数ある場合、チームはこの領域を調査するためのタスクまたは調査タスクをスプリントできます。これにより、明確な要件が得られます。ある種のプロトタイプ。



c）回顧



バグを修正することも重要です。これは、スプリントとリリースの両方に適用されます。何かのための時間がない場合や、期限に間に合わせるために残業しなければならない場合があります。たとえば、リリースを事前にテストする必要がある場合（これは、会社が将来回避したい追加コストです）。そのため、スプリントやリリースで何が良かったのか、何が悪かったのかを振り返り、今後そのミスを回避するための対策を講じています。



d）管理サポート



チームレベルでは解決できない質問や状況が発生することがあります。プロセスを変更するか、会社の経営陣を決定に関与させる必要があります。彼らがあなたを助けたいと思っており、そのような状況であなたをサポートする準備ができていることを確認することは非常に重要です。私たちの会社では、これですべてがうまくいきます-これはアルカディアと顧客側の管理の両方に当てはまります。すべての問題が議論され、すべての関係者を満足させる解決策が常に見つかります。



e）そして、私の意見では、基本は良好なコミュニケーションです。そして、私たちが会社に持っているのは、快適な仕事の主な利点の1つです。慈悲、妥協したいという願望です。



これは、チームの各メンバー、プロダクトオーナー、スクラムマスター、会社の経営陣、およびプロセスの他の多くの参加者など、すべての人に当てはまります。誰もが質問や議論を受け入れることができ、開発者は要件についてテスターと相談し、（開発の観点とテストの観点の両方から）これまたはその変更を行うための最善の方法を一緒に決定します。次に、プロダクトオーナーは常にチームと連絡を取り、すべての問題を迅速に解決し、スプリントの目標を達成するために常に途中で達成しようとします。スクラムマスターはいつでもお手伝いします。追加のリソース（テスター/開発者、スプリントまたはリリースに必要な場合）を見つけるか、スプリントを時間内に整理するための最良の方法を提案します。

テストプロセス：

a）テストケースの作成に関連するQA標準（ガイドライン）。



私たちのプロジェクトでは、テストケースがシステムの機能に関する主要な詳細なドキュメントであるため、それらに多くの注意が払われています。チームによって行われた変更ごとに、新しいテストケースが作成されるか、既存のテストケースが更新されます。



以前は、システムがまだそれほど巨大ではなかったとき、テストケースはさまざまな特定の手順で非常に詳細に記述されていましたが、現在、このアプローチは受け入れられなくなりました。このようなテストケースの更新には多くの時間がかかります。したがって、私たち（QAリード）は標準を開発しました。その主な要件は、テストケースの詳細な手順ではなく、期待される結果を含むテストスクリプトを作成することです。



b）スプリントでのテストに関連するQA標準。



スプリントテスト標準は、各チームが高品質の変更を行うことを保証するために開発されました。



これらの標準は、以下を含む最大テストカバレッジに基づいています。

• チームによって行われた変更を直接テストします（機能、および必要に応じてUI）。
• チェックリストを使用したこの変更後のシステムのテスト：これらは必須のチェックです。これには、障害者のアクセシビリティのテスト、翻訳のチェック、既存のデータのチェック、特殊文字の使用のテスト、セキュリティチェック、モバイルアプリケーションの変更のテストおよびその他のチェックが含まれます。 ..。

c）リリーステストに関連するQA標準。



リリースプロセスとそこで使用される標準については、以下で詳しく説明します。



d）自動回帰テストの使用。



回帰テスト用の自動テストの作成により、チームの寿命が大幅に短縮されました-コマンドの変更後に一部の領域をチェックする必要がある場合は、システムの目的の領域に対して回帰自動テストを実行できます（この領域が自動テストでカバーされている場合）。また、チームの変更によってシステムの一部が壊れた場合、回帰自動テストがこれを検出します。



e）テスターの相互支援、開発者の支援。



テスターはそれほど多くありません（平均して、3人の開発者に対して1人のテスター）。さらに、リリースをテストするためのスプリントタスクに気を取られることがあり、すべてに十分な時間がない場合があります。



この場合、他のチームのテスターから、現時点で作業負荷の少ない人が常に助けてくれます。 QAリードまたはスクラムマスターは、そのようなテスターを見つけるのに役立ちます。さらに、開発者は、テストケースがすでに作成されている場合、スプリントの変更のテストを支援できます。



f）テスター間のコミュニケーション。



コミュニケーションには、Microsoft Teamsのチャットが使用され、誰もが質問をしてすぐに回答を得ることができ、残りのテスターは最新の情報を見つけることができます。また、毎月QAミーティングを開催し、テスターがチームの現在のタスクを互いに共有し、問題について話し合うことができます。テストへのアプローチや、テスターに​​馴染みのない領域に関連するテストケースの場所。リリースに関する質問（将来のリリースチームの構成、テストタイムラインの変更）;リリースなどで重大なバグを見逃した後に追加された必須のチェックなど）。



上記のアプローチにより、静かな動作モードで高品質のテストを保証できます。

:

以前は四半期ごとにリリースされていました。このような時間枠で、リリースごとにチームによって多くの変更が加えられました。この量の変更には確かにリリース前のリグレッションが必要だったため、リグレッションには別の時間枠があり、すべてのチームがそれに接続されていました。これには通常約2週間かかり、テスターとチーム開発者の両方が回帰に参加しました。



しばらくすると、リリーステストプロセスの回帰に自動テストが使用されるようになりました。すべての回帰テストが自動テストでカバーされているわけではなく、一部は手動でテストされました。全体として、これにより回帰テストの時間が短縮されましたが、システムのサイズが原因で、完全な回帰にはまだ時間がかかりました。



開発サイクル全体は次のようになりました。







このリリースへのアプローチは最適ではなく、過度に労力を要し、エンドユーザーの要求を迅速かつ柔軟に満たすことができないことが明らかになりました。リリースプロセスへのアプローチには変更が必要であり、月に1回、より頻繁にリリースすることが決定されました。月次リリース



に移行すると、部分的に自動化された回帰テストを使用しても、リリーステストフェーズ中に回帰を実行する時間がないことが明らかになりました。現在、リリースの準備期間はわずか2週間です。したがって、現在、回帰はスプリントで必要な場合にのみ実行されます（開発者がシステムの特定の部分の回帰が必要であると報告した場合）。



ただし、リリースのテスト段階では、新機能だけでなくシステムの全体的な状態も確認する必要があるため、回帰ではなく安定化を使用するようになりました。



安定化には次



のものが含まれます。a ）各チームによるこのリリースに含まれる新機能のテスト。

b）クリティカルエリアテストは、システムのメインエリアの基本機能のテストです（完全な回帰サイクルよりも明らかに時間がかかりません）。

c）このリリースのチーム変更で見つかったバグをテストします。



開発サイクル全体は次のよう







になります。リリースの準備に他に何が必要かを考えてみましょう。



安定化が完了し、リリースパッケージの品質が良好になったら、本番環境にロールアウトする前に、本番環境前の環境で構成をテストします。したがって、オペレーションは環境の更新を練習し、テスターは実際のリリースの前に現在のリリースパッケージで構成を確認します。



リリースの2週間の準備が長すぎて、スプリントでテストする時間がほとんど残っていないと思われるかもしれません。ただし、通常、テスターがリリースの準備をするのに4〜6日かかります。それは以下に依存します：

• 彼のチームがリリースしようとしている機能の複雑さと範囲、
• 現在のリリースのリリースチームへのテスターの参加。

プロジェクトのすべてのテスター（リリースチームを含む）は、安定化テストに参加します。構成とリリース自体のテストは、リリースチームによってのみ行われます。



一般的なリリーステストのスケジュールは次のように







なります。重要な領域と構成には一定のテストが含まれているため、これらのテストケースを部分的に自動化しました。これにより、リリースに向けたテスト時間が大幅に短縮されたため、将来的には自動テストの使用を拡大する予定です。



テストの編成の観点から、リリースごとにQAコーディネーター（QAリードの誰か）が選択されます。 QAコーディネーターにはより多くの責任があるため、リリースのリードタイムは通常、通常のテスターよりもQAコーディネーターに対して計画されます。これらが含まれます：

• リリースチームを定義し、リリース時にそのすべてのメンバーの可用性を確認します。
• リリースのテスト計画の準備。
• 安定化および構成テストの段階で自動テストを開始します。
• リリーステスト中のテスターの作業の調整。
• テスターがリリースに関連するあらゆる種類の問題を解決するのを支援します。
• テストの実装を制御し、必要に応じて、過負荷のチームのテストを支援するために負荷を再配分します（これらは、リリーステストをすでに完了している他のチームのテスター、チーム開発者、またはQAコーディネーター自身のいずれかです）。

そしてもちろん、問題なくリリースが完了することはありません。私たちはそれらを解決し、将来それらを回避する方法について計画を立てます。最近出会ったものをいくつか紹介します。

• : , - , , - .
  
  : .
• : pre-production . — .
  
  : .
• : , .
  
  
  
  :
  
  
  
  a) - ( , ),
  
  b) ,
  
  c) ,
  
  d) , . , , .
  
  解決策：このような場合、リリースはスプリントタスクよりも優先度の高いタスクであるため、2週間すべてのリリースへの参加や残業が必要な場合でも、リリースに必要なすべてをテストする時間があります。

しかし、どんな問題が発生しても、リリースチームの力によって、または特定の分野の有能な人々を巻き込むことによって、いつでも問題を解決できます。主なことは、これは常によく調整されたチーム作業であり、良い結果につながるということです。

検疫での作業：テスターの作業を確実にする方法

私たちのプロジェクトでは、オフィスでの作業が前提条件です。これは、プロセスの参加者を勤務時間中に見つけることができるようにするためです。突然チャットで応答しなくなった場合、彼と一緒に働く人々は、彼が同僚の何人かによって必要とされていることを彼に知らせることができます。一部のチームはノルウェーにあり、一部はサンクトペテルブルクにあるため、これは適切です。



パンデミックの間、ノルウェーとロシアの両方が人口の大部分を自己隔離に送ったとき、私たちは遠隔作業に切り替えなければなりませんでした。



私たちはいつものように作業を続けました。チームはまだスプリントの生産性が高く、スプリントを終了し、リリースは時間どおりにリリースされました。



コミュニケーションは依然として良好なレベルでした。チームアプリケーションはすべてのニーズをカバーしました。チャットで活発な会話があり、会議は問題なく開催されました。緊急に話し合う必要のある質問がある場合、彼らはプロジェクト参加者を呼びました。



テストの構成の観点からは、問題はありませんでした。勤務時間中、すべてのテスターがチャットに応答し、リリースのテストに迅速に参加しました。誰かを見つける必要があるが、チャットで彼が応答しない場合に備えて、携帯電話番号のリストを用意しましたが、それを使用する必要はありませんでした。



自宅の遠隔地の職場で私たちが直面した唯一の問題は、VPNの特性により、電話/タブレットからチーム環境でシステムをテストすることは不可能でした。しかし、この問題は回避されました。解決策を見つけたプロジェクトマネージャーとITサービスのおかげです。ホームネットワーク経由で接続するときにプロキシを使用し始め、今では自宅からモバイルデバイスでテストできるようになりました。



現在、私たちは部分的にオフィスで仕事に戻っていますが、会社の一部は自宅で仕事を続けています。そして、街のさまざまな場所にいても、子供やペットが注意を要求し、インターネットが遅くなり、定期的に消え、ライトが消え、気を散らすものがたくさんあるような非稼働状態で、このような困難な時期に働き続ける単一の緊密な会社であり続けますまったくわからないこと、どうやってまた仕事ができたの？



しかし、私たちは一緒にこれらすべてを生き残り、最終的に本格的なオフィスライフに戻り、いつもよりもさらに広くお互いに笑顔になります。

結論

上記を要約すると、いくつかの点に注意したいと思います。

1. , , . — .
2. , , .
3. , , , — . , .