あんた、そこにバグはあるんか？〜テスト実行
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
過去の
「もっと知ってほしいソフトウェアテストのあれこれ」
で書いたけど多くの人が
ソフトウェアテストのお仕事＝テスト実行
と言うイメージをしてると思うんだ。
でも、テスト実行はソフトウェアテストの
活動の一部と言うことは、
既にお伝えした通りだね？
今回は昨日まで解説してきた、
テスト分析、設計、実装で作った資料を元に
ソフトウェアの動作が正しいかどうか？
を確認をする作業、テスト実行のお話だよ。
あんた、そこにバグはあるんか？
端的に言うと
「製品やシステムを動かして
欠陥（バグ）がないか？」
を調べていく作業になるよ。
もう少し具体的に書くと
テスト実装で用意した資料に書いた
条件、手順通りにソフトウェアを動かして、
期待値通りに動くかどうか？
を確認していくんだ。
テスト実装で用意した資料で
条件、手順、期待値を書いたテストケース、
いくつかあるテストケースを機能や
関係する組み合わせごとにまとめた
テストスイートと呼ぶので覚えおいてね。
記憶じゃなくて記録
当然、お仕事なので期待値通りに動いた場合に
「ふむふむ、テストケース通りだね」
期待値通りに動かない、JSTQB的に言えば
故障が見つかった場合も
「おやおや、バグっちまったよ」
と一人で納得しても意味ないよね？
テストスイート、テストケースごとで
事前に決められた各種情報を
記録していく必要があるよ。
テストした対象のバージョン情報や、
使用したツールや環境、
期待値通りか故障、欠陥があったのか？
の判定も必要になるし、
誰がいつ実施したのかも残すべきだね。
• テストアイテムまたはテスト対象、テストツール、テストウェアの ID とバージョンを記録す る。
• テスト実行の結果(合格、不合格、ブロックなど)を記録する。
故障？それともエラー？
ソフトウェアの動きがテストケースの
期待値と違ったからと言って
某明治剣客浪漫譚の斎藤さんの信念である
「悪・即・斬」みたいに
「バグ・即・報告」
と言うわけにいかないんだよ。
テスト分析、設計、実装も人が作った物だから、
期待値が間違っていることもあるし、
テスト実行をした人が手順を間違えていて、
誤った手順だから期待値も違う
と言う場合もあるよね？
更に手順も期待値も間違いないけど、
期待値通りに動かないけど、
これも故障ではない場合があるから厄介だね。
例えばテスト分析、設計、実装の間、
またはテスト実行の途中で
仕様変更されてしまった場合に
手順や期待値も変わってしまうこともあるんだ。
期待値通りじゃなかったら、
まずは条件や手順をミスしていないか？
をチェックする。
次に開発側の仕様書や設計書とテストケースを
比較してテストケースが間違っていないか？
仕様変更により条件や手順が変わっていないか？
をチェックする。
これで条件も手順も期待値も間違いなければ、
故障と判断して欠陥があることを報告するんだ。
目に見えて明らかな欠陥（バグ）であれば、
「バグ・即・報告」でいいんだけど、
JSTQBでは人の間違いと言うのを
エラーと定めているから、
ソフトウェアの故障なのか？
テスト側のエラーなのか？
を見極めることも必要ってことだね。
テスト側のエラーだった場合は、
どこが間違いなのかを特定して
正しい条件、手順でやり直しをするよ。
その場合、間違っていた内容を記録して、
同じエラーが起きないよう対策しておこうね。
•手動で、またはテスト実行ツールを使用してテストを実行する。
• 実行結果と期待結果を比較する。
• 不正を分析して、可能性のある原因を特定する(故障はコード内の欠陥によって発生する可能性 があるが、偽陽性が発生することもある(1.2.3 節を参照))。
• 故障を観察し、観察に基づいて欠陥を報告する(5.6 節を参照)。
タスクがなくなるまで繰り返し
テストスイートにある全ての
テストケースをチェックし終わるまで、
動作確認、期待値の判定、記録、
欠陥の特定、報告を繰り返していくよ。
この流れの中で欠陥が修正されたら、
再テストも行って故障が
起こらなくなっていることの
確認もしていく必要があるよ。
このいくつかある作業を
全て完了させたら、終わりと言う訳でもなく、
プロジェクトごとやテストの計画時点で
決めていた目標を達成したかどうかを
チェックして、直ってない欠陥が多かったり、
逆に思ったよりも欠陥の数が少ない場合に
再テストや追加のテストを考えたりするんだ。
その辺の基準とか考え方は
また別の機会に紹介することにするね。
まだまだあるよテストプロセス
テスト分析、テスト設計、テスト実装、
そして、テスト実行と言うテストプロセスを
紹介してきたよ。
実はここまで紹介した活動って、
実際に手を動かして作業する担当者の
活動をメインとしたお話だったんだ。
この活動が上手く進むかどうか？
進んでない場合はどうするのか？
テスト実行の細々したタスクは全て
消化したけど終わっていいの？
と言うのを考えたり対策するお仕事。
テスト計画、モニタリングとコントロール、
最後にテスト報告と言う管理側の
テストプロセスがあるんだね。
本来の順番から言えばテスト計画から
説明していくんだけど、
実際の現場でもテスト分析からテスト実行までの
お仕事内容を知らない内から
「テスト計画立ててね」
と割り振ったりしないよね？
（稀にそんな無茶振りする人もいるんだろうけど）
だから、テストプロセスの中でも、
管理側じゃない個別の作業の内容から
知ってもらいたかったんだ。
良い子のみんなもどんな流れで
テスト実行まで持っていくのかを理解できたかな？
今後の投稿でテスト計画、
テストモニタリングとコントロール、
テスト報告についても書いていくから、
安心して待っててね。
では、今回はこの辺で！
次回はみんなが愛してやまないAIをテーマに
書いてみようと思うよ。
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？