第309回： 「ALTAのテキストをつくろう」62 （テストツールおよび自動化の基礎）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、JSTQBのALTAシラバスの「5. レビュー」（pp. 61-65）の「5.2.1 要件レビュー」、「5.2.2 ユーザーストーリーレビュー」、「5.2.3 チェックリストの調整」について書きました。
チェックリストとチェッキングを混同して、「チェックリストはテスト脳を使わずに、仕様に書かれたことを機械的にチェックするもの」と誤解している人はいませんか？
前回のnoteでは、「チェックリストは、そのひな形をテスト対象に合わせてテーラリングする」話について書きました。誤解が解けていると良いのですが。
チェックリストはテストのためのツールになります。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの新章（実質的に最終章）の「6. テストツールおよび自動化」に移り、「6.1 イントロダクション」と「6.2 キーワード駆動テスト（のイントロ）」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢2の「チェックリストは単独で使用する（組み合わせない）」が66.7%と最も多く、正解も2です。
1の「標準チェックリストはテーラリングしてから使用する」を分かっていることを確認したくて作った問題なので、1を選んだ人がいなくて大満足な結果でした。
他の選択肢は、どれもシラバスに書いてあるものですが、その中から、私が意外だなと思ったものを選択肢としました。
まず、正解の「チェックリストは単独で使用する」ですが、私はチェックリストを組み合わせて使ったことがありません。どうやって組み合わせるのか今でもイメージできません。
チェックリストを組み合わせた実物を見たいです。
次に「ユーザーストーリーのレビューでは詳細なユーザーインターフェースチェックリストも使用する」ことをシラバスでは推奨しているのですが、レビューのときにそこまでチェックすることができるかなあ？と思ったので選択肢にしました。
4番目の「要件の出どころをチェックする」は、むしろ「要件の出どころは隠せ」と教わってきたので、なんでー？って思いました。
私が教わった「要件の出どころは隠せ」の趣旨は、「たとえば要件の出どころが大企業の社長だったら変なバイアスがかかって技術的な判断が曇る懸念があるから」という理由でした。
実際に新商品の企画を立てるときに、顧客要求ヒアリング結果表なるものを作るのですが、レビューで配布するものからは要求の出どころの列を削除していました。
前職の特殊性からかな。
要求の出所を知ることは要求内容の理解を深める助けになるからそういう意味なのだと思います。
復習は以上として、今回のnoteのテーマに移ります。
≡ テストツールおよび自動化のイントロダクション
シラバスの記載が短いので、全文を引用します。
テストツールを使用すると、テストの効率性と正確性を大幅に改善できる。本章では、テストアナリストが使用するテストツールと自動化手法について説明する。テストアナリストは、開発者、テスト自動化エンジニア、およびテクニカルテストアナリストと連携してテスト自動化ソリューションを構築する点に気を付けるべきである。キーワード駆動自動化では特に、テストアナリストの貢献度が高く、ビジネスおよびシステム機能性に関する経験が活かされる。
テスト自動化とテスト自動化エンジニアの役割に関する詳細については、ISTQB® Advanced Level Test Automation Engineerシラバス[ISTQB_TAE_SYL]を参照されたい。
抑えるポイントは太字にした部分を含む「テストツールを使用すると、テストの効率性と正確性を大幅に改善できる。」です。
ISTQBのシラバスの対応個所をみてみましょう。
Test tools can greatly improve the efficiency and accuracy of testing.
私が原文で確認したかったのは「テスト」の個所です。原文では、「testing」でした。つまり「テストの効率性と正確性を大幅に改善できる。」をingを強調して書けば、「テスト作業の効率性と正確性を大幅に改善できる。」となります。
「テストとテスティングの違いは、プログラムとプログラミングの違いだよ。 by 湯本さん」と前に教わりました。
ということで、本章はいわゆる「テストの自動化」が中心となります。
次回のnoteのテーマのひとつである「テストツールの種類」では、「テスト設計ツール」と「テストデータ準備ツール」と「テスト自動実行ツール」の説明があります。
ただし、テスト自動化とかテスト自動化エンジニアといった場合、テスト実行の自動化を指すことが多いことは抑えておきましょう。
言い換えれば、「テスト自動化エンジニア」という専門家が必要なほど、テストの自動実行は深いテーマということです。
「Advanced Level Specialist シラバス テスト自動化エンジニア」も読んでおくと良いでしょう。
（このシラバスはFLではなく、ALであることに注意が必要です）
テスト自動化エンジニアは、「自動テストケースの実装」、「自動テスト実行の監視および制御」、「自動テスト結果の解釈、報告、記録」を行います。
≡ キーワード駆動テストのイントロダクション
ALTAシラバスには、いきなり「キーワード駆動テスト」の話が出てきます。
そんなに有名でしょうか？ また、みなさん使っています？？
ということで、今回はシラバスからちょっと離れて基礎的な話を書きます。
テストの自動化ですが、歴史的には「テストケースを作ってから、それを自動テストスクリプトに変換して自動実行する」というアプローチから始まりました。
こう書くと「当たり前じゃん。それ以外あるの？」と言われそうです。
今は、「テストケースを作る前にどういうテストをしようか」と考えて、「この辺は手動な、この辺は自動な」と先に決めてから、「手動テストスクリプト」と「自動テストスクリプト」を作っています。
「テストケースを作ってから、それを自動テストスクリプトに変換して自動実行する」話に戻ります。
■ キャプチャ/プレイバックアプローチ
最初は、「テストケースを作ってから、そのテストケースを手動で動かしながらGUI情報を記録して、記録した情報をツールが自動テストスクリプトに変換して、手動実行したテストを再現する」という方法でした。これを「キャプチャ/プレイバックアプローチ」と呼びます。
テストを実行するときの操作を取得（キャプチャ）して、それを再現（プレイバック）する戦略（アプローチ）という意味です。
「キャプチャ/プレイバックアプローチ」は、自動化ツールのデモ映えがします。
ツールを紹介する人が、キャプチャしながら手動でテストをした後に「今、実施したテストを手を触れずに実行します」と▶️ボタンを押すと、マウスカーソルが勝手に動いて、テキストボックスに文字列が勝手に入って、ボタンを勝手に押して結果が出てくる、、、「おお、これで面倒なテスト作業は不要になるのか」と偉い人は勘違いして大喜びします。
■ データ駆動アプローチ
本当は、「構造化スクリプティングアプローチ」の話を間に入れる方が技術的には良いのですが、自動化ツールのユーザーとして大きな変化（パラダイムシフト）が起きたなと思ったのは、「キャプチャ/プレイバックアプローチ」から「データ駆動アプローチ」への変化でした。
「キャプチャ/プレイバックアプローチ」では手動実施したテストしか自動実行できないので、よく考えると「手動実行した時点でテストは終わっているので、リグレッションテスト（や再テスト）でしか役に立たない」という問題がありました。
そういったことまでは、「キャプチャ/プレイバックアプローチ」のツールデモで気が付くわけはありません。
自動化ツールを導入したあとに「アッ、そうだよね」と気が付いて、ツールベンダーの人に相談すると「データ駆動にしましょう」と言われる類のものです。
「データ駆動アプローチ」とは、【（入出力する）データ】と【テスト自動実行スクリプト】を切り離しましょうというアプローチです。
自動実行スクリプトはスクリプト内で使用する入力データを別のファイル（たとえばCSVファイル）から読み込んで使い、その入力に対する期待結果も同様に読み込んだファイル内のものを使います。
このアプローチが最高に役立つのは、組合せテストです。直交表（やペアワイズで生成した表）の1行を読み取って、各値を入出力データとして実行することで「1行分の【テスト自動実行スクリプト】を作っておけば、何千行の組み合わせテストを自動実行できる」からです。
ここで、勘の良いテストエンジニアは入力は良いけど、「期待結果はどうするの？」と思われたかもしれません。
実は「組み合わせテストは【無則の組合せ】のテスト」であるため「期待結果と入力は同じ」です。
たとえば、自動化のデモでよくあった「航空券の発券システム」で考えてみると「出発空港」（NRT、HNL、SFO、LHR、ZRH）、「到着空港」（NRT、HNL、SFO、LHR、ZRH）の組合せのテストで「NRT×SFO」の組合せテストを実行をしたときのチケットについての期待結果は「出発空港」がNRTで、「到着空港」がSFOです。入力と期待結果が同じというのはこういうことです。
これが、デシジョンテーブルテストのような有則のテストの場合は期待結果をつくるオラクルを（例えばExcelなどで）別途用意する必要があります。
■ キーワード駆動アプローチ
データ駆動アプローチを更に進め、アクションをキーワードとして呼び出してテストの操作の流れ自体を書けるようにしたものです。
（データ駆動では操作の流れは1つでした）
詳しくは次回に。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
6.1 イントロダクション
学習の目的はなし
6.2 キーワード駆動自動化
TA-6.2.1 （K3）特定のシナリオで、キーワード駆動テストプロジェクトでのテストアナリストの適切な活動を判断する 。
（K2：理解、K3：適用、K4：分析）
《問題》
ALTAシラバスに「テストツールを使用すると、テストの○○性と△△性を大幅に改善できる。」とあります。「○○と△△」を選びなさい。
1. 効率性と正確性
2. 機能性と信頼性
3. 保守性と移植性
4. 使用性と真正性
答えは次回に書きます。
≡ おわりに
今回は、「6. テストツールおよび自動化」に移り、「6.1 イントロダクション」と「6.2 キーワード駆動テスト（のイントロ）」がテーマでした。
正直に言って、この章だけでは、テスト自動化エンジニアにはなれません。ALTAの範囲としては全体的な知識と若干の経験があればOKということだと思います。
ということで、テスト自動化エンジニアを目指す人は、「Advanced Level Specialist シラバス テスト自動化エンジニア」も読みましょう。また、読むだけでは不十分で、実践することが大事です。
さて、次回は「6. テストツールおよび自動化」の「6.2 キーワード駆動テスト」の残りと「6.3 テストツールの種類」について書きます。
