🗂

テストのコツについて考えてみる

2024/02/25に公開

何故コツについて考えようと思ったか？

モダンなアジャイル開発の現場では、事業スピードが早いので、
スプリントが1~2週間を採用されている事が多く、デグレを軽減させるためにテストへの意識も高い現場が多い。

ただ、テストに時間を割きすぐると開発スピードが落ちるので、可能な限りテストにかける時間を軽減したいと思ったため為です

そして、時間がかかる原因は、「そもそもテスト手法を知らない」事が原因だと思い
「はじめて学ぶソフトウェアのテスト技法」を読んでみる事にしました

そもそもシステム開発をする上でテストは必要で、ユーザー側のテストが本来必要です。
ただ、ベンチャーだったりすると、ユーザー側のテストがそもそもされていいない企業が多いと思います。
そんな中、開発側でどお補っていくのかの手がかりを掴めると思います

プログラムの内部構造をテストする事。
実装した関数などが期待通りに動くかテストすることを指すようです。
こちらは「開発者」が担保する領域

意図した処理が、行われるか検証する事
例えば、ファイルのアップロードを、アップロードボタンを押したら、
アップロード出来るかどうかなど
こちらは、「ユーザー」が担当する領域

んん。わかったような分からんような

ブラックボックステストの中に下記のさらに細かな分類がある

これらの細かなテスト方法は割愛させていただきます。
「はじめて学ぶソフトウェアのテスト技法」を読むか、ネットで調べればすぐに見つかると思います

Rubyでテストをするとなると、Rspecを利用する事になると思います
その際に、システムの構造によると思うのですが、
よくある構造としては、「モデル層」「サービス層」「コントローラー層」、に分かれている事になるかと思います

「ホワイボックステスト」は、プログラム（関数）が期待する通りに動くのをテストするのであれば、
モデル層のモデルメソッドのテストが、ホワイトボックステストに当たる気がすると感じました

サービス層のテストは、ある意味、ブラックボックスのテストの「同値分割法」「境界値分析」「状態遷移テスト」に当たる気がしました

また、System Specという、ユーザーの動作を再現するテストもあると思うのですが、
それが、「ユースケーステスト」に当たるなと感じました。

今までテストはどんなテストをすれば良いのか？と悩む時間が多かったので、「はじめて学ぶソフトウェアのテスト技法」を読んでみたことにより、全体像が掴めたので、属するプロジェクトやチームで何が欠けていて、どお補っていくべきなのか？を自分で検討できるようになりそうです。

例えば、ベンチャーでテストチームなどがない場合は、本来は「ユースケーステスト」までプログラムで書く必要があると思いますし、テストチームがいるなら、「状態遷移テスト」までで良いと思いました。

・はじめて学ぶソフトウェアのテスト技法