テストやチェックすることが苦手です。直す方法はありますか？

質問

プログラム等を変更した時、テストや目視でチェックをするのですが、間違えている箇所を見つけることができないのです。処理をを止めてしまってから、気がつくことになってしまい、いろいろ方に迷惑をかけてしまいます。自分の目に自信がなくなってしまい、何度確認しても安心できなくなってしまいました。性格的に一点集中型で、他が見えなくなるのが原因のひとつだとは思いますが、直す方法はあるのでしょうか？

回答No.4

kyoujirouY · ベストアンサー

おおむね＃１の方の意見に賛成です。
仕様書やチェックリストがしっかり作り込まれていれば、
コーディングミスなどが原因の不具合は防げます。
どうにかしたいのならば、その辺から手を付けてはどうでしょうか。

コーディング時のミスが原因であるの不具合が指摘される場合は、
テストが不十分ということです。
しっかりコーディングすれば防げるのは確かですが、
熟練者でもやってしまうことですし、それをチェックするためにもテストするのです。
ですのでチェックリストの内容を見直しましょう。

コーディングした人がテストすると、どうしても視野が狭くなってしまいます。
プログラムコードを元に結果を推測し、大丈夫だと思い込んでしまうのですね。
思い込みを廃し、客観的な視点からチェックリストを作成するのが大事です。
個人的にはコーディングを行う前にチェックリストを作りたいですね。

テストは、正しく動くのを確認するのではなく、
不具合を見つけるつもりでやった方が良いかもしれません。

また、テストの結果、チェック項目の数に対して不具合の発見数が
少ない場合は疑ってかかった方が良いです。
バグが無いのではなく、バグを見落としている場合もありますから。

テストで不具合がたくさん出るのは問題ありません。
そのおかげで本番で不具合がでなくなるのですから。

お礼

時間に追われて、書類作成が後回しになっていたような気がします。現在保守をしているシステムは、仕様書が存在しているほうがめずらしく、仕様がわからなければ、プログラムの作成者に聞きにいくか、プログラムを解析するか、作成されたデータから推測していました。仕様書やチェックリストなどが存在していない、作る習慣がないということが問題なのですね。できるだけ、コーディングを行う前にチェックリストを作るようにしたいと思います。ありがとうございました。

回答No.5

situmonman

ソフト開発の仕事の関係で、アルバイトの方（中には全然ＩＴ技術に詳しくない主婦の方などもいます）にソフトウエアの動作確認テストやデータのチェックをしてもらってますが、人によってチェックの結果が変わってしまうことがないように、チェック方法を記したマニュアルを整備してからチェックしてもらってます。このマニュアルの作成にはかなり時間をかけており、非常に分厚いものとなってます。それぐらい、テストの前準備は大切だ、ということです。
他の人はきちんとバグを発見できるのに自分はできない、ということはそのテスト方法に何かが足りないということです。テストスキルに問題があると疑う前に、テスト方法を見直してみてはどうでしょうか。

お礼

プログラミング言語やソフトの使用方法ということはいろいろなところで、学んできた記憶があります。
　勤め先は変わってものの、社内のシステム保守の部署にいたためでしょうか、テスト方法については、見よう見まねで、きっちりをした物を作ったことがないのが原因のような気がしてきました。あまりにもミスが多いので、システム開発の仕事から、一時期、外されたこともあり、この仕事から離れることを考え始めていました。職種が変わったとしても、確認作業というのはあるわけで、シビアな環境で仕事をされている方と私とどこが違うのだろうと思い質問させて頂きました。すこし光が見えてきました。ありがとうございました。

回答No.3

ninnniku00_ge

先出の方が、手順については、丁寧に説明されていますが、そういった作業を他のメンバを交えて行っていますか？
経験豊富なPG、SEであれば、経験的に、問題になりそうなケースを事前に考慮したコーディングしたり、重点的にテストしたりということが可能でしょうが、そうでないなら、他の人にコードレビューしてもらうなり、検査も検査専任者に行ってもらうなど　チームとして回避すべきでしょうね
個人の問題というより、品質を向上させるためのチーム、あるいは会社としての取り組みに問題があるのではないでしょうか？

質問者さんのスキルがわかりませんので、なんともいえませんが、駆け出しのころは、視野の狭さゆえのミスもあります（もちろん熟練者でも油断すれば、ミスしますし）　同じ誤りを繰り返さないためには、問題をおこしたときのプロセスを自分なりに分析し、同じミスを起こさないように次に生かす（ようは経験値を上げる）という努力がやがて実を結ぶと思います。

お礼

社内システムの保守をしている部署にいます。テストといっても各個人（担当者）に任せられていて、テストの作業手順という話は、あまりすることがありませんでした。視野の狭さによるミスや熟練者でもミスはあるものなのですね。（システム開発をされている方は完璧にできる方だと思っていました。）問題を起こしたときの状態を（その時の精神状態を含めて）分析できるようにしたいと思います。ありがとうございました。

回答No.2

akipapa

アドバイスとしては、プログラムの不良が発生したときの原因が、どこにあるかを見なおすことから始めてください。プログラム設計が不十分なのでしょうか、プログラムが間違っているのでしょうか、テストデータのパターンは十分だったでしょうか。

基本設計→詳細設計→プログラム設計という順番にブレイクダウンしていくと、どこが変更箇所であるかは明確になっていきます。
目視で何をチェックしているかが気になります。プログラムを変更する場合、変更仕様を先に決定しているはずです。「変更仕様通りにプログラムが変更できているかどうかを目視している。」という意味でしょうか。目視で確認できるということは、プログラム仕様書（プログラム設計の結果）が相当細かいところまで記述されていると考えられます。
質問者は、プログラムのみの担当者であって、詳細なプログラム仕様書とプログラムを目視してチェックしているのに間違ってしまうのでしょうか。この場合なら、フローチャートの書き方を覚えて、フローチャートを書いてからプログラムを作成することをお勧めします。プログラムとの対照がしやすいので、フローチャートはＰＡＤがお勧めです。

次にテストですが、処理が正常終了するデータ（最大、中間、最小）と、エラーメッセージを出力するデータ（単項目でのnull、範囲外、複数項目の関連不整合）の両方でテストする習慣を身につけてください。既存のプログラムに新しい機能を追加する場合でも、追加した機能のテストだけでなく、元々の機能が損なわれていないか、というテストをするということです。

お礼

原因は、簡単な記述ミスや、思い違いが多いです。自分でこれであっているものだと思い込んでしまい、トラブルが起こってから気がつくことを何回も繰り返してしまいます。今は出勤前ですので、帰ってきてから
じっくりと考えたいと思います。ありがとうございました。

回答No.1

Sompob

性格？　何をバカな。

仕様書が不備だからだよ。

設計仕様書は？
チェックリストは？
試験手順書は？

誰がやっても、これに従えば
同じ結果が得られる筈なんだ
けど．．．

チェック出来ないって謂われ
るから、どれか一つが、又は
全部が不備だろ。

それから標準化してるのかな？

お礼

正確に作業のできる人と、できない人の差を知りたかったんですが、できる人にとっては、私は、バカなんでしょうね。ありがとうございました。