一問一答の一歩

プログラムの試験はITに携わる会社に入った場合、プログラムに慣れる目的で高い確率で最初にやることになる。

そのため、参考までにプログラムの試験の仕事の手順について情報共有を行う。

1-1試験の工程を確認する

プロジェクトの全体像として、大まかな流れを述べると下記のようになっている

上記のように試験にも複数の工程があり、それぞれ目的が異なっている。そのため、試験工程ごとに下記の設計書を基に作成される事が多い。なお、カッコ内のアルファベットは工程でよく使用される略語である。

• ・単体試験(UT)……一つ一つの機能がちゃんと動くかを確認
• →詳細設計書(内部設計書)を参考
• ・結合試験(IT)……プログラムの合体によって、デ一タのやりとりがおかしくなっていないことの確認
• →基本設計書を参考
• ・総合試験(PT)……本番と同じ状況にして、ユーザーの希望通りに動くことの再確認
• →要件定義書を参考

※プロジェクトによっては以前の試験仕様書を基にして作成する……という状況もあるので、その点は臨機応変に合わせること

※また、裏を返すと､試験で分からないことがあったら基となる設計書から調べていくと良い。

1-2 試験の内容に応じて分類する

試験するべき内容をピックアップできれば試験仕様書の作成は終了とはなるが、大きなプロジェクトとなると、試験の量も膨大になるので下記の内容に応じて分類することが多い。

なお、私が見たことのある分類は下記の通りである。

• ・機能試験……プログラムの目的通りに動くことの確認
• ・リグレッション試験(回帰テスト)……改造により、関係しない箇所が壊れていないことの確認
• ・性能試験……機械の処理時間が遅すぎないことの確認
• ・負荷試験……大量のデ一タの使用によって落ちないことの確認
• ・意地悪試験(異常系)……本来起こりえないことが起こった時にも機械が上手く対応してくれることの確認、基本実施に時間がかかる

試験をする際には、試験項目を見ながら試験を行うため、試験仕様書に以下の変更を加えた上で別ファイルとして保存する。

• ・合否や試験月日の記入欄を作成する。
• ・ファイル名の「仕様書」の文言を「成績書」に変更する

プログラムの試験の分類方法はたくさんあるが、私が行うことの多い試験は以下の通りである。

3-1静的試験(プログラムを動かさない試験)

• コ－ド解析

→必要な内容が不足していないこと、コンパイルエラーをおこす文法誤りがないことをコ－ドを見て確認する

3-2動的試験(プログラムを動かす試験)

• 3-2-1：指定した画面表示になっていることを確認する試験
• →試験内容に記載された操作を行い、画像キャプチャをする

• 3-2-2：デバッガーを用いて、指定したタイミングで変数の値が正しいことを確認する試験
• →正しい変数の値を出力出来たら画面キャプチャ又はログファイルをエビデンスとして残す

• 3-2-3：指定した操作を実行後、データベース内のデータが正しくなっていることを確認する試験。
• →データベースソフトを使用してデータを確認し、確認した画面をキャプチャするなりエクセルに貼り付けるなりしてエビデンスにとる

• 3-2-4他の機器と通信して電文となるテキストファイルを送り、帰ってきた電文が適切なものであることを確認する試験

試験合格とある根拠となる画像ファイルや出力されたファイルをエビデンス(証拠)として保存する

※この時、試験番号をつけるなどどの試験の証拠であるのかを一目で分かるようにしておくこと

試験内容の対応する部分に合否の日にち、合否の結果、試験実施者を記載する。

また、試験をしていて普段と変わった挙動やデータの関係で特殊条件で試験を実施した場合には備考欄に記載する。

※合格であることは確認できたけどエビデンスの採取を取り忘れた、又はエビデンスに不備があった当、試験実施日とエビデンス採取日が異なっている場合はどちらをかくべきかはケースバイケースなので、上司に確認する。

以下、3〜5の工程を繰り返す。

テストが一区切りつくところまで終わったら、先程行っていた作業で、試験を何件実施したかを記載する。また、試験の結果が合格でないものがあった場合は、その試験項目についてチェックし、複数人数でプログラム作成をしている場合は報告を行う。

試験お結果がファンクション、つまりプログラムの問題であるである場合、管理職の人から〇〇の試験についてのトラブルシートを発行してくださいとの連絡が入るはずなので、トラブルシートのファイルを作成する。(すでに雛形がある場合にはコピーして中身を書き換えてもよい。)

トラブルシートには問題点の概要とトラブルの具体的な状態を記載する。

問題ページに戻る