単体テストとは

単体テストとは

みなさんは「システム開発におけるテスト」と聞くと、どのようなテストを思い浮かべますか?

システムの機能が正しく動作するかを確認する機能テスト、システムに負荷をかけても不具合が起きないかを確認する負荷テスト、情報流出の恐れがないかを確認するセキュリティテストなどさまざまなテストがあります。

システム開発におけるテストの流れは以下の通りになります。

システム開発におけるテストの流れ

単体テストは、システム開発の最初に行うテストです。

システムの機能や画面を分解した際に、その小さな1つ1つの単位を対象にして行うテストのことを単体テストといいます。※UT(Unit Test)とも呼ばれます。

単体テストを行うことで、個々の機能や画面が想定された通りの動きをしているか確認することができます。

例えば、家計簿アプリの開発では、金額を入力した際に、画面に正しく数字が表示されるかなどを単体テストで確かめます。

家計簿アプリの開発

単体テストを完了することで、次の結合テストに移行する品質が担保でき、結合テストがよりスムーズに行えるようになります。

単体テストと結合テストを正しく行わないと、システムテストに途方もない時間がかかってしまうため、両者の特徴や違いについて理解することは重要です。

単体テストと結合テストの違いを理解したい方はこちらの記事をご覧ください。

【ゼロからわかるシステムテスト入門】ー単体テストと結合テストの違いー

テスト観点とは

テスト観点とは、システムが正しく動作するかを確認するために、どの部分で、どのようなテストを行うかを可視化することをいいます。

テストの方向性を決める要素となるため、システム設計段階までに決定しておくことが望ましいです。

テスト観点とは

例えば、家計簿アプリの単体テストでは以下のようなテスト観点があります。

・金額を入力した際に、画面に正しく数字が表示される
・登録ボタンを押した際に、正しくデータが保存されるか
・入力した形式が誤っているときに設定したエラー文言が出るか

テスト観点についてより詳しく知りたい方はこちらの記事をご覧ください。

【ゼロからわかるシステムテスト入門】ーテスト観点とはー

単体テスト計画時のポイント

単体テストは、①計画→②設計→③実施とフェーズ分けすることができます。

「①計画」での品質や期間の要件が「②設計」でのテスト観点に影響を与えます。

例えば、「①計画」では以下のような考えるべきポイントがあります。

・テストによって、どこまでの品質を担保したいか?
・テストに使える期間がどの程度あるか?
・システムの仕様はどのようにあるべきか?

当然、テストの品質と期間はトレードオフの関係にあります。

・システムを最低限リリースできる程度の品質にするのか
・不具合のほぼない完璧に近い品質を目指すのか

品質の高さや期間の長さに応じて、テスト観点の数や細かさが変わります。

例えば、Webページの画面検証では以下のような違いがあります。

・最低限の品質:「文字表示に崩れがないか」
・完璧に近い品質:「画面サイズやデバイスが変わっても文字の大きさや改行の位置などが適切に反映されているか」

Webページの画面検証

単体テストを始める際には、いきなりテスト設計をするのではなく、まずは計画を立て、品質や期間の要件を定めることが重要です。

単体テスト設計時の観点

「②設計」で考えるべき観点には以下があります。

・テスト仕様書の明確性
・テスト観点の網羅性

それぞれ順番に解説していきます。

テスト仕様書の明確性

システム開発のテストでは、テスト仕様書を作成する人と、実際にテストを実施する人が同じであるとは限りません。

仕様書作成とテスト実施の担当が異なるときは「テスト仕様書の明確性」に注意する必要があります。

テスト仕様書は認識の齟齬がないよう、誰がいつテストしても同じ内容でテストできるようにします。

曖昧な表現は使わず、認識に齟齬が生まれそうなテスト項目には、備考欄などに詳細を記述します。

一人で作成するのではなく、第三者からレビューを受けることで、より認識齟齬が生じにくいテスト仕様書になるでしょう。

例えば、以下のような記述を心掛けます。

NG:良くない記述例
「ボタンを押して動作をチェック」

OK:正しい記述例
「登録ボタンを押した際に、ポップアップで登録完了のメッセージが表示される」

テスト仕様書の明確性

テスト観点の網羅性

システム開発のテストでは、テスト観点が網羅されているかを確認することも重要です。

もちろん人間がテストを設計し、実施する以上、完璧に1件の抜け漏れもなく網羅することは不可能です。

しかし、システムの仕様やユーザーがどのように利用するかを想定することで、なるべく抜け漏れがないように設計する必要があります。

コードの論理的な正確性を確認したり、過去のテストでも頻繁に起こったバグなどを重点的にチェックするなどの方法も有効です。

また、多角的な視点から網羅性を担保するためには、要件定義書の作成者(クライアント)、開発者、テスト実施担当者など様々な役割の方にもレビューしてもらうのがいいでしょう。

まとめ

単体テストにおける観点を考える際には、以下の点に注意するとよいでしょう。

①計画:テストの品質とテストにかけられる期間を明確にする
②設計:テスト仕様書の明確性とテスト観点の網羅性に注意して設計を進める

テスト観点に漏れがあると、リリース後の不具合対応に追われたり、セキュリティ事故の危険性が高まるなどのリスクが生じてしまいます。

しかし、
「テスト仕様書を明確にするにはどうすればいいの?」
「テスト観点が網羅できているか不安、、、」という方もいらっしゃるかと思います。

そのような方のために、テスト専門会社GENZのノウハウが詰まったテスト観点表をご用意しました。

以下からダウンロードできますので是非ご参照ください。

テスト観点一覧[表示系]
テスト観点一覧[スマホアプリ系]
テスト観点一覧[Web系]
テスト観点一覧[API系]

GENZでは、徹底したヒアリングと積み重ねてきた1,000以上のテスト観点設定から、お客様に最適なテスト観点を提案させていただきます。

「システム仕様で特に確認してほしい部分がある」などのお客様からの観点の提案も大歓迎です。テスト完了までお客様と一緒に進めていきます。

ご不明な点やご質問がございましたら、お気軽にお問い合わせください。

 

お問い合わせ