ITの他の分野と同様に、テストは急速に発展しています。 そしてここで、最新の状態を保つことも同様に重要です。 新しい情報を入手する方法の1つは、会議/セミナーに参加することです。 そして、このメソッドを正常に使用します。
2016年5月20〜21日、第19回国際会議「SQA Days」がサンクトペテルブルクで開催されました。 イベントは3つの流れで開催され、会議の2日間で、さまざまなトピックに関する57のレポートがここで聞かれました。テストプロセス自体、テストチームの構築の原則、QAスペシャリストの専門的な成長とモチベーションです。
テスト自動化に関するレポートは、別のフローで送られました。 多くのスピーチは、DevOps、Continuous Deliveryなどのトレンドに捧げられました。 SQA Days-19の最も興味深い報告についてお話します。
Jenkins 2.0：継続的デリバリーの一部としてテストを編成します （Oleg Nenashev）
Olegは、オープンソースプロジェクトJenkinsのコアチームのメンバーであり、CloudBeesで働いており、そこでCloudBees Jenkinsプラットフォームを開発しています。 Olegは、継続的デリバリのトピックと、この方法論を実装するときに発生するタスクに触れました。
継続的デリバリーでは、製品テストはすべての段階で短いサイクルで行われ、テストは可能な限り自動化されます。 必要に応じて、継続的デリバリーには、製品の以前のバージョンへの迅速なロールバックが含まれます。 この方法では、インフラストラクチャがプロジェクトにとって重要になります。 障害が発生するとすぐに、特に変更をロールバックする必要があり、新しい機能をリリースしない場合は、すぐに損失が発生し始めます。 インフラストラクチャは製品によって変化するため、それに合わせてテストする必要があります。 継続的デリバリーのフレームワーク内では、これらはもちろん、システムをモジュールに分割する短いサイクルです。 そのようなテストを整理するには何が必要ですか？ プロジェクトのプロセスの並列化、コードとアセンブリ手順のバージョン管理、テストとアセンブリの再現性、実際のリリースでのテスト。
継続的デリバリーの実装には自動化システムが必要です。 OlegはJenkins 2.0の新機能について話し、コードテクノロジーとしての新しいPipelineに焦点を当てました。 古典的なJenkinsインタラクションモデルはWebユーザーインターフェイスです。 ユーザーは、新しいタスクを手動で作成し、詳細を追加する必要があります。 この点で、プロジェクトの作成と管理には追加の作業が必要です。さらに、Jenkinsタスク設定はプロジェクトコードとは別に保存されます。 このアプローチにより、最高の継続的インテグレーション/継続的デリバリ手法を適用することができなくなります。 Jenkins Pipelineを使用すると、アセンブリプロセスをコードの形式で記述できるため、Jenkinsタスクの構成をプロジェクトコードと共にバージョン管理システムに保存し、変更を追跡し、プロジェクトでテストできます。
結論として、OlegはCloudBees JenkinsプラットフォームでのPipelineの使用が成功したことについて話し、また、コードとしてのPipelineが自動化サポートコストを削減し、継続的デリバリーに使用できると結論付けました。
恐れることを止めて自動化を開始する方法。 開始しないか （Alexey Lyazgunov）
このレポートは主に興味深いものです：
- プロジェクトに自動化を実装したいテストマネージャー
- 自動化が「機能しているように見える」が、それが結果をもたらすかどうかは明らかではないチームに
- いくつかのアクションを自動化し、コマンドレベルに上げたいエンジニアも同様です。
レポートは詳細であることが判明し、そのような瞬間に触れました：自動化とは何か、自動化とその消費者の役割、自動化に期待されるもの、自動化が高価で長い理由、自動化からの目標と期待、失敗の原因。 スピーカーは、自動化の目標について詳細に説明し、条件付きでそれらを良い、悪い、疑わしいものに分けました。
- テスト時間を短縮します 。 一見、目標は良好ですが、それはすべて自動化する必要があるものに依存します。 たとえば、これが新しい機能である場合、テストの期間は大幅に長くなります。 したがって、すぐにテストする必要がある場合は、おそらく自動化すべきではないことを理解する必要があります。
- チェック/カバレッジの数を増やしてください 。
- より頻繁なチェックを提供します 。 自動化の主な目標の1つ。
- 「人的要因」の影響を減らします。 アレクセイによると、疑わしい目標ですが、場合によっては良い目標です。 確かに、特定の順次ステップに従ってテストを実行する必要がある場合があります。 ただし、多くの場合、テストでは人が検出できる欠陥を検出できないことを理解する必要があります。
- より安価なテスト 。 自動化は高価であり、新しいプラクティスにお金を払わなければなりません。
- 新しいタイプのテストを導入します 。 自動化により、手ではできないことを行うことができます。
- 新しいリリースのリリース時間を短縮します。 良い目標ですが、基本的なテストセットがあるはずなので、最初は達成するのが少し難しいです。
- 手動テスターを自動テストに置き換えます 。
- 現在のステータスをすばやく取得します 。 素晴らしい目標。 たとえば、テスト用にビルドを提供する価値があるかどうかを知りたいため、特定のテストセットを実行します。
- 手動スクリプトの自動化 。 スピーカーの観点からすると、これは悪い目標です。 もちろん、一連の受け入れシナリオを自動化することは良いことですが、より詳細に、そしてより広く自動テストでカバーする場合、多くの困難に直面します。 まず、手動スクリプトは主にUIテストであり、これは最も高価で信頼性の低い自動化です。 さらに、テストの詳細、スクリプトごとのテストの内訳が異なります。 異なるインターフェイスを使用したほうが良い場合があります（たとえば、フロントエンドでフォームに入力するよりも、APIを使用してユーザーを作成した方がよい場合があります）。 また、すべての手動テストが自動化されているわけではなく、可能なすべてのテストに手動スクリプトがあるわけではありません。
- 回帰テストを自動化します 。 回帰テストを自動化する場合、新しい自動テストを記述するペースは製品開発のペースと同じにする必要があることを理解する必要があります。 可能であれば、そのような目標を自分で設定できます。そうでない場合は、モジュールまたはコンポーネントレベルでのみ回帰テストを自動化することをお勧めします。
- 自動化によりテストが簡素化されます 。
目標を要約すると、Alexeyは最初に緑で強調表示された目標に焦点を合わせ、「青」の目標を設定することを提案します。
その後、アレックスは「3つのDO」の概念を紹介します。自動化は良い、高価、長いです。 これは質問のリストですが、自動化を実装するときに答える価値があります。
自動化は大歓迎です：
- 自動化を実装することで解決したい問題は何ですか？
- 自動化に対する私の期待-妄想ではありませんか？
- リーダーシップとチームのサポートと理解はありますか？
- 自動化をプロセスに統合する方法を知っていますか？
自動化は高価です：
- 自動化に対価を支払うつもりはありますか？
- 新しい人を雇う準備はできていますか？
- インフラストラクチャ、ツール、トレーニングの費用を支払うつもりはありますか？
- 常に支払う準備はできていますか？
自動化は長い：
- 自動化の利点はすぐには得られないことを理解していますか？
- 開発のすべての参加者が関与し、開発へのアプローチを変更する必要があることを知っていますか？
- 私は理解しました、始めたので、私は止めることができませんか？
- プロジェクトは、自動化の成果を享受するのに十分な長さですか？
- 自動化の研究に時間を費やすつもりはありますか？
結論として、アレクセイはチェックリストを作成することを提案し、収集した情報に基づいて「自動化を実装する価値があるかどうか」という質問に「はい」と答えます。これは実装できるという意味ではありません。 これはおそらくあなたが成功することを意味します。 しかし、答えが「いいえ」の場合、ほとんどの場合、成功しません。 しかし、試していない場合、それは間違いなく動作しません。
自動化手法の評価 -MBT（Dmitry Khimion）
技術的には、レポートは強力で高品質でした。 Model Based Testing（MBT）方法論とアジャイルフレームワーク内での適用性に専念しました。
つまり、MBTは、自動テストシステムの一部としてテストを整理する1つの方法です。 すべてのアプリケーションは状態マシンです。
古典的な意味では、この方法論にはテストケースはなく、テスト対象のシステムのモデルのみがあります。 自動テストなどのエンティティはありません。テストスクリプトは、自動テストの実行中に生成されます。
Dmitryは、MBTを自動テストの従来のアプローチと比較します。 ある状態から別の状態への遷移のように、すべての状態は一度記述され、組み合わせメカニズムによるテストの生成で一度だけ使用されます。 変更の量は開発者とほぼ同じです。 線形スクリプトを使用する場合、自動テストの優れたモジュラーシステムがある場合でも、共通コードが渡され、たとえば新しい手順を追加する必要がある場合、新しい機能を使用するすべてのテストを修正する必要があります。 テストの数が増えると、テストの開発と更新の期間が長くなります。 MBTはアジャイルソフトウェア開発に役立ちます。 アジャイル手法には、常に作業成果物である短距離スプリントが含まれます。 すべてのアジャイルチームは、理想的には、開発が完了したらテストの完了に努めます。 生成されたテストスイートはモデルを変更することで柔軟に変更でき、これに必要な時間は機能の開発にほぼ等しいことを考慮すると、適切な組織では、MBT自動化は開発に追いつくか、開発がタイムラインを延長しても追いつかず、この場合スプリントの継続時間が長くなります。
Dmitryは、MBTフレームワークの概念をさらに説明しました。そのアーキテクチャ図を以下に示します。 ソース-モデルの構築元の外部ソース。 テストモデル-テスト中のシステムのモデル。外部ソースからプログラムビューに変換されます。 Generatorはモデルをグラフの形式で読み取り、パス（テストシーケンス）を形成します。 制限ツール-テストシーケンスの生成を制限するメカニズム。 Test Managerは、システムのパフォーマンスと結果の集計を担当します。 ロガー-ロギング用のモジュール。
要約すると、DmitryはMBTを使用することのプラス面を強調しました。 この方法論は、コードの量を最小限に抑えるために機能します。 MBTは、組み合わせによって高いテスト範囲を提供します。 モデルを更新する時間は、ほとんどの場合、新しい機能を開発する時間に対応するため、メソドロジーはアジャイルに適用できます。 MBTを使用する場合の短所は、ツールの選択肢が限られていることです。 さらに、前の図で灰色で示されているモジュールは、独自に実装する必要があります。