悩めるSEの雑記です

日々思いつくがままです

嫌な体験は吐き出してスッキリしたい

この数日の間に、とても嫌な体験をしました。ずっともやもやが続くので、ここで成仏させたいです。

ざっと概要

  • 火曜日、水曜日で基幹系システムと対向テストを行った。
  • なんの準備もなく迎え、見事にミスが多発した。

起きたこと

  1. 無計画で当日を迎えた。
  2. データの準備だけで1日を費やす。
  3. 最後のバッチがエラー終了になる。
  4. 最後のバッチが正常終了しているけれど、途中でOracleエラーのメッセージが出力される。
  5. 最後のバッチが1件しか送信していない。
  6. どうしても送信対象が作られない。
  7. レコード作成時に設定されるFK項目がおかしい。
  8. ビルドにあたふた
  9. 送信先が違っていた

順番に見ていこう

無計画で当日を迎えた。

  • 火曜日、水曜日がテスト実施日であった。
  • 火曜日の朝、どういう段取りかリーダーに尋ねた。しかし一切準備なし。
  • 自分は前日休出して、段取りが必要なことのリストアップ、対象データの整理、プログラムの実行順序と担当だけ整理しておいた。このテストの本来の目的である、拠点システムが出力した実績を基幹系へ送り、正常に処理されることを確認する。そのために基幹系から受け取った計画にしがって拠点システムを動かす段取りを考えていた。
  • しかし火曜日朝時点で何も考えていないリーダー。とことん詰めた結果、対向前に実施した単体テストの環境で出力した実績データだけ格納してくれた後はやる、と。シナリオに乗っ取らず、しかく各自バラバラで実施して出力された実績を集めて送る。やっつけも良いところ。

データの準備だけで1日を費やす。

  • 使うデータなどは整理していたので、それをメンバーに共有して実績出力を実施した。
  • これだけで1日目は終了してしまった。
  • リプレイス後の構成についてはまだ未決定であったり、そもそもテスト担当していないシステムだったこともあって、幾分あやふやなところがあった。
  • 一部、翌日に開発側への確認を残してしまった。

最後のバッチがエラー終了になる。

  • 二日目はメンバー一名、直接システム・テストに関わらないサブリーダー(的な方)、リーダーで対向テスト実施となった。
  • 夕刻になっても終わっていない模様で尋ねると、何かエラーが起きているが出力がなくわからないとのこと。
  • このシステムはDB接続後、エラー情報はDBへ記録されるのを知っていたので確認して共有した。
  • 動かしているバッチがどこへログ出力するのか、それもわからずにテストをしている。ちなみにこのやり取りは、過去に何度もやっているので、覚えていたらすぐ対応出来たことなだ。

最後のバッチが正常終了しているけれど、途中でOracleエラーのメッセージが出力される。

  • 何故かOracleスキーマに関するエラーメッセージが出力されていた。
  • シンプルなバッチでそんなおかしいところもなさそうであった。とりあえず切り分けが必要なので、どこで起きているかわかるようログを入れてもらった。(因みに退社後、テレワークで様子を見に来た結果)
  • この操作を担当しているメンバーがまたあやふやで、どこどこ?どれどれ?なになに?状態で全く進まない。
  • ログを入れてみると、何故かOracle接続処理の中で起きている。接続に使用しているアカウントやSIDが問題ないのは確認できている。
  • 原因はなんと単体環境に追加していたOS認証パッチであった。なんで単体テスト用パッチを当ててるのか!?何が何故何のためにあるのか、全く理解していない。

最後のバッチが1件しか送信していない。

  • エラー調査用に入れらログを見て気付いた。どうも1件しか送っていない。今回このバッチで送られるデータは4件のはず。
  • さっきのOS認証のエラーは実行自体には影響なかったので、先に送られていたのかもしれない。大本になるテーブルの登録状況を確認すると、1件しか対象となる状態(製造完了)になっていない。なぜ?
  • それにしても、何があるべき姿か(この場合はどの実績が送られるべきか)わかってないし、確認もしていない。

どうしても送信対象が作られない。

  • 送られているデータもどうも違う。なぜ?
  • バッチのSQLを抜き出して確認するがおかしいところは見当たらない。
  • 仕様書なども再確認するが・・・

レコード作成時に設定されるFK項目がおかしい。

  • 大元レコードが保持している、指示情報のキー値がどうも違う。
  • バッチから抜き出したSQLでは正しく取得できている。なぜ?
  • 何度も確認するが、どうも取得する条件が想定通り作用していない。
  • !?ふと気づいた。バッチが最新バージョンじゃないのでは???確認すると刷新していないという。なぜ?わざわざ試験環境のバッチが古いから刷新が必要と伝えてあり、ユーザへ最新バージョンの確認まで実施していたのに・・・開発側リポジトリも最新であり、そこから取得すれば良い、というのが確認結果だった。だからそのソースでビルドデプロイしてくれたら良かったのに。なぜかそれでテスト環境も最新だと思ったらしい。一年くらい刷新していないし、自分達もこのバッチのテストや不具合対応していたのに・・・何故わからないのか。
  • とにかく情報を整理して理解することが出来ない

ビルドにあたふた

  • 結局22時まで作業して、翌日最新ソースでやり直すことになった。
  • 翌日は現地側でのテストのため、午前中は環境が利用できなかった。このあたりの調整も事前にできていない。
  • ビルドも少し心配だったので、Google Meetで共有されている作業を覗いてみた。ゾッとした。ビルドのプロジェクト・参照アセンブリなどの理解が浅く、ただビルドするだけに、あたふたしてて全く進んでいない。
  • ウィンドウを沢山開いて、あっちこっちいって、ちがうこれじゃない、とか。ひどい状況。
  • とりあえずビルドはできたものの、環境が利用できないのでそこでMeetを抜けて放置することにした。あきれてしまった。(因みにこの日、私は体調不良で休暇取得)

送信先が違っていた

  • 基幹系とIFする環境には、DB上に接続先が設定されている。
  • バッチプログラムだけじゃなく、DB上にはこういった情報やSQLも登録されており、こちらの最新化確認も必要であった。これも伝えてあったのだが・・・
  • FTP先がテスト用じゃなく別のリハ用につながっていたそうで、そちらに取り込まれてしまい影響したようであった。
  • またもう一つWebサービㇲをつかったれんけいもあるのだが、そちらの接続先についても一年ほど前のままで確認が取れていなかった。

まとめ

  • 無計画出迎え、本来の目的からズレた「お茶濁し」テストとした。
  • やることなすこと尽く失敗した。
  • お客様の費用をつかってこれは許せない。ずっとこんな感じ。自分の段取り不足で、スコープ&品質を下げて辻褄合わせ。そんな事が許されるのか。
  • いつも現場へ丸投げで、私が段取り&メンバーフォローでなんとか凌いできた。
  • 口では偉そうなことを言うリーダーだが、なかなかのポンコツで何も出来ないしやっていない。