Q&A
ご回答ありがとうございます。
やはりテスト設計のやり方としてはおかしいのですね。
しっかりと最新のテスト手法などを勉強し、自分から提案することができるよう頑張っていきたいと思います。
単体テストの設計書をソースコードを見て作れと言われたのですが、
それが正しいことなのかどうか悩んでいます。
業務内容は、仕様書はなしで出来上がったソースコードを見て、if文の分岐を必ず一回は通るように試験ケースを設定し、入力値、出力値を設計書として書き出していくというものです。
疑問に思った点としましては、
- 試験ケースが仕様書基準ではなく、ソースコード基準でつくられるため、もし出力値が仕様どおりでなくても、テストとしてはOKになってしまう。
- そもそもテストとして成り立っているのかどうか。
プロの人から見た場合、仕様書なし、ソースコードのみでのテスト設計は正しいのかどうか、ご意見を伺いたいです。
回答2件
0
ベストアンサー
疑問に思われている通り、テストとしては成立しません。
- 指示をした人にテスト作成の意図を聞くのが一番早いですし、技術者のスキルとして聞き出す能力は必要とされると思います。(が、あんまりにもレベルが低そうな匂いがしてたら聞き辛い気持ちもわかります)
実際に何を意図しているかは聞かないと判明しないと思いますが、ありそうな推測を挙げてみます。
推測1
契約上の責任回避のための作業であるケース
推測するに「納品物としてのカバレッジ100%の単体テスト」が必要なだけであって、「品質を担保するためのテスト仕様書」は必要ではないということではないでしょうか。
膨大な量の「納品物としてのテスト仕様書」を納品し、検収させる（実際には全部目を通されることは無い）ことで責任問題を回避するための作業なんだと思います。
問題があったら、「仕様の解釈としての実装はテストケースの通りです。検収頂きましたよね？」と言い張ります。（法的に有効かどうかは別の話ですが。）
推測2
今後の修正でのデグレーションを防ぐための作業であるケース
今書かれているテスト設計書をベースに、ユニットテスト（自動テスト）を起こすつもりである。と希望的な観測をした場合は以下の様な意味で一定の意義はあるのかなと思います。
仕様としては結合テストのテストで担保し（こちらは仕様書ベースでテストを書くのかも）、単体テストは「テストを書いた時点から単体ベースでは変更がないことを担保する」ことに注力することで、今後単体レベルでの仕様変更はきちんと管理されるようになる。。。
追記
推測3
単語の定義の問題であるケース。
慣習的に「単体テストの設計書」と呼称されているものが実は「現在の仕様の確認/調査書」であるだけのケース。。。
追記2
推測１-２
推測１に近いですが、「とにかく納品物としてテスト仕様書が必要である（もしくは、になった）」ケース。
「発注側の組織内ルールとしてコードカバレッジ100%のテスト仕様書が必要」でかつ、「形式的には内部監査に耐えられる内容であること」が求められているが、予算/納期的に真面目に作るのは無理なので、今回の様なケースになることはありがちです。
受注時には約束してなかったテスト仕様書を当然の様に求められて、断り切れなかったとか、慣習的にそういった流れになってるとか。
推測2+3
網羅的な仕様確認の起点となるドキュメント作成であるケース。
実は、現在出来上がってるのものが、一種のプロトタイプ的なバージョンで、これをもとに最終仕様の検討などがされる場合にはあり得るケース。
まずは現在の仕様を把握し、わかっている範囲のテスト仕様書を書く（=現時点での単体詳細仕様書[主に正常系]が出来上がる）。
これをベースにして、全体の仕様書も作成する。
全体の仕様書が出来上がったら、単体仕様書をもう一度精査して、抜けているケースが無いかを確認していく。
色々推測を書きましたが、結局は指示した人に聞かないとわからないと思いますので
（角が立たない様に）意図を尋ねられればベストだとは思います。
例えば、「出来るだけ見やすい/使いやすいものを作りたいので、この資料って誰がどうやって使うものなのか教えていただけませんか？」という感じとかでしょうか。
投稿2017/11/18 19:14
編集2017/11/19 00:58
総合スコア18778
0
単体テストの設計書をソースコードを見て作れと言われた
仕様書なし、ソースコードのみでのテスト設計は正しいのか
質問者の方の疑問はもっともです。
たとえば「テストの答案を採点基準にしたら、
必ず100点になっちゃうじゃん」みたいなことに思えるでしょう。
すなわち、「コードが仕様」と、コードから起こしたテストでは、
そのコードにバグが含まれていても、検証できないではないかと。
検証するためには、仕様とコードを分離する必要があるはずです。
――しかし、実態として、
「仕様書がないままテストを作る」、
「テスト仕様書はテスターが作る」、
という現場はよくあるのではないかと推測します。
改めてまず、テストの仕様書／設計書などを誰が書くべきか、考えてみます。
システム開発の教科書的には、ウォーターフォールならV字モデルで、
詳細設計と単体テストが連動しているはずなので、
詳細設計の設計者がテスト仕様書も書くのが基本でしょう。
しかし、設計者は人件費の単価が高いことが多く、
経営層がテスト仕様書を書かせたがらないこともあります。
また、アジャイルなら、テストファーストなどとの相性もあり、
プログラマがテスト（仕様書）を書くこともあるでしょう。
少なくとも、自分で実装したので、コードの挙動は理解できているので、
これも選択肢として十分有力だと思います。
しかしこれもやはり、経営層がさせたがらないことがあります。
プログラムを書く工数よりも、設計やテストやドキュメントなどを書く、
それ以外の工数の方が多いのが普通なので、負担だということです。
こうして、テスターがテスト仕様書を書く、という事態が発生します。
「私がテストできないのは、どう考えても（仕様書を書かない）お前らが悪い！」
と開き直っても生産的でないので、べき論ではなく、別の道も考えていきましょう。
ところで、「プログラミング」とは、狭義のコーディングだけでなく、
設計まで含んだ広義のプログラミングの意味もあります。
同様に、広義のテストには設計も含む、と考えることもできそうです。
もちろん、一般的にそう認識されている、というわけではないですが。
なぜ、そう考えることに意味があるのかというと、
設計の時点でテストを完全にカバーするのが難しいからです。具体例を考えます。
「ボタンを押すと入力を表示する」プログラムに対して、
「ボタンを押すと入力を表示する」ことを確かめるだけでは、不十分なテストです。
たとえば、どういう文字種を許容するのか、半角全角どちらでも良いのかとか、
電話番号や郵便番号ではハイフンを入れるか入れないかとか、
HTMLのタグなどが入力できてしまうと、脆弱性につながる……とか、
入力だけでも何十個もテストする項目がありえます。全部実施できるか別として。
すると、設計の時点で全部カバーしようとしても、
人的リソースが足りなくなる事態も想定可能、というか現実によくあるでしょう。
テスト仕様書ができている「べき」、といっても現実にできない。
だから、あふれた設計的要素がテストまで流れてくる。
テストに設計的要素などというと、違和感があるかもしれませんが、
最近では「探索的テスト」の手法も注目されているようです。
簡単に説明すると、設計書などがなくても、バグがありそうな部分を
自力で探索してテストする手法です。これを、設計書がないのなら、
設計的要素がテストの責務に分配されている、と私は解釈しています。
最初の話に戻って、テスト仕様書がないからテストが不可能かといえば、
テストに設計的要素が入ってくることで可能なのではないかと思います。
ただ、そのためには、テスターが要件や仕様を把握する必要があります。
正しいのかどうか
「正しくない」と切って捨てるのは簡単です。
それなのになぜ、わざわざこんなことを言うのか？
自分の方が正しいと思うと、正しさに安住してしまうからです。
最初に戻ると、質問文の状況では、従来のただの制御パステストです。
そこから先に発展するのか不明ですが、現状ではかけ離れてます。
たんなる検収のアリバイのために、形だけ作っているのかもしれない。
それでも、現在の状況だけ見て、可能性を切り捨ててしまうと、
数年後には時代遅れになってしまう可能性だってあります。
そもそも、昔はテストを書かないところも多かったようですし、
テストファーストとかも普及してなかったし、今と色々違います。
昔はリファクタリングより「動いているものをいじるな」が正しかった。
**昔は「正しくなかった」ものが「正しくなってきた」**んです。
だから、かくあるべき、という「べき」論よりも、
現実に対してできることを探っていく方が、
とくに変化の早いIT関連では有効な考え方です。
たとえば、質問者の方がテストの力をつけていくことで、
提案する余地のようなものができていくかもしれない。
もっと遠い未来では、出世したり、転職したり、独立したりして、
組織のテストのやり方を変えるかもしれない。
新しいテスト技法の先駆者になるかもしれません。
そのためには、「新しい正しさ」を目指す必要があります。
投稿2017/11/19 01:33
編集2017/11/19 01:42
総合スコア5592
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/11/19 03:55
2017/11/21 11:42