システム開発する会社にいます。作ったもの（プログラム）に対して、テストをするのですが、いつも最初は2〜3割ほどテストをク…

Question

システム開発する会社にいます。作ったもの（プログラム）に対して、テストをするのですが、いつも最初は2〜3割ほどテストをクリアできません。問題の部分を修正してからまたテストを行う、ということを繰り返しやり、いつも問題なし（100%テストクリア）で納品してるのですが、こういうやり方は普通なのですか？

なお納品してから問題が次々と起こるので、その対応もしなければなりません…職場の上司からは「これが当たり前、昔からそうしてきた」と言われます。

Answer 1

>100%テストクリア
これが作成した項目を100%行ってクリアすること、という意味であればその通りです。「一部のテストはクリアしませんでした」・・・で納品なんてありえません。
作成したテスト項目は100%実施するのが当然です。実施できないならば実施できない内容を理由を含めて顧客と調整しなければなりません。

さて、
>いつも最初は2〜3割ほどテストをクリアできません。
ということですがまあ、そんなものです。
もし、最初から100%クリアできるテストならば、テストの内容のほうに不備があるとしか思えません。（たとえば検品作業で100%問題ないって言われたら「お前、本当にチェックしたのか？」って疑問に思いますよね）

さて、
> なお納品してから問題が次々と起こるので、その対応もしなければなりません…

それは、テストが悪いんじゃないでしょうか。普通、納品後にそんなに大量に問題が噴出したらテスト工程が悪いと判断されますね。お客様もそれで良しとしているなら良いのですが。

・テスト項目が網羅されていない
・テストの観点が雑
・などなど

Answer 2

100%テストクリアで、納品する事は、ありえません。ゼロバグが不可能なのと同じです。テストクリアしていない項目をクリアした事にすると、テスターとしての責任問題が発生するでしょう。テストしたいないと同じですから。

テスターはクリアしていない項目は、バグとしてマネージャーに報告する。
マネージャーは、このバグの重要度を判断して、重要度が低ければリリースする。そして、次のバージョンで修正する。

アメリカのIT会社にいますが、テスト項目で合格となった不具合が発生して、テスターの責任問題になった事があります。

開発者がテストすると、バグに対して甘くなりがちなので、別にテスターをつけるのが普通です。テスターには、開発者と少し対立しても、テスト結果をきちんと報告する事が求められます。

Answer 3

そうですか。実装前にテスト仕様書を作成して実装に入れば、不具合が発生する状態でテストに入ることはないでしょうに。
最初から2～3割もテストをクリアできない品質でテストを開始するようでは開発プロセスが不適切と思えます。
>いつも問題なし（100%テストクリア）で納品してるのですが、
>なお納品してから問題が次々と起こるので、
問題なしで納品して、納品後に問題が次々と起こるということは第一にテストケースが不足しているでしょう。また、開発スタイルはデータベースに接続して画面からデータを入力したりボタン押下しながら開発するスタイルではないでしょうか？

他の方とのやり取りで、
>費用がないとのことで、テストケースを無駄に増やすな、と指示されてます（上司）
冗長なテストケースは無駄ですが、必要なテストケースを増やすなということではないでしょう。

Answer 4

学校の演習程度の簡単なものならいざしらず、お金をもらえる程度の規模のプログラムをミスなく作れる人なんて人間にはいないでしょう。
テストと言ってもいろんな段階でのテストがあるので、単体テストレベルで問題を出さないなんてのは、人間には無理な話ですね。
結合テスト段階くらいなら、単体テストでしっかりバグつぶしができていて、設計に問題がなければ、バグが出ないということも理論的にはあるでしょうが、実際にはこれもほぼないです。

一般的には、バグカーブと言いますが、バグ検出率は徐々に下がって行くような形を描くのが普通で、その傾きが低くなっていれば十分テストできているとみなすのが一般的ですね。
https://monoist.itmedia.co.jp/mn/articles/1002/18/news101.html

納品してからも問題が多く出るってのは、テストが不十分である可能性が高いですけど。
もっとも、完全新規で作ったシステムが納品後全く問題を起こさないってのも珍しいことではあるので、多少は障害が出るものではありますけどね。
そこはテストにどれだけ金をかけるかでしかないので、例えば銀行のシステムとか、宇宙ステーションの生命維持システムとか、治療に使う医療関係のシステムとか、そういう「不具合が起きたらすごく困る」ものは、システム稼働後にはほぼ問題が出なくなるくらい徹底したテストをしますけどね。
そういう意味では、みずほ銀行の大規模システムトラブル＆長期化とか、マイナカードのトラブルとかは、ちょっとありえない話ではありますが。

たとえば、WindowsとかMacOSとかも、メジャーなアップデートの直後は、何らかのトラブルが起きて、パッチが高い頻度で出てくるとかはよくありますよね。
ああいったものは、元々オンラインアップデートを前提としており、あくまでクライアントPCでの利用なので、テストにアホみたいなコストを掛けるよりは、問題があったらアップデートすれば良いという割り切りがある程度含まれているわけです。
オンラインゲームなんてもっと酷いですよね。
大型アップデート直後のバグなんて常識ってくらいだったりしますから。