Agiles Testen -Wikipedia

いつ アジャイルテスト （ラテン語から アジャイル 「Flink、Movable」）は、アジャイル開発プロジェクトの一部としてテストソフトウェアと呼ばれます。アジャイル開発プロジェクトでのテストには、何よりも開発チームのサポートに焦点を当てる必要があります。アジャイルテスターの多くの特性も従来のテスターに​​役立ちますが、関連する問題はそれほど明確ではないため、すべてのプロジェクトチームによって改善されていません。アジャイルテストは、アジャイルマニフェストの原則に従い、テストにアジャイル原則を使用します。

アジャイルテストは、アジャイルソフトウェア開発の目標を最適にサポートするように設計する必要があります。

• 顧客または顧客担当者の間の緊密な協力によって引き起こされる高い顧客満足度（スクラム、たとえば、製品所有者など）と開発チーム、
• エラー予防と早期障害発見に関する開発活動の一貫したオリエンテーションから生じる製品品質の高い
• 盲目の仕事の削減によって引き起こされる高い開発速度（不必要なドキュメント、不必要なエラー補正など）
• 短い反復によって可能になった変化に対する迅速な反応、
• 自己組織化と永続的に許容される作業ペースによってサポートされている高いチームの動機。

特定の状況では、「クラシック」の値、ほとんどが位相指向または反復的な増分手順を考慮する必要があります。 B.規制された環境：

• テスト活動の良好な予測可能性、迫害、検証可能性
• 高く再現可能なテストカバレッジに起因するテストデザインの高いシステム

速度後の要求と不必要な作業を避けるために、もう一方の体系的および信頼性を回避するために、アジャイルテスト手続きは、次の基本原則に基づいている必要があります。

高速フィードバック [ 編集 | ソーステキストを編集します ]

新しく開発または変更されたプログラムコードは、配信前にテストする必要があります。スクラムなどの反復方法では、これは、アジャイルテスターが通常、2週間以内に作成および変更された機能に関する情報を高速なフィードバックを通じてチームに提供する必要があることを意味します。この高速フィードバックサイクルが機能するように、数日後に最初のテスト可能なバージョンで機能を使用できる必要があります。さらに、テスターはスプリントの前の関数の定義にも関与しています。

チームの現在のステータスに関するフィードバックをできるだけ速く提供できるようにするために、多くのチームは、高度な自動化と軽量のマニュアル探索的テストのバランスバランスに依存しています。プログラマーは自動化におけるテスターの作業をサポートし、重要なスキルを持つテスターはテスト自動化の出発点を提供します。さらに、アジャイルチームは、すべてを自動化できるわけではないことを認識しています。不十分に設計されたユーザーインターフェイスや非表示のコントロールなどの対応するリスクは、探索テストを介してお客様に対処します。

高度の自動化 [ 編集 | ソーステキストを編集します ]

要件の変更とプログラムコードの恒久的なリファクタリングに対する迅速な反応をサポートするには、できるだけ多くの体系的なテストケースを設計および自動化する必要があります。これには、構造的にベースのテスト（単体テスト）、専門的なシステムおよび受け入れテストが含まれます。

Geringerオーバーヘッド [ 編集 | ソーステキストを編集します ]

非操作テスト活動（テスト管理、エラー管理、ドキュメント作業など）の努力は、できるだけ低く保つ必要があります。

テストの役割の溶解 [ 編集 | ソーステキストを編集します ]

アジャイルの原則に従って、すべてのテスト活動に対する責任がチーム全体に分配されます。これは、古典的なテストの役割（テストマネージャー、テストアナリスト、テスター）と、時にはソフトウェア開発者とテスターの境界との間で消えます。ただし、必要な資格のため、後者は開発とテスト作業の両方に設定されています。

テスト段階の溶解 [ 編集 | ソーステキストを編集します ]

典型的なアジャイル反復長の2〜3週間以内に、一連のテスト段階（ユニット、統合、システムテストなど）のシーケンシャルシーケンスの時間はありません。ただし、さまざまなテストレベルでカバーされているさまざまなテスト目標に到達する必要があり、「マイクロテストサイクル」のテストアクティビティ（通常、ユニット、統合、およびシステムテストのシーケンス、24時間以内に）でカバーする必要があります。アジャイルのコンテキストでは、テストレベルは、時間的テストフェーズの代わりにコンテンツテストとしてむしろ理解する必要があります。

