それじゃ、行ってみようか。

　11月からのスケジュールがムチャクチャで、担当したプログラムの仕様書設計が2日、プログラミングが単体テストとレビューを含めて3日。

　ちょっと単体テストとレビューってのを説明すると、プログラムを組めばテストをするのは当たり前ですが、効率の良いテストをするための計画書を作る必要があります。そりゃ、テストをすればするほど良いでしょうが、無駄に項目を増やしても時間を取られるばかり。例えば（便宜上、1950年以降の）西暦を和暦に直すプログラム作った場合、昭和と平成の境など要点をチェックすればOKで、1950年以降を1年ずつ入れていくのは無駄…と言う感じ。

　ゆえにテスト計画書が妥当かのレビュー（審査会みたいに思ってください）をし、過不足があれば修正。ＯＫが出るまでそれを繰り返し、その後テストを実施。当然、バグが発生したらその時点でテストを中断してプログラムの修正。テストの内容によってはそれまでのテストをやり直す必要がある。その後、その結果のレビューもあるのですが…今回問題になったのがコレ。

　こんなテストをし、こんな結果になりましたと報告していると「この観点では見てないの？」と。いや、それはテスト計画書のレビューで言えよ！過不足の吟味ができていないって事じゃん。で、追加のテストを実施して再度レビューをすると「この値も変更されるよねぇ？」とか言い出す。それ、仕様書を書く時点で言えよ！

　仕様書の書き換えしてレビュー、プログラムを組み直して再度テスト計画書を追記。レビュー。そしてテストを実施して結果レビュー。あれ、この値おかしいんだけど？と仕様レベルの話をまた言ってくる。ここで仕様書を…以下同文。できた計画書だけでA4サイズ15枚、項目で200個くらいのテストにそれに見合う大量のエビデンス（←テストをした証拠として、画面のスクリーンショットや出力結果のデータ、処理結果のログなどをまとめた資料）。

　以上、いっぺんに言えばもっと効率よく出来たと思われますが、それでも3日じゃ無理な作業量。先日書いた「愚痴るのも鬱陶しくなるほどの理不尽さに悩まされている」と書いたのがこんなお話。

　多分、月末には「思ったほど仕事が進んでない」「この役立たず！」って罵倒されるんでしょうねぇ。


　あぁ…はやく燻製作りたい（笑）。

この記事へのトラックバックURL
https://fanblogs.jp/tb/4423256

お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。