Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

デリバリーライフサイクルでのテストの自動化

開発とリリースのライフサイクルの一部として自動テストを導入すると、アプリケーションを開発してデリバリーする方法が変わる場合があります。これらの変化の中には、垂直型のチームを組織するDevOpsの文化によってもたらされるものがあります。垂直型のチームは、ビジネスアイデアの観点から、アプリケーションのデプロイや本番での監視まで参加します。リリースサイクルのタスクが自動化されると、リードタイムが短縮されます。

チームの編成

チームがアプリケーションライフサイクル全体を担うため、プロダクトオーナー(PO)、ビジネスアナリスト(BA)、開発(DEV)、品質保証(QA)、運用といった個別化されたロールはなくなります。それに代わり、1つのプロダクトチームがドメインに属するすべてのアプリケーションに関連するあらゆる側面に対して責任を負います。このチームには、このような各ロールにつき少なくとも1人のメンバーがいます。そして、すべてのメンバーが各側面で連携して、品質の高いアプリケーションの開発、可能な限り迅速な本番へのデリバリー、アプリケーションの保守を行います。

自動テストでは、QAが大きな影響をもたらします。QAではテスト戦略を定義し、リスクとテストシナリオを特定し、テストで取り組むべき対象を示します。さらに、テストをしやすくするためにアプリケーションアーキテクチャの設計方法をQAで示すこともできます。

QAロールのみが自動テストに関するすべての責任を負ったり、DEVロールのみが実装に関わったり、POやBAのみが要件に関わったりするわけではありません。アジャイル手法と同様、チームがアプリケーション全体のあらゆる側面に対して責任を負います。各ロールには、独自の考え方があると考えてください。それぞれの考え方によって独自の視点や長所がもたらされ、開発中のアプリケーションの向上につながります。

つまり、ユーザーストーリーの定義/ドリルダウンを開始したらすぐにテストやQAプロセスについて話し合う必要があります。チームメンバー間の効果的なコミュニケーションがビジネス目標との連携の確保につながります。

プロセスに関係する3つのロール

先ほど提案したようなチームが組織されていない場合、通常は次のようなワークフローが発生します。POまたはBAが最初にユーザーストーリーを作成して開発者に引き渡すときに、受け入れ基準を追加します。

開発者はそれを受け取った時点で、厳密に示されていない最終的な振る舞いに関する多くの疑問を抱きます。疑問を解消し、場合によってはそれらを新しい受け入れ基準シナリオに変換するために、開発者はユーザーストーリーを送り返します。

その後、誰も検討していない潜在的なシナリオをテスターが見つける場合もあります。そして、最終的に全員が受け入れ基準に満足するまでユーザーストーリーに関するやりとりが行われ、最後にユーザーストーリーがスプリントに追加されて開始します。

そのほかによくあるアンチパターンとして、このプロセスがスプリントの前ではなくスプリントの間やスプリントの後に発生する場合があります。その場合、特定のシナリオが開発中やテスト中に初めて特定され、多くの再作業が必要になります。

提案したようなチームが組織されている場合、3つのロールすべて(「スリーアミーゴス」と呼ばれるPO、DEV、QA)の間で行われる最初期のコラボレーションセッションで受け入れ基準が定義されます。これによってプロセスが効率化され、開発段階やテスト段階でのつまづきや期待される結果の行き違いを避けることができます。これら3つのロールによる話し合いは、ビヘイビア駆動開発(BDD)の中核となります。その目的は、ただ問題なく動作するだけではなくビジネスニーズに対応できるソフトウェアを開発することです。

これらの話し合いは、バックログリファインメントセッション中に行う必要があります。このセッションでは、チームがユーザーストーリーの開発の詳細について前もって話し合い、スプリントを開始できるようにします。このように、受け入れ基準、テスタビリティを考慮した計画、テスト戦略を含むテスト定義は、ユーザーストーリーの詳細に追加されたテーマにすぎません。

テスト定義をミーティングの最後まで放置せず、ユーザーストーリーの詳細として行うことが重要です。テストは前面に押し出さないと、二次的な考慮事項として扱われることになります。

優れた受け入れ基準

優れた受け入れ基準を記述することは、効果的なソフトウェアデリバリーのための鍵の1つです。受け入れ基準は、特定のユーザーストーリーに対するルールを定めているため、開発チームによって作成されたコードを評価するときに必要です。

受け入れ基準には様々な記述方法がありますが、BDD手法で採用されているGiven-When-Then形式を使用することを推奨します。これは、例示による仕様という方法に基づいています。

この方法は、誰にとっても非常に自然なものです。人間の脳は、例から概念を導き出すことに長けています。そして例が多いほど、手元の問題とそのスコープをよく理解することができます。

