日々学習〜人の役に立てるITエンジニアを目指して〜

ITエンジニアが日々学んだ事を書き記します

2015-04-01から1ヶ月間の記事一覧

変数の初期化を忘れるべからず

よくある障害のひとつに変数の初期化を忘れて、関係ない値で更新されてしまう事がある。気を付けていたのだが、自分でもやってしまった。ひとりで修正してテストまでやったので、確認が足りなかった。やはりテストは第三者がやるべきだと思った。そして変数…

効率の良いテスト方法は?

障害があった時は、どうしても短時間で対応しなければならなくなる。出来ればしっかりと時間をかけてテストしたいけど、お客さんを待たせる事になってしまう。なのでいかに他に影響のない修正をして、テストを行う範囲を少なく出来るかを考える必要がある。…

パターンを想定しきれないものは作らない

しっかりとテストをしたのだが、把握できていないパターンがあって、不具合が発生した。テストパターンを洗い出して、何十パターンのテストをしたが、網羅できていなかった。それほどの複雑な処理にしてしまった事が原因で、設計時に対処はできたと思う。設…

max値が正しく取得出来ない

テーブルのフィールドのmax値の取得が正しく出来ない障害が発生した。原因はフィールドの型がvarchar型だったためだった。varchar型だと1から10の値があった場合、9が取得される。select時、convertでint型に変換するか、フィールドの型をintに変更するかの…

作業の優先順位

本稼動から1ヶ月半が経ったが、障害や問い合わせはまだまだ落ち着かない状態。割り込みの作業が随時発生して、上手く仕事がまわせていない。優先順位の付け方と誰に作業を依頼するか瞬時に判断するのが難しい。あとは情報をすぐに共有する事が大事だなと感じ…

テスト結果報告で信頼を得る

不具合が発生し、その箇所を修正した際のテスト結果報告は 操作した手順の画面キャプチャを取ることにより お客様に説明が行いやすくなる。 特に修正前と修正後の違いが分かるようにするとなおよい。 文章だけのテスト仕様書だとイメージが湧きづらい。

修正した履歴とその理由は必ず書く

不具合が発生した際、過去に変更した箇所が原因だったりする。 プログラムの修正履歴には修正した内容は書いてあるが、なぜそのような修正をしたか書いていない時がある。 修正した本人がいればいいが、いなかったり、何年も前の修正だと忘れている事が大半。…

お客さんと開発側のギャップ

お客さんとの打ち合わせをしたが、お客さんの要望と開発側でやろうとしていたことにギャップがあった。 要望について、開発側としては工数をどうしても考えてしまう。 そうするとお客さんが望んだものとかけ離れてしまうという事がよくある。 工数を気にせず…

本稼動直後に発生しがちな障害

本稼動直後に発生しがちな障害を何点があげると・・・ ・タイムアウトの頻発 実際のデータ件数を想定せずテストをしてると発生に気付かず何てことがよくある タイムアウト値についても注意が必要 ・NULL値のエラー データに入って来ないと想定してた場合、予…

本稼動後のプログラム修正による影響

本稼動後に発生した障害の対応をする際、気にしなければならないのは修正したことによる影響はどの程度になるかを考えること。 だった一文を変えたとしても、影響が広範囲にわたることがある。 テストパターンをどれぐらいやる必要があるのか、他の機能に影…

デスマーチに陥りやすいパターン

本稼動から1ヶ月、泊まるまでのことはなくなったが、終電間際が続いている。 デスマーチに陥りやすいパターンとしては・・・ 日中発生した障害の対応を行い、夜間にプログうラムのテスト、本番環境へ実装を行う。 →ベンダーとの仕事だと、修正したプログラム…