無事実装を終え、ほっと一息、、
つく暇もなく、テストフェーズに移ります。
スピードを意識するあまり、テストがおろそかになってしまい、リリース後に問題発覚。。
なんてこと経験した事ある方は中にはいらっしゃると思います。
実装終えたら開発も終盤だな、と思っている方。
大間違いです！！
さぁ、テストを分解していきましょう。
目次
第1章 要件定義
第2章 設計
第3章 開発（実装）
第4章 テスト・検証 ←今回はココ！
第5章 リリース
第6章 運用
なぜ「テスト」が必要か
そもそもテストの目的とはなんでしょうか？
今一度考え直してみてください。
バグを潰すこと
だと思っていませんか？
それは目的ではなく、手段です。
第1章〜第3章の各フェーズの目的は何だったでしょうか？
そうです！
依頼者（発注者）にとって本当に価値のある成果物を提供すること
です。
テストフェーズを終えると次はもうリリースに入ります。
つまり、このテストフェーズはある意味最後の砦になるわけです。
この最後の砦をくぐり抜けてしまったバグは世の中にリリースされていきます。
もしそのバグが致命的なものであったら。。。
ゾッとしますよね。
この最後の砦意識がテストフェーズでは重要です。
そしてこの最後の砦意識を支える、テストに対する考え方を紹介します。
テストにおいて、正しい操作で正しく動作するのを確認する事だけでは不十分です。
サービスとして正しい操作で正しく動作する事は当たり前です。
ユーザーの想定外の操作方法、不正なデータの入力などのイレギュラーな状況でシステムがどのように動作するのかを検証することがテストの本質です。
余談ですが、僕の会社にいるテストエンジニアの方も「デバッグではまずそのサービスを壊しにかかる」と言っていました。
つまり、ただの作業と捉えずに目的を念頭においてテストしていきましょう！ということです。
どこまでテストすれば良いんだ！？
そうは言っても、全てのバグをリリース前に潰し切ることは至難の技です。
そもそも開発プロセス全体の開発工数の中でテストが占める割合は7割以上と言われています。
半分以上テストなんです！！
どこまでテストしてバグを潰し、どの時点でリリースするのか。
難しい問題だと思います。
答えは、、、
ありません。
正確には千差万別で色々な答えがあります。
例えば、全くテスト文化がない会社に対していかにテストが大事かを説いても、すぐには対応出来ないこともあると思います。
どこまでやるかは自分たちで決めることだと思います。
例えば
オレ流「身の丈」開発プロセス
こちらの方のように、テスト範囲をぐっと絞って実施することも大事だと思います。
大事なことは目的に照らし合わせた時に自分たちがどこまで出来るか、どこまでやるべきかを定義することだと思います。
間違っても、時間がないからとりあえずリリースしちゃえ、ということはないようにしたいですね。。
どんなテストがあるの？？
実際にどのようなテストがあるのか見ていきましょう。
以下のサイトを参考にさせて頂きました。
3つのテスト設計技法
大きく分けて以下の3種類のテストに分かれます。
・仕様ベースのテスト
・構造ベースのテスト
・経験ベースのテスト
それぞれどういったものか見ていきます。
仕様ベースのテスト
仕様ベースのテストはブラックボックステストと呼ばれています。
システムの中身の処理は見ずに、インプットとアウトプットの値だけを見て仕様を満たしているかを検証するテストです。
主に複数のプログラムが組み合わさった、機能テストやシステムテストで使われます。
要するにAを入力したらBが返ってくる、といった仕様が正しいかどうかを評価します。
ブラックボックステストのポイントは2点あります。
1点目は正常な値とエラーが期待される値を入力してテストすること。
2点目は境界となる値付近をテストすること。
例えば
0〜50を入力されたらOK
51〜100を入力されたらNG
を出すシステムを作ったとします。
まず正常な値である20や３６、60や８３を入力してOK、NGが出るか確認します。
次に-10や150などのエラーが期待される値を入力した時にきちんとエラーが出るかを確認します。
そして、境界値0、50、100付近の-1、0、1、49、50、５１、99、100,101をテストする、ということです。
正常系、異常系、ギリギリを攻めた時の挙動を検証するということですね！
構造ベースのテスト
構造ベースのテストはホワイトボックステストと呼ばれています。
構造ベースのテストは内部構造を理解した上で、ロジックや制御の流れが正しいかどうかを検証するテストです。
ホワイトボックステストにはプログラミングに関する知識が不可欠で、主にクラスや関数を見る単体テストで使われることが多いテスト技法です。
ブラックボックステストとは違い、処理を一つ一つ細かくテストしていくため、イメージでいうと工場のベルトコンベアの流れ作業に似ています。
部品一つ一つをチェックして正しいかどうかを検証していきます。
経験ベースのテスト
経験ベースのテストにはブラックボックステストやホワイトボックステストのようなキャッチーな名前はついていません！
テスト担当者が持つスキルや経験と、ユーザーの利用実態に関する情報などを元にテストケースを作っていくというのが、経験ベースのテストです。
属人性が高く、限られた会社、環境でしか出来ないテスト技法ですが、これまでに上がってきたインシデントや類似した欠陥の情報などの知見を生かして効率的で質の高いテストが出来ます。
参考サイトのこちらの画像が分かりやすかったので転載させて頂きます。
（引用：https://webrage.jp/techblog/three_types_of_test_design_techniques/）
そうはいってもテストって大変なんでしょう...？
と思っている方。
テストの負担を軽くするために様々なツールやフレームワークが開発されています！
・ユニットテスト用フレームワーク
xUnit
今の時代は言語ごとにユニットテスト用のフレームワークが用意されているんです！
便利な時代になりましたね！
有名どころでいうと、JUnit（Java用のユニットテストフレームワーク）、PHPUnit（PHP用のユニットテストフレームワーク）があります。
PHPUnitに関しては過去にチュートリアルを試した記事があるのでそちらも合わせてどうぞ！
No.2 新卒未経験エンジニアがComposerでPHPUnitをインストールしてユニットテストを試してみた〜PHPUnitインストール編〜
No.3 新卒未経験エンジニアがComposerでPHPUnitをインストールしてユニットテストを試してみた〜ユニットテスト実践編〜
ぜひそういったツールを活用してテストを導入してみてください！
・テスト自動化ツール
使ったことはないのですが、テストを自動化するツールもあります。
（使ったことないので記事紹介だけ。。）
おすすめテスト自動化ツール4選
Jenkinsなんかは有名ですね！
使ってみたらまた記事書きます！
まとめ
テスト技法、テストツールと紹介してきましたが、今回の記事の一番のテーマは
テストは最後の砦
だと思います。
まだテスト文化がない会社の方はいきなり大掛かりなテストを導入するのは大変だと思うので小さなことから始めていくのが良いと思います。
例えばコードレビューなんかは身近ですが、立派なテストの一種だと思います。
ユニットテストなんかは簡単に導入出来るので自分がまずは率先して使ってみるのも良いと思います。
せっかく良いサービス、システムを世の中に出していくのだから評価されないと面白くないですよね！！
積極的にテストして、テストを好きになりましょう！！
新卒未経験エンジニアの「テスト」経験談
エンジニア道を歩き始めて1ヶ月。
必死の思いで開発した社内ツールのリリース3日前。
テストエンジニアの方にお願いしてデバッグしてもらうと大量のバグが。。。
泣きそうになりながら一つ一つ対応していきましたが、PHPとMySQLしか使えない僕には全てのバグ対応は無理でしたorz
IEの表示崩れなど致命的な欠陥に繋がらないバグは一旦対応せずにリリースという判断がくだりました。
大量のバグが次々とシートに記載されていく様は圧巻でしたね笑
今となっては笑い話です。