ソフトウェアテストの準備と心の準備もできた？
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
テスト分析、テスト設計で
何をテストするか？
どんなテストをするか？
が明らかになったら、
テスト実装で何に対して
どんなテストをするかの準備を整えるよ。
恒例のカタカナ英語を乱発！
• テスト手順を開発して優先度を割り当てる。場合によっては、自動化テストスクリプトを作成する。
• テスト手順や(存在する場合)自動化テストスクリプトからテストスイートを作成する。
• 効率的にテスト実行ができるように、テスト実行スケジュール内でテストスイートを調整する
(5.2.4 節を参照)。
• テスト環境(これには、テストハーネス、サービスの仮想化、シミュレーター、およびその他の インフラストラクチャーアイテムが含まれる)を構築する。また、必要なものすべてが正しくセ ットアップされていることを確認する。
• テストデータを準備し、テスト環境に適切に読み込ませてあることを確認する。
• テストベース、テスト条件、テストケース、テスト手順、テストスイートの間での双方向トレー
サビリティを検証し更新する(1.4.4 節を参照)。
恒例のカタカナ英語で分かりにくくしている、
テスト実装の解説だね？
テスト手順はそのまま、テスト実行の時に
確認する期待結果（期待値）を見るための
手順を明確に書いて、場合によっては
自動化テスト用の実行順序を決めて
スクリプトと呼ばれるプログラムを準備する。
テスト手順や自動化テストのスクリプトを
グループごとに整理してテストスイートと
呼ばれる複数のテストケースやスクリプトを
まとめたものを作る。
テスト環境の準備については
例えば本当に買い物できるECサイトで
テストなんかしたら、実際に使ってる
お客さんに怒られるからテスト用の
ECサイトを用意してもらう。
またはカーナビとか実際に車に載せる前に
テスト用の機械、またはパソコン上で動く
シミュレーターを作ってもらう。
その環境が動くように構築を行う
と言うのが、ここで言う
テスト環境の構築の意味だよ。
次にECサイトであれば、
会員データや商品データをテスト用の
ECサイトに登録したり、
カーナビとかであれば地図や経路が確認できる
設定データを読み込ませたりして、
テストデータの準備と環境への反映をするんだ。
最後に前回のテスト設計でも書いた通り、
何を参照して作ったかを
分かるようにしておくのも重要だよ。
更にテスト分析、テスト設計、テスト実装を
進める内に仕様変更があったり、
今までの資料に記入ミスがあることに気づいたら、
ミスのあった資料だけではなく、
他の資料にも同じ訂正を反映して
資料と資料の間の整合性を取らないと、
何が正しいか分からなくなって
迷子になるからね。
結局、何ができたらええのん？
テスト実行ができるように準備を整えること。
これがテスト実装だよ。
でも、僕が担当したことのある
いくつかのプロジェクトで
呼び方とか範囲が違うことも多かったよ。
テスト分析、テスト設計、テスト実装の内、
テスト手順と期待値をまとめた
テストスイートを作るところまでを
「テスト設計」と呼んでいて、
テスト環境、テストデータの準備は
「テスト準備」と呼んでいる現場もあったよ。
別の現場だと軽めのテスト分析と
テスト設計の作業を合わせて「テスト設計」、
テストスイートを作るのが「テスト実装」、
テスト環境は開発側に用意してもらって、
テストデータは「テスト実行」をしながら、
登録して進めたりすることもあったよ。
こんな感じで、会社やプロジェクトごとに
呼び方が違ったり、同じ呼び方でも
範囲が違ったりするから、
JSTQBの考え方と一致しなくて
困る人も多いんじゃないかと思うね。
改めて振り返ろう、分析、設計、実装
JSTQB的には各テストプロセスを
テスト分析で「何をテストするか？」を検討、
テスト設計で「どんなテストをするか？」を決定、
テスト実装で「テスト実行を可能な状態」にする
と範囲を分けているよ。
JSTQBを受験する良い子のみんなの内、
既にソフトウェアテストの現場で
お仕事してる子も多いと思うんだけど、
実際の現場での呼び方、範囲と
JSTQBが定めている呼び方、範囲を
比較して、その違いをしっかりと
理解しておけば変な引っ掛け問題も
クリアできると信じてるよ。
テスト実装の解説まで進んだことだし、
今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
振り返りはこちら↓
テスト分析1
テスト分析2
テスト設計
この記事が気に入ったらサポートをしてみませんか？