この記事は、自分の資格を気にかけ、より良くなりたい人に役立ちます。 学習が遅すぎることはありません。
遅かれ早かれ、テスターは仕事のプロセスの質だけでなく、自分自身との関係、つまり教育と能力の質についても考えます。 現時点では、すべての大学がそのような専門家を準備できるわけではありません。 すべての種類のコース、通常は遠隔のコースが残っているため、成功を収めた同じ分野の人々から学ぶ機会があります。 しかし、それ自体を主張する別の方法があります。 これらは証明書です。 たくさんありますが、それは意味がありません。 しかし、ほとんどすべての地域で彼らはそこにあり、領収書ではなく、マイナスよりもプラスです。
ISTQB、いわゆる 国際ソフトウェア試験資格委員会。 これは、テスターにとって世界的に認められている認定です。 これを取得した場合、理論的には基本的な知識と理論があります。つまり、インタビューでプラス記号を取得でき、一般的に自分自身を主張します。
記事では、エラーについて話します。 愚かではありません。 私が個人的にそのようなテストで行った、またはできたものについて。 そして、誰にもそのように捕まって欲しくありません。
包括的なテスト
手始めに、「テストにどれだけの労力を費やしても、徹底的なテストは不可能です（いわゆる原則＃2）」を思い出したいと思います。 この原則を覚えておく必要があります。 準備のために資料へのリンクをあまり投げません。記事の最後にリンクを掲載します。 私が疑問に思ったのは、「十分な労力と道具のサポートがあれば、すべてのソフトウェアで徹底的なテストが可能です。」最初の考えは、忍耐と労力がすべてを粉砕するということでした。できません。問題の数を最小限に抑えることしかできません。
ステージとタスク
覚えておくべき情報。 主なテストプロセスは、活動の段階、領域に分けることができます。
- 計画（ステージ1）
- 分析と設計（ステージ2）
- 実装と実装（ステージ3）
- 終了基準とレポートの評価（ステップ4）
- テストを完了する手順（ステップ5）
これらはすべて、知る価値のある段階です。 それらはランダムに選択されるのではなく、すべてに機能があります。 しかし、これは、特定の状況で重複したり同時に発生したりできないことを意味するものではありません。
実際、私が直面した問題は、分析と設計の段階でどのようなタスクを実行するかでした。 さまざまな答えがありました。
- テスト目標の定義
- テストベースのレビュー
- テスト手順からテストケースを作成する
- プロセスを改善するために学んだ教訓の分析
デザインという言葉をつかんで、私はこの段階ですべてのテスト計画が設計されたので、手順とテストスイートを作成することは素晴らしい答えのように思えました。 私が間違っていた方法。
したがって、私の記事を読んだ後に巨大なマニュアルを読まないようにするために、すべての手順を簡単に検討します。 それぞれを参照するための特別な番号のステージ。
したがって、ステージ1、計画中。 この段階で最も重要なことは、テストの目的を決定し、この目標を達成するのに役立つタスクを自分自身（または上位の人）に説明することです。 範囲、リスク、アプローチ、および人々があります。 このステップには、テスト管理も含まれます。 計画を作成しただけでなく、プロセス全体を通して、タスクごとに実行されていることを監視しています。 したがって、目標を設定するだけでなく、目標を監視します。
第二に-私たちはプロジェクトを分析し、従事しています。 何が含まれていますか？ テストの基礎の単なるレビュー。 プロジェクトの整合性に関する要件、リスク分析に関するレポート、アーキテクチャ、設計、技術が含まれます。 インターフェイス要件。 この段階では、本質的に、リスクレポートを作成し、特性を評価し、優先順位を付けて、プロジェクトのアーキテクチャが出現します。 テスト環境を選択し、すべてのツールをインストールします。
第3段階では、テストスクリプトを記述する意志が与えられ、すべての重要な作業は、手動モードまたは自動モードで実行するためにすぐに実行されます。 実装と実装の段階をテスターの人生で最も重要なものと考えたいと思います。間違いなく最も時間がかかります。ほとんどの問題は認められることであり、後悔することはありません。
第4段階では、主にレポートを処理し、可能な特性を評価し、見つかったバグを調べ、実行できる他のテストを分析し、これらすべてを関心のある人向けのレポートにまとめます。
そして最後に、第5段階はむしろ一連の経験です。 どのような結果が得られたか、どのような目標を達成できたかを調べ、将来のリリースのためにデータを分析し、さらに活用します。 この段階でも、文書化なしで行うことはできません。文書化は、メンテナンスの段階に詳細に行う必要があります。
保守試験
私のミスは、この段階で、受け入れ手続き中にシステム上の苦情の分析に対処できることを提案しました。 そして、これが主なタスクです。 実際、メンテナンス期間中のテストには、環境を変更した後のシステムの動作が含まれます。 つまり、この段落は、現在のシステムに対するこれらの変更の影響、またはいくつかの追加の変更を指します。
たとえば、プラットフォームの変更。 保守テストとは何ですか？ すべての運用テスト、テスト変更、影響を受けなかった領域の回帰テスト計画のリストに追加する価値もあります。 この場合、主な問題は、テストに含める必要がある領域の境界です。 時間とリソースに余裕がある場合は、それらすべてを含める必要があります。 しかし、この時間は常に十分ではありません。 したがって、決定を下すには、リスクと、システムのサイズと変更のサイズの比率を評価する必要があります。
システムおよびコンポーネントのテスト
覚えておくべき主なことは、コンポーネントのテストは通常開発者の責任であり、システムのテストはテスターの典型的な責任であることです。
コンポーネントのテストでは、可能な限りシステムをこれらの部分に分割できる限り、システムの異なる部分でのみ同じ欠陥検索を行っています。 これらの各部品を個別にテストできることが重要です。 多くの方法とアプローチがありますが、これは非常に広大なトピックであり、テストの種類の違いから、本質から離れます。 コンポーネントテストのもう1つの機能は、機能テストだけでなく、非機能特性もチェックされることです。 たとえば、これには、リソースの動作のテスト、メモリリークの追跡が含まれます。 通常、コンポーネントのテストでは、コードを使用できます。
反対はシステムテストです。 コンポーネント内で各部分を個別の部分と見なした場合、ここではシステムを単一のオブジェクトと見なします。 テストでは、多くの方法を使用し、機能要件と非機能要件の両方を調べます。 ここでは、テストの説明、システムを使用するためのオプション、およびその他のさまざまなバグ検出方法がすでに研究に適していますが、システム自体はコードにアクセスできない「ブラックボックス」と見なされます。
正式なピアレビューとその手順
システムのコード要件、入力データの要件、いくつかの法的問題などを考慮する必要がある場合など、システムにレビューが追加されます。 基本的に、システム内の各モジュールを完成させるために考慮しなければならないリストがあります。 このプロセスでは、必要な分野の専門家に頼らなければならない可能性があります。
正式なピアレビューの主な段階は、計画、開始、個々の準備、研究/評価/結果の記録、再処理、追跡です。 手順は実際にはすべて一貫していて論理的です。 必要な基準を計画し、人々を選択しました。最初に、この特定のシステムのすべての機能と要件を考慮して、計画を共有し、個別に準備しました。 その後、私たちは専門家に示された結果を得て、浮上したすべての問題を修正しました。 そして、どこでも壊れていないことを確認します。
おわりに
この資料は、今後の認証に関連するすべての問題を解決するために作成されたものではありません。 少なくとも私がカバーできた小さなものが確実に私の頭に収まることを願っています。 少なくともある程度記事が有用であれば、私の意見では、単純に回避できる可能性のある非自明なエラーを引き続き分析できます。
建設的な批判に常に備えています。 疑問が生じたり、私の声明に議論の主題がある場合、理論に戻る機会が再びあります。
便利なリンク
トレーニング資料
Natalia Rukolのテストに関する良い記事