手動テスターから自動テスターへの移行
テスト管理ツールコラム
導入
テストの自動化は長年にわたって行われてきましたが、ツールがよりユーザーフレンドリーになり、テスターの技術がますます高まるにつれて、ますます注目を集めています。QAアナリストを含む多くのQAおよびテストの役割の要件として技術スキルを追加する雇用主がますます増えています。
しかし、従来の手動テストで障害を見つけることに熟練している手動テスターはどうなるでしょうか? 手動テスターはテスト自動化を適用するスキルをどのようにして習得しますか? また、手動テスターは、テストに対するより技術的なアプローチに移行する必要があると感じるべきでしょうか?
この記事では、手動テスターから自動テスターに移行するためのいくつかのオプションと、テストの自動化が適切かどうかについてのガイダンスを説明します。
テスト自動化の学習は良い転職ですか?
私は最近、大手求人サイトで「QA アナリスト」の求人情報について非常にランダムな調査を実施しました。「QA アナリスト」の職務内容の 90% 以上で、テスト自動化の経験が必須であるか、テスト自動化の経験が望ましいと示されていることがわかりました。さらに興味深いのは、「QA アナリスト」の検索結果では、役職の約半数が「QA オートメーション アナリスト」または「QA オートメーション エンジニア」であったことです。それはとても重要なことです。
職務内容の中に純粋に手動テストのみを示す投稿は見つかりませんでした。
このサンプリングは単なるサンプルですが、テストの自動化が QA/テストのキャリアにおいて考慮すべきものであることを示す強力な指標となります。
私自身の場合、テスト自動化は QA およびテスト分野での成功の非常に大きな部分を占めています。私は 1980 年代後半の初期にテスト自動化に携わることができて幸運でした。現在、私は約 90% の時間でテスト自動化を使用しています。
手動テストと自動テスト
手動テストと自動テストは根本的に異なる 2 つのテスト アプローチであり、それぞれに異なるスキルと属性が必要です。これら 2 つのアプローチには共通の領域があり、場合によっては、一方が他方より必ずしも優れているとは限りません。
こう主張する人もいるかもしれませんが、テスト自動化はテストです。手動テストとは見た目も操作性も異なり、多くの場合、目標も異なりますが、テスト作業全体で大きな活用ができるテスト形式です。
優れたテストの条件を理解していないと、自動テストは弱くなります。組織でテスト評価を行うと、このような弱いテストをよく目にします。
役立つ例えの 1 つは、私が「電動工具の例え」と呼んでいるものです。
本棚を作りたいと想像してください。手鋸で木材を切る代わりに、店に行って電動鋸を購入します。家に帰ると、棚を作るために木材を切り始めます。でもちょっと待ってください…
板をどのくらいの長さにすればよいのか、あるいは真っすぐに切る方法がわからないと、非常に醜くて機能しない棚ができてしまいます。教訓は、ツールが役に立つ前に、ツールの使い方だけでなく、木工自体の基本を理解する必要があるということです。
テストツールにも同じことが当てはまります。テスト ツールをインテリジェントに使用するには、まず、テスト対象のテスト方法を理解する必要があります。
テスト自動化とは実際何ですか?
手動テストからテスト自動化への移行を検討しているテスターは、基本的にソフトウェアをテストするためにソフトウェアを作成 (または使用) していることを考慮してください。コードファーストのアプローチを使用している場合、あなたはテスターであると同時にソフトウェア開発者の役割を果たしています。
テスト自動化では、コーディングと同じスキルが必要になります。つまり、問題解決、細部への注意、反復可能なパターンでの思考、保守可能なスクリプトの作成などです。
ノーコード/ローコードツールとスクリプト化されたツール
初期スクリプトをほとんどまたはまったく必要としないツール (コードなし/ローコード ツール) と、完全に「コードファースト」のツールとの間には、重要な違いがあります。
ノーコード/ローコード ツール (Selenium IDE など) を使用すると、テスト セッションを記録し、最初に記録したとおりに再生することができます。これはデモでは適切に見えますが、場合によっては、テスト自動化のニーズには十分である可能性があります。
しばらくテスト自動化に取り組んだことがある人は、予期しないエラー メッセージやループ条件などの特殊な条件を処理するために、ある時点で何らかの手動によるコーディング作業が必要になる可能性があることを知っています。
ただし、ノーコード/ローコード ツールを使用して初期テスト スクリプトを作成し、必要に応じて変更することには価値があります。これにより、空白の画面からテスト スクリプトを作成したり、既存のテスト スクリプトをコピーして調整したりする場合に比べて、時間を大幅に節約できます。
ノーコード/ローコード ツールのもう 1 つの大きな利点は、多くの場合、純粋なスクリプト ツールや言語よりも学習が簡単であることです。これは、テスターによるツールの採用率が高くなり、コードファースト ツールを使用するよりもはるかに早くテスト自動化の目標を達成できる可能性があることを意味します。
「コードファースト」ツール (Selenium WebDriver ベースのツールなど) は、ノーコード/ローコード ツールよりも労働集約的で、より多くの技術的専門知識を必要としますが、より複雑な状況に対処できます。
最初は、コードファーストのツールを学ぶのは難しいかもしれません。ただし、熱心に取り組むことで、基本的なコマンドから始めて、さらに仕上げていくことができます。ただし、コードファースト ツールは、特にテスト スクリプトの保守に関しては、より多くの労力を必要とする可能性があることに注意してください。
役立つテスト自動化の原則
ここで、手動テスターから自動テスターに移行する際に役立つテスト自動化の原則をいくつか説明します。
原則 1 – テスト自動化は単なるツール以上のものです
テストの自動化について考えるとき、最初に思い浮かぶのはツールです。「どのツールを使用していますか?」、「そのツールをどれくらい使用していますか?」などの質問がよくあります。
めったに聞かれない質問は次のとおりです。
- 「ツールを使用するプロセスは何ですか?」
- 「自動テストをどのように設計して実装しますか?」
- 「自動テストはどこで管理および保守していますか?」
- 「テスト自動化に関してあなたのチームをトレーニングし、指導するのは誰ですか?」
- 「あなたの組織ではテストツールがどの程度広く導入されていますか?」
おそらく、どの特定のツールを使用しているか、または使用する予定であるかよりも、これらの質問の方が重要であると思います。
私はよくテストを、管理されたテスト環境内で行われる人、プロセス、ツールの「鉄の三角形」と表現します (図 1)。
図 1 – テストの鉄の三角形
もちろん、アイアン トライアングル (一部では「PPT」と呼ばれています) はテストだけを目的としたものではありません。ソフトウェア開発、IT セキュリティなど、さまざまな場面でそれが見られます。
この図からわかることは、テストを効率的に行うには、これらの要素のバランスが取れている必要があるということです。ツールはあっても、それを使用するためのプロセスがなく、人々がツールを使用する意欲を欠いている場合、未使用のツール (「シェルフウェア」とも呼ばれます) が残ることになります。
同様に、ツールと意欲的な人材はあるものの、プロセスがない場合は、ランダムで組織化されていない自動テストが大量に作成される危険があります。
最後に、プロセスと人材はあるがツールがない場合、テストは手間がかかり、多くの場合非効率的になります。
原則 2 – テスト ツールは何をテストすべきかを教えてくれない
テスト ツールの登場以来、ツールのトレーニングには欠けている部分がありました。欠けている部分は、ツール トレーニングでは、特定のツールを使用してテストを自動化する方法を学習しますが、多くの場合、テスト対象の項目に対して適切なテストを設計する方法は学習しないことです。
ツールのトレーナーと開発者を擁護するために、ツールのトレーニングの焦点はツールの使用方法にあるべきです。ただし、ツールを使用して適切なテストを作成する方法を示さないと、ツールの結果が非効果的になります。
トレーニングが終了し、自分の環境やアプリケーションでツールを使用してみると、分からないことを実際に学び始めます。
テスト自動化ツールを入手するだけでテスト範囲が広がり、より良いテストができると信じている人が多すぎます。テスト自動化ツールは、テストするように指示した内容と、テストするように指示した方法をテストします。
つまり、テスト自動化においても、誰かがやらなければいけない分析という作業が残っているということです。
原則 3 – テストの自動化には問題解決が必要になることがよくあります
私は毎日テスト自動化に取り組んでおり、問題の解決にかなりの時間を費やしています。
場合によっては、予期しないスクリプトエラーが発生する可能性があります。したがって、アプリケーションの変更によってテスト スクリプトが間違っているのか、それとも対処する必要がある環境上の問題があるのかを判断する必要があります。あるいは、テスト対象のアイテムに本当に欠陥がある可能性があります。
テスト自動化における問題解決は、テストそのものだけに留まらない場合もあります。おそらく、現在のツールやアプローチでは簡単に実行できない新しいことをテストする方法を考案する必要があるでしょう。
問題解決はスキルであると同時に考え方でもあります。問題について考え、情報を収集し、仮説を検証する方法を学べば、問題解決者への道を歩み始めます。
問題解決者への移行に向けて私が強くお勧めする本の 1 つが、『Are Your Lights On?』です。ジェラルド・ワインバーグ著。これは新しい本ではありませんが、技術的な文脈における問題解決のテーマに関する優れた本です。
原則 4 – 基本的なテストを自動化することは 1 つのことです。堅牢で厳格なテストを自動化することは別のことです
前述したように、ツールのデモとトレーニングでは、ほとんどの例は非常に基本的なテストです。これらはスモーク テストまたは健全性テストと考えることができます。実際、回帰テストの多くはかなり基本的で確認的なものです。ただし、陰性テストを自動化する必要がある場合があります。
例として、私が作成したテスト自動化アプリケーションは、人々が食品を注文できるようにするものです。要件は、最大注文金額が 75 ドルであることです。そこで、75 ドルを超える注文が許可されていないことを確認する自動テストを作成しました。しかし、そのテストが実施されてすぐに、20 ドルを超える注文ができないという欠陥が発見されました。
私の最初のテストは、すべてのテスト理論によれば正しかったです。$75 以下が「有効」クラス、$75 が境界値、$75 以上が無効でした。しかし…「有効な」範囲またはクラスに欠陥が発生しました。
そこで、今後こうした状況を特定しやすくするために、20 ドル、40 ドル、60 ドル、75 ドル、75 ドル以上など、さまざまな価格レベルでテストするテスト スクリプトを作成しました。完璧ではありませんでしたが、以前よりも良いテストとなりました。
原則 5 – 自動テスト スクリプトにはバグが存在する可能性があります
テスト自動化では、手動または生成ツールを使用してコードを作成します。基本的に、テスト自動化は「ソフトウェア テスト ソフトウェア」です。これにより、コードをテストするためにコードに欠陥がある可能性が生じます。
難しいのは、テスト自動化には非常に明らかな欠陥もあれば、まったく明らかではない欠陥もあるということです。スクリプトの欠陥によりテストの実行が失敗する場合もあれば、スクリプトは正常に実行されても意図したものとは異なる動作をする場合もあります。実際、テストは「合格」する可能性がありますが、その理由は間違っています。
このため、スクリプトの実行を時々視覚的に観察することが必要になることがよくあります。
原則 6 – 自動テストのメンテナンスに時間の大部分が費やされる可能性が高い
テスト自動化メンテナンスの削減または排除は、長年にわたってテスト自動化の聖杯でした。しかし、AI や「自己修復」スクリプトを使用するツールであっても、テスト スクリプトのメンテナンスは依然としてテスト自動化の最大の課題の 1 つです。
「自己修復」スクリプトはロケーターの変更には役立ちますが、テストに関係するプロセスが変更された場合にはあまり役に立ちません。
アプリケーションの変更率を確認し、それらの変更がテスト メンテナンスやテスト自動化メンテナンスの形で直接下流にもたらされることを考慮してください。
これが、テスト スクリプトの自動化が必ずしも良いとは限らない理由です。新しいスクリプトを作成するのと同じくらいの時間を、テスト スクリプトの保守に費やすことになるのは簡単です。
テスト スクリプトのメンテナンスは、テスト スクリプトの小さな一部を変更するだけだと簡単に無視される人もいるかもしれません。ただし、キャリアとしてテスト自動化を検討する場合は、テスト スクリプトのメンテナンスが非常に困難になる場合があることを理解しておく必要があります。
誤解のないように、メンテナンスを容易にするテスト自動化を作成する方法はあります。例としては、データ駆動型テスト、モジュール型テスト、キーワード駆動型テストなどがあります。(図2)
図 2 に示すテストについて考えてみましょう。顧客の追加、顧客情報の変更、将来のある時点での顧客情報の削除の機能を自動化する可能性があるためです。これは基本的に顧客の通常のライフサイクルです。
図 2 – モジュール式で再利用可能なテスト
これらの関数のテストは、1 つの線形テスト スクリプトで簡単に自動化できます。しかし、テストを 3 つの小さなスクリプト (関数ごとに 1 つずつ) に分解したらどうなるでしょうか? これで、ビルディングブロックのようなモジュール構造が完成しました。ドライバー スクリプトは、各モジュール式スクリプトがいつどのように実行されるかを制御します。
顧客を追加する 2 番目のテストを実行し、その顧客を再度追加する場合、新しいスクリプトは必要ありません。新しいドライバー スクリプトを作成するか、テスト #1 用のドライバー スクリプトを拡張して、顧客の追加テストを 2 回実行するだけです。
そして…この考えを他のテスト (テスト #3 など) に持ち込むこともできます。テスト #3 は、テスト #1 やテスト #2 とはまったく異なりますが、新しいテスト スクリプトは必要ありません。
ここで、これが 3 つの小さなテスト スクリプトであると考えてください。このようなスクリプトを 10 個使って何ができるか考えてみましょう。これにより、テストの設計と実装がはるかに迅速かつ簡単になります。
ただし、最大のメリットは、変更が必要なときに、すべてのスクリプトではなく 1 つまたは少数のスクリプトに変更を分離できることです。たとえば、スクリプト 1 を変更する必要がある場合、その 1 つのスクリプトを変更するだけで済みます。「顧客の追加」が関係するすべてのテストを追跡する必要はありません。
テスト自動化への移行を検討する際に、これはテストについてどのように考え始める必要があるかを示す一例にすぎません。もちろん、これはテスト自動化アーキテクチャを正確にどのように実装するかについての組織的な決定ですが、テスト自動化を本当に効果的に行うには、テスト組織の効率性が必要であるという考えは変わりません。
原則 7 – テスト自動化は人に取って代わるものではありません。むしろ、それは彼らを異なる役割にシフトさせます
私たちは、人間が自動化に取って代わられるのではないかという当然の恐怖が存在する時代に生きています。実際、そのようなことはしばらく前から起こっており、今になってさらに明らかになりつつあります。
経営陣が、テスト自動化ツールがテスターのかなりの割合を置き換えることができると考える理由は理解できます。しかし、その見解では少なくとも 2 つの重要なことが抜け落ちています。
- テストの自動化により、時間の経過とともに生産性が向上し、その結果、テスターは自動化できないテストに集中できるようになります。したがって、ツールでテストできないものをテストするには、テスターが依然として必要です。
- 前述したように、テストが適切に自動化されていても、主要なアクティビティは依然として人間によって実行される必要があります。テストの計画と分析は依然として必要です。問題解決は依然として必要です。テスト設計は依然として必要であり、自動化を実行し続ける人も依然として必要です。
原則 #8 – テストの自動化は本質的に確認的なものである
テスト自動化により欠陥が発見されることがありますが、それらの欠陥は主に機能の低下が原因です。退行した機能とは、正しく動作しなくなった機能のことです。回帰テストは、これらの欠陥を見つける方法です。
テストの自動化が検出された欠陥の数によって判断される場合、それは失敗とみなされる可能性があるため、これは理解することが重要な点です。
テストの自動化は、実際には、通常は正常に動作しているが、何らかの理由で失敗し始めた機能の欠陥を見つけるためのセーフティ ネットのようなものです。
テスト自動化に失敗ではなく「合格」がたくさんあったとしても、驚いたりがっかりしたりしないでください。これは正常です。もちろん、テストが基本的すぎるか簡単すぎるかどうかを常に自問する必要があります。
手動テスターから自動テスターへの移行を開始する前に、移行を開始する準備ができているかどうかを確認すると役立ちます。
使用している特定のツールに関係なく、雇用主は多くの場合、特定の言語のスキルを持つ人材を求めており、「ノーコード/ローコード」ツールが使用されると常に想定できるわけではありません。コードベースのスキルを持っている場合は、ノーコード/ローコード ツールを適用するのが非常に簡単です。このような状況の中で、この自己評価が提示されています。コーディングの知識や経験はありますか? もしそうなら、使い慣れているコーディング言語はいくつありますか? コーディングの経験はどれくらいありますか?精神的な挑戦を楽しんでいますか？問題を解決するのは好きですか?細部までこだわる目はありますか？反復可能なパターンで考えることができますか? たとえば、同じ方法で何度も実行できるタスクを特定できますか?手続き的かつ論理的に考えることができますか？例えば、「こうなったらこうしてください。それ以外の場合はそうしてください。」
これらの質問のほとんどに肯定的に答えた場合は、おそらくテスト自動化の作業にうまく取り組むことができるでしょう。現在のコーディングの知識がなくても、適切な属性と思考スキルがあれば、コーディング方法を学ぶことができます。
テスト自動化スキルの簡単なチェックリスト
ここでは、テスト自動化を成功させるために必要なスキルを簡単にまとめます。良いニュースは、適切なトレーニングと練習によって、スキルは時間をかけて学び、完成させることができるということです。
✓ 問題解決スキル – 問題を分解して根本原因を見つけることができますか? 選択肢の中から最適なソリューションを特定できますか?
✓ 論理的思考スキル – 一連の出来事を追跡して論理的な結果を判断できますか?
✓ 分析スキル – 状況を研究してよく理解できますか?
✓ 技術スキル – データベースの操作、テスト環境の構築、シェル スクリプトの操作などができますか?
テスト自動化属性のチェックリスト
属性は、むしろあなたの性格やあなたが誰であるかを表します。これらにある程度取り組むことはできますが、一夜にして改善することはできません。それは、「今は忍耐が必要だ！」という忍耐に関する古いジョークのようなものです。テスト自動化を使用する際によく必要となる属性をいくつか示します。
✓ 粘り強さ – たとえそれが困難であっても、完了するまで何かを続けることができますか?
✓ 細部にこだわる目 – 小さなことに気づきますか?
✓ 忍耐 – 簡単にイライラしない能力はありますか?
✓ 創造性 – 困難な問題に対して創造的な解決策を考案できますか?
テスト自動化に必要なスキルを構築する方法
テスト自動化スキルを構築するための私の一番のアドバイスは、何らかの方法で何かの自動化を始めることです。Selenium IDE は、テスト自動化の学習を始めるための無料かつ簡単な方法です。Selenium IDE は、Chrome および Firefox で動作するブラウザ プラグインです。
次に、一般的なテスト自動化に関する優れた書籍またはオンライン コースを探します。私が一般的なアプローチを提案する理由は、それらが特定のツールや言語に適応できるからです。
私が役に立ったと思った書籍は次のとおりです。Dorothy Graham と Mark Fewster 著の「Experiences of Test Automation」。『現実世界のテスト自動化: テスト自動化のための実践的なレッスン』 Greg Paskal 著(この本は、テスト自動化を始める人に特に役立ちます)。
次に、需要のあるテスト ツールまたは言語に関する特定のコースまたは書籍を見つけます。例としては、Selenium WebDriver や Python 言語などがあります。独自の就職調査を行ったり、社内でどのツールが使用されているかを調べてそこから始めることもできます。
テスト自動化の領域を理解し、コースまたは書籍の演習に取り組んだら、最初の実際のテスト自動化プロジェクトを開始する準備が整います。これは完全にあなた自身の主導によるものかもしれません。あなた自身の経験のためです。
たとえば、テストするオープンソース プロジェクトを選択するとします。モバイル アプリのテストはより困難です。テスト環境にインストールして、選択したツールと対話できるバージョンのアプリが必要になるからです。アプリによっては、開発者が Appium などのツールを使用してモバイル エミュレーターと対話するベータ テスト バージョンを提供する場合があります。
モバイル アプリのテストを見つけて自動化するには余分な労力がかかるため、最初は Web ベースの例に固執することをお勧めします。
あなたの目標は、実際のアプリケーションのテスト自動化における具体的な実践経験を示すことができるようになることです。
テスト自動化スキルは、ソフトウェア QA およびテストの専門家にとって高い需要があります。テスターは、Web アプリケーション、モバイル アプリ、APIのテストに使用できる独自のツールと言語のセットを持っている必要があります。
テスト自動化の学習には、ツールや言語の学習以上のものが含まれることに注意してください。また、テスト自動化を成功させるには、問題解決スキルを開発し、粘り強さ、忍耐力、詳細な方向性などの属性を構築する必要があります。
手動テスターから自動テスターへの移行は簡単ではありませんが、キャリアの生き残りの問題になりつつあり、努力する価値は十分にあります。
PractiTest(プラクティテスト)に関する
お問い合わせ
PractiTest(プラクティテスト)のトライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
※この記事は以下の記事を意訳した記事になります。
引用元：「What is a Test Plan? The Complete Guide for Writing a Software Test Plan」
