質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.06%

テストについて

受付中

回答 3

投稿

  • 評価
  • クリップ 1
  • VIEW 1,835
退会済みユーザー

退会済みユーザー

単体テストや結合テスト、総合テスト全般についての質問ですが、どこまでテストを行えばいいのかが分かりません(どんなテストケースを作ってテスト仕様書をかけばいいのか分かりません)。

テスト仕様書自体は作成することができますが、本当にこれで全て網羅しているのか不安です。
何かアドバイスをいただきたいです。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

+1

どこまでテストをおこなえば良いかは、プロジェクトの性質や、かけられる金銭的・時間的・人材的コストなどによって違ってくると思います。

テストとはある条件下において意図した動作を行うかを確かめるものです。
ユニットテストでは、ある入力に対して正しい出力が得られるか、または正しくエラーを吐くかなどの確認を行います。
どんなテストケースを作成して良いのか分からないということは、テストすべきコードの仕様を把握できていない、もしくは仕様自体が複雑でテストが困難な状態なのではないでしょうか。

テストの網羅性に関してはカバレッジなどの確認や、境界テストなどの手法によって効率的におこなうことができます。
ただしこれに関しても、バグがないことを保証するためのものではありませんので、あまりカバレッジを100%にすることにこだわらないほうがいいと思います。
もし、あなたの言う「すべて網羅」の意味が「あらゆる状況に対するテストケースの作成」という意味なら、それを実現する方法を私は存じません。

自分の仕事がちゃんとした品質になっているのかという不安は尽きないと思いますが、時間をかけて体系的に勉強したり経験を積んだりするのがベストかと思います。
あなたの望む回答になっているかは分かりませんが。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

時間が取れるのなら、JSTQB認定テスト技術者資格(http://www.jstqb.jp/)、少し古いですがソフトウエア・テスト PRESS(http://gihyo.jp/magazine/testpress)を参考にされてはいかがでしょうか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

Vモデルの考え方を基本にマトリクスとデシジョンテーブルを活用すると良いと思います。

どんなテストケースを作ってテスト仕様書を書くかについては、基本はVモデルに従います。
規模の大小やプロジェクトの進め方が違っても結局はVモデルの考え方が登場します。
テスト仕様書のインプットはテストの工程に対応する設計書だということです。

本当に全部網羅しているかについては、網羅性が見えるようになれば安心感を得ることができます。
テストパターンの洗い出しにマトリクス表を作り、
テストパターンに対する結果の抽出にはデシジョンテーブルを作る
と良いと思います。単純作業に近いので取り掛かりやすく且つ分かりやすいでしょう。
(単純なだけに爆発的なパターン数になります。実質不要なパターンも数に含まれるので冷静に見ましょう)

単体テスト、結合テスト工程においては実際にコードが動いた実績の確認も行うと良いです。Carimaticsさんも回答されているカバレッジの確認です(昨今のプロジェクトでは必須?)。カバレッジ100%にこだわらないほうがよいという考えに賛同します。100%にするためにテスト対象のコードを変更しなければならない場合が存在します。100%にするためにテスト対象を変更しては意味がなくなってしまいます。かといって設計変更はインパクトがある。この場合はテストできない理由を記録し残します。カバレッジはトータルでは100%になることはないと言えるかもしれませんね。

蛇足ですが、Vモデルの考え方はテスト工程で設計工程の記述不足・検討不足をあぶり出すことになったりします。設計そのもののテストにもなっていると言えるでしょう。こうしたものを見つけた場合には懸案事項や課題管理表に記録し報告するようにすると良いでしょう。
(工程が終わっていたり、契約上設計書を変更できない等で受け入れられない可能性が高いですが、こうした活動は次の改善になります。)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.06%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る