第251回： 「ALTAのテキストをつくろう」14 （テスト実装 前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト設計のプロセス」の「テストケースの設計」の後編として、「テスト設計の注意事項」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.5 テスト実装」のうちの前半（シラバスでは21ページあたりの「テスト実装とは何か？」）について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、4が70.9%と最も多く、正解も4です。正答率が高かったので、解説は軽めとなります。
2の「静的テスト結果を使用して期待結果を生成する」が不正解な理由は“シラバスのどこにも書いていないから”です。
実務において、仕様書のレビュー（＝静的テスト）のときに確認した（仕様書に書かれていない）動作について動的テストのときに確認することはよく行われています。
レビュー指摘対応漏れは、何度も経験しています。
具体的には、仕様書のレビュー議事録をもとに、“レビューした結果としてみんなで合意した仕様”についてのテストケースをつくります。
気が利いたチームなら、テストベースは、レビュー議事録ではなく、レビュー記録表もしくはそれを蓄積したチケットシステムかもしれません。
逆に、「ホワイトボードを写した写真が添付されたメール（いわゆる議事メモ）」がテストベースとなることもあります。
やりやすく漏れにくい方法でしたら、なんでもよいのですが、メモ類はトレーサビリティが取りにくいので一箇所にまとめておくことをお勧めします。
この場合、まさに「静的テスト結果を使用して期待結果を生成する」をしています。ですから「静的テスト結果を使用して期待結果を生成することがある」という文なら選択肢2も正解です。
しかし、いつもそうするわけではないので不正解とします。
選択肢4の「テスト設計は良いレビューとなる」は代表的な「パースペクティブレビュー」方法の一つです。
ALTAでは、レビューのテクニックとして、基本的な「チェックリストベースドレビュー」を中心に説明しています。「パースペクティブレビュー」はALTAシラバスには出てこないようです。
以上で復習は終わりです。
≡ テスト実装
今回は、「テスト実装」がテーマです。まずは、ISTQBの「テスト実装」について理解しましょう。
以下は、ISTQB用語集の検索結果です。
用語集に「テスト分析と設計に基づいてテスト実行に必要な」と書いてあります。
ここから、＜テスト分析＞ → ＜テスト設計＞ → ＜テスト実装＞ → ＜テスト実行＞の順番であることがわかります。
次に後半の「テスト実行に必要なテストウェアを準備する活動」から、テスト実装の役割が「テストウェアを準備すること」であるとわかります。
「テストウェア」って何だっけ？って思ったら用語集で確認します。
私は何だっけ？って思ったので確認しました。
えっ？ これを全部用意するのがテスト実装じゃないよね？？ ということでシラバスを読んでみます。
テスト実装では、テスト分析と設計に基づいてテスト実行に必要なテストウェアの準備をする。次の活動を含む。
すべてのテストウェアではなく「テスト実行に必要なテストウェア」ね。よかった良かった。
シラバスには、「テスト実行に必要なテストウェア」の説明が続きます。説明は「活動（タスクレベル）」（何を行うか）を書いてあり、長いものです。
そこで「各活動」から、「（そのタスクの）成果物」をピックアップしたものが以下のリストです。
テスト手順、場合によっては自動テストスクリプト
テストケースとテストスイートの優先度
テスト実行スケジュール（リソースの割り当てを含む）
テストデータおよびテスト環境
テストウェアとの間のトレーサビリティ（更新）
「テスト手順と優先度を明確にして、テストデータとテスト環境を実際につくって、トレーサビリティを更新する」というのがテスト実装とのことです。
簡単に書けば、「テスト実行を開始できるように準備を完了することの全て」が「テスト実装」です。
キャッチイメージ（下記に再掲）は、テスト実装を「テストの作成」と「実行準備」に分けたものです。
私はこんなふうにキーワードで理解することが多いです。
テスト実装の理解で間違えやすいのは「テスト実装は、テストケースからテスト手順つくることだけ」という誤解です。
また、さらに誤解しやすいのは、1でいう「テスト手順」についてです。以下、テスト手順について説明します。
2回前のキャッチイメージを再掲します。
私は長らく、上の図にある「テストステップ」と「テスト手順」を同じものと誤解していました。
つまり、テスト設計では上の図の「テストケース」（目的、事前条件、テストステップのうち入力と期待結果、事後条件）をつくり、テスト実装でテストステップに「アクション」を追加すると思いこんで（誤解して）いたのです。
そうではなく、テスト設計では必要に応じて「アクション」つまり「操作手順」までつくります。（操作手順を書かなくてもわかるならアクションは書きません。）
そして、テスト実装ではテスト実行を考慮しながら、テストケースの並び替えを行いテスト手順をつくります。
この「テストケースを並び替えてテストプロシジャー（テストプロシジャーは実行順序のことで、テスト手順と同義語です）をつくり、最終的にはテストケースをまとめたテストケーススイート（＝ テストスイート/テストセット）をつくる」ことを「テスト手順の作成」と言います。シラバスの該当部分を引用します。
テストアナリストはテスト実装時に、テストケースの効率的な実行順序を特定し、テスト手順を作成する。テスト手順を定義する際には、テスト実行の順序に影響を与える可能性のある制約や依存関係を入念に識別することが求められる。テスト手順では、すべての初期事前条件（データリポジトリからのテストデータのロードなど）およびすべての実行後活動（システムステータスのリセットなど）を記述する。
「テスト手順」を用語集で検索した結果を貼っておきます。
≡ JSTQB ALTA試験対策
いつものことですが、まず、テスト設計の「学習の目的」を確認します。
1.5 テスト実装
TA-1.5.1 （K2）テスト実装の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。
今回の範囲（1.5）については、K2なので、「理解」です。テスト実装時のテストアナリストのタスクについて理解していれば良いということです。
《問題》
テスト実装について、以下の選択肢から正しいものを選びなさい 。
1.テスト実行時の操作手順をテストケースに追加する
2.テストデータやテスト環境の要件を明確にする
3.テストケースの優先度についてテストマネージャーに相談する
4. トレーサビリティについては変更しない
答えは次回に書きます。
≡ おわりに
今回は、「テスト実装とは何か？」がテーマでした。
組織内で概念の統一が行われていることが大事です。
ところで、様々なテストの概念を組織でまとめるのはひと仕事です。海外のパートナー企業があれば、まとめたものを翻訳する必要もあります。
そこで、「明記していない部分はISTQBに準拠します」とか「私たちのテストプロセスは、ISO/IEC/IEEE 29119の定義にしたがいます」というように、参照する標準を決めておくと楽ができます。
きちんと理解できたかどうかはJSTQBの試験の合否である程度わかりますし、ISTQBであれば、全世界の言語に翻訳されたものが公開されています。こちらを使わないともったいないと思います。
さて、今回も、ALTAテキストの追記はありません。すみません。
1章が終わったタイミングでまとめてつくります。
次回は「1.5 テスト実装」の後半です。「テスト実装のコツ」について書きたいと思っています。
《余談》
今回は、気力が戻っていないので、お休みしちゃおうかなって思ったのですが、『そんなことされてもうれしくないぞ』って叱られそうなので書きました。
この記事が気に入ったらサポートをしてみませんか？