経緯
これから記述するバグ票のお話は昭和50年代前半、私が新人社員として過ごした約3年間の出来事です、まず、皆さんが知っているバグ票とは別物として捉えてくださいね、当時、4社合同で開発していたシステムがありました、不具合やダウンが発生した時、その原因はどこにあるのか、ダウンしたプログラムが直接な原因とは限りません、ですから、原因が判明し誰がどのように対処したのかが明記されるまでバグ票は永遠に4社間を周り続けることになります
解析担当者の机の上
まずはダウンや不具合が発生した箇所のプログラム担当の会社へバグ票が渡されます、当時はダンプリストが付いている場合も多くありました、ダンプリストですから、そこそこ重たいですよ、解析担当者の机の上は複数個のダンプリストが所狭しと積み重なっていました、処分しようと持ち上げるだけでも「よっこいしょ」と思わず声が出そうになる状態です、しかし、そこは仕事でありプロの解析担当者は黙々とバグ票とダンプリストを解析し不具合原因を見つけるのです
カッコイイ
新人社員の私にはたくさんのダンプリストに囲まれて解析作業をしている先輩社員達がカッコよく見えて仕方ありませんでした、まさにプロフェッショナルの姿、いつか自分もダンプリストに囲まれながら仕事をしてみたいと思っていたのです、結果としてバグ票へ原因と対策を明記し自分のサインを残す、信頼されている社員だからこそ担当できる仕事です
TOK、再現待ち、本当にそれでいいの
忘れもしません、バグ票にはいくつかの終結方法が存在していました、不具合やダウンなのですから、そこには明らかに原因があるはず、原因が判明すれば対処も可能、通常はバグ票にはその旨を記載し終結します、が、しかしですよ、そうではない終結方法が存在していました、その一つはTOK（たぶん、テストOKの意味）です、これはですね、どんなに不具合に見えても「これで良い、問題なし、そういうものです」と終結する方法、もう一つは再現待ち、これは凄いですよ「起きない事象が起きた、なので解決方法は不明、再現されたらその時もう一度考慮する」なのです、起きないって起きたでしょ、それを起きないって一体何がどうなっているの、？？？？、だから再現待ちなのです、ある時、ユーザー側から強烈なクレームが来たらしい「TOK、再現待ちになるのでは、試験をやっても意味がない」と、ごもっともですね
コメント