ISTQBに従って、それぞれの意味を思い出させてください。
- Kanbanは柔軟なアジャイルファミリ手法であり、その主な目的は、ワークフローを視覚化し、最適化し、開発時間を短縮することです。
かんばんの特徴は次のとおりです。
- かんばんボードの存在-特定のアクティビティに関連する特定のタスクのステータスを確認できるボード。たとえば、これらのタスクは開発中またはテスト中です。
- 進行中の作業制限。 これは、かんばん委員会の各段階で特定の数のタスクがある場合があることを意味します。 前のタスクのいずれかが完了した場合にのみ、新しいタスクを開発に取り込むことができます。 また、いずれかの段階でタスクが終了した場合、この段階の責任者は、前の段階へのタスクの遂行を支援することができます。
- リードタイム 各タスクには、作成から終了までの間に一定の時間があります。これは順守する必要があります。
- かんばんボードの存在-特定のアクティビティに関連する特定のタスクのステータスを確認できるボード。たとえば、これらのタスクは開発中またはテスト中です。
- XPはアジャイルファミリの柔軟な方法論であり、その主な目的は、コードを高速に記述し、基本的なプログラミングプラクティスをペアで使用し、広範なコードレビューを行い、コード全体の単体テストを行い、コードのシンプルさと明確さを実現することです。 スクラムを使用する場合、コアXPプラクティスがしばしば実装されます。
- スクラムは、アジャイルファミリの柔軟な方法論であり、開発プロセスの基礎となる一連の原則であり、スプリントと呼ばれるハードフィックスおよび短期の反復を可能にし、最も優先度の高い新機能を備えた作業ソフトウェアをエンドユーザーに提供します。
スクラムの特徴的な機能は次のとおりです。
- 製品の増分-チームは、スプリントと呼ばれる定期的な間隔で作業し、特定のアプリケーション機能の開発、テスト、および委託を行います。
- 製品バックログ、スプリントバックログ-アプリケーションの機能は、リストに優先順位付けされたタスクに分割され、それに応じて実行されます。
- 完了の定義-機能に関する作業の最後に、完了の定義と呼ばれる事前に承認された要件を満たす必要があります。 要件は事前に設定され、チーム全体で議論されます。
- デイリースタンドアップミーティングは、毎日のミーティングです。その主な目的は、各チームメンバーから、「昨日やったこと」、「今日すること」、「苦労したこと」の3つの質問に答えることです。 これにより、チーム全体の開発プロセス全体の可視性が向上します。
上記の方法にはすべて、1つの目標があります。それは、高品質の製品をエンドユーザーに迅速に提供することです。 これらはすべて柔軟な方法論です。 ウォーターフォールモデルを使用する場合、アクティブな開発フェーズの完了後に順次実行されるため、テストプロセスは非常にシンプルで理解しやすく、スクラムではすべてがそれほど簡単ではありません。
そして、スクラムはどのように構築されていますか？
チームは、PO（製品所有者）、スクラムマスター、および開発チームで構成され、開発チームは、1つのQAオートメーション、1つのバックエンド開発者、1つのフロントエンド開発者、1つのUX、および1つのレイアウトデザイナーで構成されています。 開発は反復的で、2週間スプリントされます。 各スプリント中に、いくつかのタイプの会議が開催されます。
- 計画-スプリント計画、バックログプロジェクトからの次の2週間の一連のタスク。
- バックログの改良-プロジェクトのロードマップの分析、バックログにあるタスクの評価。
- デモ-スプリントの結果を表示し、完了した作業を評価して、スプリントの成功を決定します。
- レトロ-スプリントのプラス面とマイナス面の議論、マイナス面を排除するために必要なソリューションの検索。
- 毎日の会議-各チームメンバーに代わってプロジェクトの状況を確認するための毎日の集会。
タスクを完了するプロセスは次のとおりです。
- 計画時に、タスクはBacklogプロジェクトの現在のスプリントのBacklogに分類されます
- スクラムボードで開発中ステータスになり、開発者が実行を開始した後
- タスクの結果は、gitの個別の機能ブランチに注がれます。
- タスクは、スクラムボードの「開発中」ステータスから「テスト中」ステータスに移行します。
- 結果はテストベンチに注がれ、テストされます
- 完了したタスクの自動テストが実装されています
- その後、書かれた自動テストと実装された機能がGitのプロジェクトのメインブランチに送信されます-開発する
- すべてのタスクが完了し、自動テストでカバーされると、それらはCIで組み立てられます。 アセンブリが正常に完了すると（すべてのユニットと自動テストに合格）、アプリケーションは自動的にデモの内部デモスタンドに移動します。
- スプリント結果が正常に受け入れられると、アセンブリはpromサーバーにロールアウトされます。
テスト自動化のスプリントの開始時と開発者のスプリントの終了時に何が起こりますか？ 結局のところ、スプリントの開始時には完了したタスクはなく、スプリントの終了時にはテストに転送されないタスクはもうないように思われます。 そして、コード最適化、リファクタリング、新しいツールの実装など、ほぼ同じことが起こります。
自動化エンジニアの例として-開発者にとっての魅力レポートの実装-クエリ作業の最適化。
スクラムでのテスト
テスト自動化プロセスの開始時に、回帰テストを自動的に実行するようにCIを構成する必要があります。 目標は、手作業を最小限にすることです。 何もする時間がないので、素早く作業する必要があります。 その後、リポジトリを実行し、マージ要求によるアセンブリの起動を構成する必要があります。 開発者の1人がプロジェクトのメインブランチに何かを送信すると、アセンブリが開始され、その結果から、変更が正しいかどうかを理解できます。
テストの作成を開始する前に、プロジェクトの主要なビジネスアイデアを理解して、そもそも注意を払っているリスクの高い領域を特定する必要があります。 それと同じように、現実的であり、アプリケーションが小さい場合でも、テストでアプリケーションを完全にカバーすることはできません。 サザーランドは、すべてのバックログを実装するのに十分な時間はないということを書いたので、彼は常にバックログにパレートの原則を適用しました。 可能性のある欠陥の80％をカバーする自動テストの20％を記述します。
テストを書くとき、最大限の抽象化を達成する必要があります。 特定の条件下でのみ使用できる関数のコードを記述しないでください。 入力パラメータを変更して、可能な限りコードを再利用するような方法で実装することをお勧めします。
スクラムでの効果的な作業は、開発者との緊密な作業なしでは不可能です。なぜなら、コードを独立して研究するのに十分な時間がないからです。 直接情報を入手すれば、結果はより速く、より良くなります。 この場合に使用されたこれまたはその機能はどのように実装されますか？ これは、内部構造を理解するために重要です。
テスト自動化の必要な品質
自動化、特にスクラムでは、アプリケーションがどのように機能するかを理解するために、いわゆる「内部」で技術的に精通している必要があります。 ある技術から別の技術にすばやく簡単に切り替えることができることが重要です。 たとえば、データベースを変更する場合、接続方法を変更する準備をする必要があります。 技術スタックは可能な限り広くする必要があります。
スクラムは、変更に対する迅速な反応、緊急の修正を意味します。 ユーザーがアプリケーションに何らかの不整合を見つけた場合、開発チームはできるだけ早くパッチをリリースする必要があります。 これを行うには、問題を非常に正確に特定できることが重要です。 これはセルフテストに非常に役立ちます。 3つのレベルのWebアプリケーションがあるとします。DB、フロントエンド、バックエンドがあります。 アプリケーションのどこかにバグがあります。 手動テストを使用する場合、問題を見つけるには1日以上かかることがあります。その場合、問題を修正して再度テストする必要があります。 セルフテスト中に回帰テストを実行し、数時間以内にバグの正確な場所を示す完全なレポートを取得します。