【DAY009】ソフトウェアテストについて①【テストの必要性】
■ はじめに
以前ソフトウェアテストの基礎講座を受講したので、自分用にまとめ直した。
テスト工程について6回に分けて取り上げて行く予定。
全体の流れ
- テストの必要性(本記事)
- テストの基本的なプロセス
- テストレベルとテストタイプ
- テスト技法
- テスト計画
- テスト設計
詳細に書いていく予定なので、些細なツッコミ等ありましたらどしどしお願いいたします。
書き手の情報
一応明記しておきます。
■ テストの必要性
★テストの目的
そもそも、なぜテストが必要なのか？
確認することが当然だから？テストを行うことが開発の工程の一つだから？
それら間違ってはいないが、はたして、これが明確な「テストの目的」なのか？自信をもってテストの目的を言える人はそう多くはないのが実情だそうだ。
目的もわからずにテストをするとなると、やる気も方向性も分散してイマイチな結果になりがち。(現にテストはよく眠くなる。)
ではテストを行う目的とはなにか。
それはズバリ「要件や仕様を満たして正しく動作するか確認する」こと。
あたりまえじゃないかーい。って？
そう、当たり前のこと。でもその当たり前のことを「目的」として言語化しておくのは大事なのだ。
そうでないと、テストを作る際にイレギュラーのイレギュラーなど考え始めてしまい、一向に終わらないテストになる。
あくまで、「要件」と「仕様」を満たし、「正しく動く」を確認することが大事なのだ。
★テストの必要性
テストの目的を果たす必要性とはなにか。
なぜ、正しく動作することを確認する必要があるのか？正しく作ったんだから、動くじゃん！とテストを省略したくなる気持ちは、まま、ある。
しかし、テストする対象物を作っているのは「人間」である。
さらに「複数」の人々が、コミュニケーションを取りながら、「一つ」のモノを作り上げるのだ。
さて、そのような場合、問題になるのは「ヒューマンエラー」である。
悲しいかな、人間はちょっとした聞き間違いや言い間違い、そして勘違いが多い生き物なのだ。
以下３つを取り上げて考えてみる。
- 要件定義書の書き方 ①
- 設計書の書き方 ②
- 設計書からコーディング ③
①話し合いの結果、要件定義をまとめて書く。（聞き間違い、解釈違いがある可能性）
②要件定義から、設計書を起こす。（読み取り間違い、認識違いの可能性）
③設計書からコードに起こす。（読み取り間違い、認識違いの可能性）
人の噂に尾ひれがつくのと似ていて、伝聞、伝達にはミスが生じやすい。
また、人が作業する内容には、介した人数分の解釈や判断が入るもの。
結果として、話し合いで決められた要件と、コーディング(実装)が異なるものになる可能性があるというわけだ。
設計書通りに作ったと思ったら、うっかり実装し忘れた機能だったり、対象が違っていたりなど、少なからずエンジニアの方々は経験していると思う。
そういうことです。
どのタイミングで気付くかはその時々であろうが、およそほとんどの場合何かしらの「エラー」が潜り込んでいるものだ。
だからこそ、
リリース前にその「エラー」を見つけるため、テストは必要なのだ。
「要件の通り当たり前に動くことを確かめる」とは、そういうことです。
もし、テストをせずにエラーを残したままリリースしたらどうなるか？
それは、故障となる。
誤字脱字といった単純な「バグ」だったり、環境の設定が違ったり、原因は多岐にわたる。
しかし、要件や仕様を満たして、正常に動作することを確認するテストをきちんと行っていれば、少なくとも「要件通りの動作保証」はされるということになるのだ。
以上、テストは省略すべきではない。必要な子という説明でした(๑•̀ω•́๑)b
※3月ごろに書いていた記事を微修正しました