チームの緊密な協力 [ 編集 | ソーステキストを編集します ]

迅速なフィードバックへの欲求と、チーム全体を通じてテストする責任の仮定は、「テスター」（つまり、テスターの雇用者の大部分）と「開発者」、「テスター」と顧客担当者（スクラムDEM製品所有者）との間の緊密な協力をします。
この協力は、直接的なコミュニケーション（したがって、顧客とチームに価値のない文書の広範な権利放棄）を通じて、ペア（SO -Called ペアリング ）到達した。

一部のスクラムアーティファクトとプロセスのいくつかの重要なポイントで、体系的な事実を「固定」することにより、アジャイルの才能の目標を実現することができます。

「準備ができている」（DOR） [ 編集 | ソーステキストを編集します ]

DORは、テスト能力を早期に確保するのに役立ちます。これは、製品所有者によるユーザーストーリーの作成、品質保証、および製品からスプリントバックログまでストーリーが使用される場合に使用されるチェックリストです。定義の意味で「準備ができていない」ストーリーは、スプリント計画会議中にチームによって拒否される可能性があります。 DORは、ストーリーの技術的および技術的なテスト可能性を保証し、可能な運用上の受け入れ基準の定義を求めています。適切な受け入れ基準は、「例による仕様」アプローチによって作成されます ^[初め] 。いわゆる投資基準は、DORの良い出発点です ^[2] 要件について。ストーリーを作成するとき、テストと製品所有者のペアリングは、テストと品質保証の方法論的知識と製品所有者の専門知識を組み合わせるために理にかなっています。

「完了の定義」（DOD） [ 編集 | ソーステキストを編集します ]

DODは品質の目標を固定します。これは別のチェックリストであり、「Sprint Reviewの提出の準備ができている」と見なされる前に、ストーリーの実装においてチームがどの目標を達成しなければならないかを説明します。 DODでは、次のようなテスト目標B.必要なテストタイプ、達成するテストカバー、およびテスト基準（次に、見つかったすべてのエラーの削除）。したがって、DODは、製品の品質と顧客満足度を確保するために直接機能します。

「テストの定義」（DOT） [ 編集 | ソーステキストを編集します ]

ドットは、アジャイルチームのテスト戦略を固定します。彼らは、中央のドキュメントであるチームにとって有効な「ゲームのルール」を脱ぎます。この憲章は、一般的な手順を固定するのに理想的な場所でもあります。 B.テストケースドラフトおよびテスターのツール使用。

ドットでは、どの情報（たとえば、ストーリーのリスクと価値の分類とその説明）に基づいて説明され、実装され、実行する必要があります。リスクまたは価値指向のテスト戦略の「古典的な」テストから知られているアーティファクトに取って代わります。アジャイルテスト戦略の定義の良い出発点は、「アジャイルテスト象限」です ^[3] 。

スプリントに伴うテスト [ 編集 | ソーステキストを編集します ]

の原則 実現とテストノンストップ 。スプリント中に、「テスター」が初日からチームに統合され、ストーリーの実現について「開発者」と並行して作業することを保証する必要があります。このための好ましいスキルは次のとおりです。

• スプリント計画と毎日のスクラム会議へのテスターの参加
• 開発およびテスト活動の一時的な絡み合い。この目的のために、「テスト駆動型開発」や「最初のテスト」や開発者とテスターのペアリングなどの原則が適切です
• アジャイルチームの中央計画であるタスクボードでの適切なプレゼンテーションを通じて、計画とステータスの追跡におけるテストの透明な表現
• 体系的な単体テストの実装、つまりH.同等のクラス分析、状態分析、または決定テーブルなどの体系的なテスト方法を使用するもの ^[4] 発展
• 系統的テストと探索的テストの組み合わせ。後者は特に迅速にフィードバックを提供し、体系的なテストでは見つからない可能性のある間違いを見つけます
• CI（継続的統合、継続的統合）環境の動作は、適切なリスク指向戦略に従って変更（チェックイン）を導入し、回帰テストとして実行される変更（チェックイン）を導入するときに選択される自動化されたユニット、統合、およびシステムテストを選択します。

成熟した試験発作 [ 編集 | ソーステキストを編集します ]