Given-When-Then形式は、以下に示す3つの部分から成り立ちます。

  • Given — 入力/前提条件。このシナリオで指定する振る舞いの開始前の状況について記述します。これは、テストの前提条件とみなすことができます。
  • When — 機能。指定する振る舞いを実行します。
  • Then — アサーション。指定した振る舞いに伴って想定される変化について記述します。

Andを使用してつなぐことで複数の前提条件、アクション、アサーションを組み合わせることができます。

この形式に基づくシナリオを以下に示します。

シナリオ: ユーザーが取引終了前に売却を依頼します
Given MSFT株100株を保有しています
And APPL株150株を保有しています
And 時刻は取引終了前です
When MSFT株20株の売却を依頼します
Then MSFT株80株を保有しているはずです
And APPL株150株保有しているはずです
And MSFT株20株の売却指図が実行されているはずです

この例には、テクノロジー、システム、画面インタラクション、APIに関する技術的な情報はまったく含まれていません。それは、この情報が機能が提供された時にビジネスユーザーが期待する振る舞いを示すものであり、実際にそこで何が起きるかを示すものではないからです。

技術的なソリューションを切り離すことでビジネスユーザーとの話し合いが非常にうまく行く、ということを忘れないでください。このシナリオは振る舞いを重視しているため、将来リファクタリングを行う際にも有効です。

また、この例にはIFやORがないことにも注目してください。テストシナリオは明確かつ明示的に記述し、定義に条件付きロジックが含まれないようにする必要があります。どうしてもIFやORを追加する必要があると思う場合は、新しいシナリオを用意してください。別のテストシナリオを記述して検証するようにします。

過剰

受け入れ基準を記述した後、ユーザーストーリーのシナリオが多くなりすぎることがあります。その場合は、ユーザーストーリーを複数に分割できます。分割する際は、各ユーザーストーリーがビジネス価値を提供可能な最小単位になるようにします。

Readyの定義/Doneの定義

チームのワークロードに自動テストが導入されたら、Readyの定義(DoR)Doneの定義(DoD)を確認し、これらに適合していることを確認します。適切な受け入れ基準が定義され、特定された対応するテストに全員が同意している場合にのみ、ユーザーストーリーを準備が整ったものとして受け入れる必要があります。

次にチーム全体のタスクとして、テストの実装をDoDに反映します。そのために別の技術的なストーリーを作成し、複数のユーザーストーリーに依存するE2Eシナリオ用のテストを実装します。このとき、ユーザーストーリーですでに実装されているものと異なるビジネスロジックを使用しないでください。この方法に従うと、依存関係の問題のためにユーザーストーリーのDoDが損なわれることがありません。

DoRでは、新しいテストシナリオで必要な品質テストデータの明確な定義を追加することを検討します。また、確認が必要な既存テストを特定する必要がある場合があります。DoR/DoDに関して考慮する必要がある項目を以下に示します。

Readyの定義

  • 「<ユーザーロール>として、<メリット>を実現するために<アクティビティ>を行うことを望みます」という形式で記述されている。
  • INVESTの原則(Independent: 独立している、Negotiable: 交渉可能である、Valuable: ユーザー価値を提供する、Estimable: 見積もり可能である、Small: 小さい、Testable: テスト可能である)が満たされている。
  • ビジネスプロセス図のステップとしてマッピングされている。
  • ビジネスコンテキストと価値が明確になっている。
  • MoSCoWなどに基づいて優先順位付けされている。
  • 対話を通じてユーザーストーリーが明確化され、ビジネス、IT、DEV、QAの各チーム(の全員)の間で開発内容についての認識が統一されている。
  • 機能面と非機能面の両方で、受け入れ基準に詳細が取り込まれている。
  • 受け入れ基準の定義に全員が関与している。
  • 主要なユーザーストーリー用のワイヤーフレーム/モックアップの作図と確認が行われている。
  • ビジネスチームによる検証が行われている。
  • テストケース/シナリオが取り込まれている。
  • 有意義かつ包括的なテストデータが用意されている。
  • 新しい手動テストまたは自動テストが明確に特定され、カテゴリ分けされている(UI、API、コンポーネントなど)。
  • ユーザーストーリーによる影響を受ける可能性がある既存テストが、確認を行うために特定されている。
  • 大まかな見積もりが行われ、スプリントに収まっている。

Doneの定義

  • コードが完全なものであり、ITガイドラインに従い、パブリッシュされている。
  • 開発者による単体テストが正常に完了し、DMによって確認されている。
  • 受け入れ基準のテストケースが正常に実行されている。
  • EMによって確認と承認が行われている。
  • ユーザビリティテストとパフォーマンステストが実施されている。
  • 中間デモ(プレビュー)が行われ、デモからビジネスに移行する前の安定化中にフィードバックに対応するための計画が用意されている。
  • 修正が必要な既存テストがすべて更新され、最終的に合格している。
  • 新しいコードの回帰テストで不具合が生じていない。
  • Was this article helpful?