アカウント名:
パスワード:
他の大手と違って、これまで企業合併・統合しつつも、システム面やサービス、業務を全然整理できていない状態なんだから、来いって言われても困るだろうな
そもそも自分とこの子会社が上手く立ちまわったり仕切れないのに、いらん事ばっか主張してくるもんだから、ベンダーも自分の責任にされたくないって方向に向いちゃうと思うし一過性の増員要請に対して、ベンダーがその後に何を期待できんの？って事もあるし
既に何年も経ってるのに、未だに合併前の基幹システムは温存させちゃうってたりとか、設計書の無いサブシステムだらけとか、イレギュラーな処理を無理やりカスタマイズで延命させてたりとか、どこを見ても不幸なレールしか見えないってのは、なかなかないと思うんだよね更に付け加えると、ベンダーやソフトハウスをどれだけ大事にしているかという所も大きいと思うし
問題はどこにあるのかってのを経営陣もわからんといかんと思うんだよなあ
ゼロベースで新しく作って，古いほうと並行して動かす．どちらへも同じ入力が行くが，新しいほうからの出力は古いほうからの出力と比較するのみ．違いがあったら新しいほうを修正する．実際に使うのは古いほうからの出力だけ，というのを１年間続けてから移行，とかできないかな．川人先生の本にあった，小脳のモデルのように．
ああ、こないだ行ってた金融系の職場で同じ事言ってたなあ。結構大量に修正して、どうやってテストするんだと思ったら、「前と同じ出力が出たらOKとする」とか言い出したので、目の前の人間が正気なのかわからなくなった。テスト仕様書は「〜が正しく動くこと」の連続で、それで疑問を感じてなかったようだし。逃げられてよかった。しかし、比較的新しい銀行のシステムのはずなのだが....。
銀行じゃないですけど, 金融系のシステムでその方式でテストをして, オリジナルのシステムの潜在バグを見つけたことがあります. 対処方法は…オリジナルにあわせてバグを作り込むことでした.
数年後, そのユーザには金融庁の監査が入り, 処分を受けました.
># ところで現新一致のテストってそんなに不思議ですかね？いや、入力データのパターンとかなんにも考えてなかったみたいなんで。#少なくとも明記はされていない。真面目にやるととんでもない事になってるはずなんだが。適当に動かしてみて、同じように見えたらOKと考えていたんじゃないかなあ。そう考えていたとしか思えん。
モンキーテストってのもあるけどね。まあそれは普通追加分。
> 「前と同じ出力が出たらOKとする」とか言い出したので、目の前の人間が正気なのかわからなくなった。> テスト仕様書は「～が正しく動くこと」の連続で、それで疑問を感じてなかったようだし。
発注する金融系の会社の人としては、普通じゃない？いうなれば要求仕様書から出せるテスト仕様なんてそんなもん。
あなたがまともだと考えてるテスト仕様書って、設計からしか起こせないもののことじゃないかな。そんなの金融会社の社員が作れるわけないでしょ。
すいません、後出しジャンケンみたいで申し訳ないのですが、「前と同じ出力が出たらOKとする」「〜が正しく動くこと」でOKとしていたのは、ユーザではなくて、設計レベルでの動作責任を負う（はずの）立場の人でした。
ユーザに対して、要求仕様を満たしているかという確認でも、もう少しディテールは付けます。完全は無理としても、「正しく」とは何か？ぐらいはある程度言及しないと、命がいくらあっても足りません。「同じ出力」にしても、どの点を見て同じとみなすかはある程度言及しておかないとまずいでしょう。
不備があったとしても、どこに不備があったか判るだけましです。確認項目に「正しく〜」なんて記述しか残ってなかったら、テストは全部やり直しと言われても仕方がありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
同じ金融系でも (スコア:0)
他の大手と違って、これまで企業合併・統合しつつも、システム面やサービス、業務を全然整理できていない状態なんだから、来いって言われても困るだろうな
そもそも自分とこの子会社が上手く立ちまわったり仕切れないのに、いらん事ばっか主張してくるもんだから、ベンダーも自分の責任にされたくないって方向に向いちゃうと思うし
一過性の増員要請に対して、ベンダーがその後に何を期待できんの？って事もあるし
既に何年も経ってるのに、未だに合併前の基幹システムは温存させちゃうってたりとか、設計書の無いサブシステムだらけとか、イレギュラーな処理を無理やりカスタマイズで延命させてたりとか、どこを見ても不幸なレールしか見えないってのは、なかなかないと思うんだよね
更に付け加えると、ベンダーやソフトハウスをどれだけ大事にしているかという所も大きいと思うし
問題はどこにあるのかってのを経営陣もわからんといかんと思うんだよなあ
Re: (スコア:0)
ゼロベースで新しく作って，古いほうと並行して動かす．どちらへも同じ入力が行くが，新しいほうからの出力は古いほうからの出力と比較するのみ．
違いがあったら新しいほうを修正する．実際に使うのは古いほうからの出力だけ，というのを１年間続けてから移行，とかできないかな．
川人先生の本にあった，小脳のモデルのように．
Re:同じ金融系でも (スコア:2, 興味深い)
ああ、こないだ行ってた金融系の職場で同じ事言ってたなあ。
結構大量に修正して、どうやってテストするんだと思ったら、
「前と同じ出力が出たらOKとする」とか言い出したので、目の前の人間が正気なのかわからなくなった。
テスト仕様書は「〜が正しく動くこと」の連続で、それで疑問を感じてなかったようだし。
逃げられてよかった。
しかし、比較的新しい銀行のシステムのはずなのだが....。
Re:同じ金融系でも (スコア:2)
銀行じゃないですけど, 金融系のシステムでその方式でテストをして, オリジナルのシステムの潜在バグを見つけたことがあります. 対処方法は…オリジナルにあわせてバグを作り込むことでした.
数年後, そのユーザには金融庁の監査が入り, 処分を受けました.
Re: (スコア:0)
コンテンジェンシープランみたいなもんでしょうかね。
実際のデータで動作確認・負荷テストできるなんて理に適ってるといえばそうかもしれません。
そんなに気軽に本番データつかっていいかとか問題もあるでしょうが。
規模が大きくてミッションクリティカルであるならやる価値はあるとは思いますが、でもまぁ不思議とそういうテストで自信満々になっていると並行稼働終わった途端にレアバグが…とかありがちですよね。
# ところで現新一致のテストってそんなに不思議ですかね？
# 「～が正しく動くこと」てのはだれのさじ加減だって感じですけど。
Re: (スコア:0)
># ところで現新一致のテストってそんなに不思議ですかね？
いや、入力データのパターンとかなんにも考えてなかったみたいなんで。
#少なくとも明記はされていない。真面目にやるととんでもない事になってるはずなんだが。
適当に動かしてみて、同じように見えたらOKと考えていたんじゃないかなあ。そう考えていたとしか思えん。
Re: (スコア:0)
修正箇所を通過するはずとかデグレチェックといったパターンも決めずに数だけやっても願掛けにしかならないですもんね。
Re: (スコア:0)
モンキーテストってのもあるけどね。
まあそれは普通追加分。
Re: (スコア:0)
> 「前と同じ出力が出たらOKとする」とか言い出したので、目の前の人間が正気なのかわからなくなった。
> テスト仕様書は「～が正しく動くこと」の連続で、それで疑問を感じてなかったようだし。
発注する金融系の会社の人としては、普通じゃない？
いうなれば要求仕様書から出せるテスト仕様なんてそんなもん。
あなたがまともだと考えてるテスト仕様書って、設計からしか起こせないもののことじゃないかな。
そんなの金融会社の社員が作れるわけないでしょ。
Re: (スコア:0)
いくら引き出しても残高の減らない通帳とか預金者としてはとても正しい動作をしてると思うけど、そういうのはダメなんでしょ。だったらそれを書かなきゃ。
Re: (スコア:0)
すいません、後出しジャンケンみたいで申し訳ないのですが、
「前と同じ出力が出たらOKとする」「〜が正しく動くこと」でOKとしていたのは、ユーザではなくて、
設計レベルでの動作責任を負う（はずの）立場の人でした。
ユーザに対して、要求仕様を満たしているかという確認でも、もう少しディテールは付けます。
完全は無理としても、「正しく」とは何か？ぐらいはある程度言及しないと、命がいくらあっても足りません。
「同じ出力」にしても、どの点を見て同じとみなすかはある程度言及しておかないとまずいでしょう。
不備があったとしても、どこに不備があったか判るだけましです。
確認項目に「正しく〜」なんて記述しか残ってなかったら、テストは全部やり直しと言われても仕方がありません。