ユニットと統合テストだけでなく、システムと受け入れテストも、スプリントの早い段階で（ストーリーの実装または「テスト」という意味でさえ、可能な限り同時に）設計および自動化する必要があります。スプリント中は、変更とリファクタリングの「セキュリティネット」として機能するために永久に走っている必要があります。ブラックボックステストのレベルでは、さまざまなフレームワークが、たとえば、ソフトウェアの堅牢なテスト自動化の変更や不正行為に対して、このような早期を構築するのに特に役立つことがわかります。

たとえば、ユーザーストーリーの形でのビジネス要件は、Gherkinで作成し、BDDフレームワークを使用して自動化できますが、統合ポイントとパフォーマンス基準の不正行為は、テスト尿を使用してチェックされます。テスターのタスクは、追加のテストケースを特定し、特に誤った入力のためにアプリケーションを不正行為に意図的に説得することです。

• スコット・アンブラー： アジャイルモデリング。極端なプログラミングと統一プロセスのための効果的な実践。 ジョン・ワイリー＆サンズ、ニューヨークニューヨーク2002、ISBN 0-471-20282-7
• マイク・コーン： アジャイルの推定と計画。 Prentice Hall Ptr、Saddle River NJ U。 a。 2005、ISBN 0-13-147941-5。
• エスター・ダービー、ダイアナ・ラーセン： アジャイル回顧策。良いチームを素晴らしいものにします。 実用的な本棚、ローリーNC u。 a。 2006、ISBN 0-9776166-4-9。
• トーマス・ロスナー、クリスチャン・ブランデス、ヘルムート・ゲッツ、マリオ・ウィンター： モデルベースのテストの基本的な知識。 Point.Val。Hellberg、2010、2010、ISBN 978-3-89864-58-8-8。
• Andreas Spillner、ThomasRoßner、Mario Winter、Tilo Linz： 実用的な知識ソフトウェアテスト – テスト管理。 ISTQB規格に従って、認定テスターの高度なレベルへのトレーニングとさらなる教育。 3番目、改訂版、拡張版。 Dpunkt.verlag、Heidelberg 2011、ISBN 978-3-89864-746-5。
• シルケ・ガイゼン、バリス・ギュルダリ： スクラムでのアジャイルテスト – テストの種類とプロセス 。オブジェクトスペクトルオンラインテーマスペシャル、エディションアジリティ/2012。
• Manfred Baumgartner、Martin Klonk、Helmut Pichler、Richard Seidl、Siegfried Tanczos： アジャイルテスト – 品質へのアジャイルな方法 。 Carl Hanser Verlag、Munich 2013、ISBN 978-3-446-43194-2（ アジャイルテスト [2013年9月11日にアクセス]）。
• ジェームズ・A・ウィテカー、ジェイソン・アーボン、ジェフ・カロロ： Googleがソフトウェアをテストする方法 。 Addison-Wesley Professional、2012、ISBN 978-0-321-80302-3。

1. ↑ Gojko Adzic： 例別の仕様。成功したチームが適切なソフトウェアを提供する方法。 Manning Publications、Shelter Island NY 2011、ISBN 978-1-61729-008-4。
2. ↑ マイク・コーン： ユーザーストーリーが適用されます。アジャイルソフトウェア開発用。 Addison-Wesley、ボストンMA u。 a。 2004年、ISBN 0-321-20568-5。
3. ↑ リサ・クリスピン、ジャネット・グレゴリー： アジャイルテスト。テスターとアジャイルチームのための実用的なガイド。 アディソン・ウェスリー、サドル・リバーニュージャージー州u。 a。 2009、ISBN 978-0-321-53446-0。
4. ↑ アンドレアス・ゲームズ、ティロ・リンツ： 基本的な知識ソフトウェアテスト。認定テスターへのトレーニングとさらなる教育。 ISTQB標準に応じた基礎レベル。 第4、改訂および更新版。 Dpunkt.verlag、Heidelberg 2010、ISBN 978-3-89864-642-0。
5. ↑ Fitnesse Acceptance Testingフレームワーク
6. ↑ ロボットフレームワーク
7. ↑ HelmutGötz、Markus nickolaus、ThomasRoßner、Knut Salomon： モデルベースのテスト。モデリングとテストの生成。基本、ツール使用の基準、概要のツール （= IX研究。 01、2009年3月）。 Heise Magazines Verlag、Hanover 2009。