工期、予算に制限あると異常系が雑になりがち。。。
雑に設計していいのではなくて、異常のキャッチは必要なのでそんなに楽にはならないよなあ
東急の電車の事故も、電車がはみ出してる異常時のテストをやってれば事前にわかったはず。
とはいえどんな異常が起こるかは想定しきれないので漏れるのはどうしようもない
言葉遊びに見える
とはいえ、「極めて稀にしか発生しない軽微な異常」なら漏れていても仕方ない。デメリットとコストのバランスをどこで取るかはマネジメント側の判断となる。
正常系のレアケースやパフォーマンス、セキュリティ等の考慮が漏れてる事も有る。
「動けばヨシ！」→後で大炎上、これ様式美なw
テスラのEVとかこれに当てはまるか……発火時にドアの開け方が分からず焼死した事例あったしなぁ
私が若いころ同じ現場にいた熟練のSEの言葉「正常系なんてサルでも書けるんですよ」。今でもふとした時に思い出す。
「漏れても仕方ない」で納得してくれる菩薩のような客など存在しない。
まあ、ここに来ることはないっしょってとこは大体３年後くらいに着火する
ちゃんと異常系もテスト項目作っておくのが大事。テスト駆動開発ならテストケースしっかり作らなければ
壁打ちでアイデアをAIに伝えて考慮漏れを挙げてもらう、って使い方もされるわけで、AIが判断できる材料を渡すのをサボらなければ、そのうちできる気はする。誰かの頭の中から引っ張り出した後は正常系と変わらない。
こいつらなにいってんの？感しかない。何でこんな処理にこんな工数かかるのって言われる時の相手の想定はこんな感じだけど、エンジニア側がこれなのはマジでわからん
今日コードイイじゃん♪ 動けばイイじゃん♪ めちゃくちゃイイじゃん♪ Ummm イイじゃん♪ みんなみんなイイじゃん♪ らしくってイイじゃん♪ 怒られてるんじゃん? Ummm イイじゃん♪
PoCとか言って正常系の機能評価したあと異常系の考慮も運用フェーズの要件も考慮しないでいつの間にか実運用しようとする怖いシステム
異常系テストですか？今実施してますよ
ど素人の私が作るようなコードですね。それでプロなんですか。
データも処理も正しくて普通は落ちる訳ないものでも、ネットワークエラーやらハード故障やらで処理が死ぬ可能性は普通にある訳で...
動けばいいじゃん（ただし不具合、仕様漏れはゼロとする）
そらテストなんて異常系をやらないと意味ないだろ。正常系でエラー出るなら受け入れすらできないんだから
（正常系で）動けばいいじゃんなので、異常系の事を考えてること自体が異常系。
しかも開発期間がやたら短い場合の「動けばいいじゃん」は、ほぼ必然的に異常発生が多発する。まぁ開発者の知ったことではないので、運用で頑張ってカバーすればいい。開発者としてはどうしようもない
今のプログラマってテストケースの考え方やカバレッジって習わないの？
△異常を想定する ○取り得る入力パターンを出す、想定している入力でなければそこで落とす、突発的なエラーを拾う/動けばヨシは正常系通すことしか考えずコスト削減している状態なんは確か
「動けばいい」話をしてるのに、異常系の話ってどういうこと？「動く」の定義から始めましょうか。
だろう運転より、かもしれない運転。システム開発にも免許が必要だよな。
工期が短いなら当然こうなるので、マネジメント層が意図してやっている。運用でテストすればいいと思っている。保守や運用担当者には相応の負担がかかる
運用でカバーという金言
やばげなシステムは想定の網羅性の検証にこそ時間をかけますからぬ
まず、異常系から作ってそれに引っかからずに通るルートが正常系になるんや。(極論)
リスクアセスメントして優先順位を決める必要があるのでは？ リスクの発生頻度と重大性で評価する手法。気が付いた異常系は全部対応なんてやりきれないので。
まぁ上流でどれぐらいユースケースを具体的に想像できているかだよな。
セキュリティとバグ潰しに自信がないので、プログラミングは趣味だけにしている。あと、個人情報を扱うサイトは作らない。
そらそやろ。
最近のテストって、正常系と異常系といってるけど、その異常って想定された例外の範囲で、実質昔の正常系テストの範囲なのよね。本来の異常系ってのは想定外の事例が発生した場合の事を指し、その時にどうするかの話
異常系とは突き詰めれば正常系なのである
どの開発のどの段階で言う話なのか、どんな目的なのかによるとしか言えん。アジャイルはまるで関係ない。まじ風評。
異常系の管理と設計って何気に大変なんよな。
ベンダーによる正常系のテストも漏れていたため地獄を見たビジネスサイドがいますよ それはテストなのか
製品・工学に限らない。甘い制度設計、性善説での運用、いつの間にか超えてる安全ライン…人間は正常性バイアスの奴隷で、確率思考もリスク見積りも苦手。「発生したこの異常系を、誰も考慮していないのである！」
お金と時間しだいじゃないの
運用でカバーできるなら別に構わないけど、そういうのってシステムというよりツールレベルの話だと思うんだけどな
「故障」の定義を「一切応答しない」とした奴が考えたトランザクションとか
ソフトウェア開発のセルフアセスメントを支援する生成AIの研究があったなと https://www.juse.or.jp/sqip/workshop/report/attachs/2024/1_Self-Assessor_本文.pdf
“ 動けばいーじゃん”という前提があるなら異常系は気にしなくていい。前提と違う機能を作り込んでも過剰品質。前提(仮定)が偽だと言うなら何を結論にもってきてもそれは真になるので、まず前提をどうにかしてもろて
異常系より性能テストが面倒だしヒヤヒヤする
ヘボプログラマーが何か言ってやがる。異常系で本当に大変なのは、以上の原因が特定できるログ設計。これが不要なシステムなら異常系なんて簡単だ。ストンと落ちればsystemctlが再起動してくれる。
うごけばいいってプロトタイプの段階の話では？異常系について客と議論するとかじゃなきゃ考えないよ
異常系の考慮の漏れではなく、そもそもユースケース漏れが起こってるから異常系に落とし込まれないってだけなんだが。
だ、だって「動けばいい」って言われたし…。
オーバーエンジニアリングしすぎんなーってこの時代に、こういう話を見るととても味わい深い
マネージャーが判断すればいいというが人間は将来のリスクを正しく認識する事が苦手なので、まあうまくいくことは少ないよ
異常、準正常の両方考慮できないと今のクラウドAPIを使うことすらままならない
「絶対に問題になる」と進言して「コストがない」と断られたことがあるが、案の定損害賠償沙汰まで発展して部署が解散になったことがある。馬鹿じゃないかと思った。
システムのテスト、『動けばいいじゃん』っていうときは高確率で異常系の考慮が漏れている「万が一異常が発生した際にどうしてこうなったんだ！？って怒られるやつ」
工期、予算に制限あると異常系が雑になりがち。。。
雑に設計していいのではなくて、異常のキャッチは必要なのでそんなに楽にはならないよなあ
東急の電車の事故も、電車がはみ出してる異常時のテストをやってれば事前にわかったはず。
とはいえどんな異常が起こるかは想定しきれないので漏れるのはどうしようもない
言葉遊びに見える
とはいえ、「極めて稀にしか発生しない軽微な異常」なら漏れていても仕方ない。デメリットとコストのバランスをどこで取るかはマネジメント側の判断となる。
正常系のレアケースやパフォーマンス、セキュリティ等の考慮が漏れてる事も有る。
「動けばヨシ！」→後で大炎上、これ様式美なw
テスラのEVとかこれに当てはまるか……発火時にドアの開け方が分からず焼死した事例あったしなぁ
私が若いころ同じ現場にいた熟練のSEの言葉「正常系なんてサルでも書けるんですよ」。今でもふとした時に思い出す。
「漏れても仕方ない」で納得してくれる菩薩のような客など存在しない。
まあ、ここに来ることはないっしょってとこは大体３年後くらいに着火する
ちゃんと異常系もテスト項目作っておくのが大事。テスト駆動開発ならテストケースしっかり作らなければ
壁打ちでアイデアをAIに伝えて考慮漏れを挙げてもらう、って使い方もされるわけで、AIが判断できる材料を渡すのをサボらなければ、そのうちできる気はする。誰かの頭の中から引っ張り出した後は正常系と変わらない。
こいつらなにいってんの？感しかない。何でこんな処理にこんな工数かかるのって言われる時の相手の想定はこんな感じだけど、エンジニア側がこれなのはマジでわからん
今日コードイイじゃん♪ 動けばイイじゃん♪ めちゃくちゃイイじゃん♪ Ummm イイじゃん♪ みんなみんなイイじゃん♪ らしくってイイじゃん♪ 怒られてるんじゃん? Ummm イイじゃん♪
PoCとか言って正常系の機能評価したあと異常系の考慮も運用フェーズの要件も考慮しないでいつの間にか実運用しようとする怖いシステム
異常系テストですか？今実施してますよ
ど素人の私が作るようなコードですね。それでプロなんですか。
データも処理も正しくて普通は落ちる訳ないものでも、ネットワークエラーやらハード故障やらで処理が死ぬ可能性は普通にある訳で...
動けばいいじゃん（ただし不具合、仕様漏れはゼロとする）
そらテストなんて異常系をやらないと意味ないだろ。正常系でエラー出るなら受け入れすらできないんだから
（正常系で）動けばいいじゃんなので、異常系の事を考えてること自体が異常系。
しかも開発期間がやたら短い場合の「動けばいいじゃん」は、ほぼ必然的に異常発生が多発する。まぁ開発者の知ったことではないので、運用で頑張ってカバーすればいい。開発者としてはどうしようもない
今のプログラマってテストケースの考え方やカバレッジって習わないの？
△異常を想定する ○取り得る入力パターンを出す、想定している入力でなければそこで落とす、突発的なエラーを拾う/動けばヨシは正常系通すことしか考えずコスト削減している状態なんは確か
「動けばいい」話をしてるのに、異常系の話ってどういうこと？「動く」の定義から始めましょうか。
だろう運転より、かもしれない運転。システム開発にも免許が必要だよな。
工期が短いなら当然こうなるので、マネジメント層が意図してやっている。運用でテストすればいいと思っている。保守や運用担当者には相応の負担がかかる
運用でカバーという金言
やばげなシステムは想定の網羅性の検証にこそ時間をかけますからぬ
まず、異常系から作ってそれに引っかからずに通るルートが正常系になるんや。(極論)
リスクアセスメントして優先順位を決める必要があるのでは？ リスクの発生頻度と重大性で評価する手法。気が付いた異常系は全部対応なんてやりきれないので。
まぁ上流でどれぐらいユースケースを具体的に想像できているかだよな。
セキュリティとバグ潰しに自信がないので、プログラミングは趣味だけにしている。あと、個人情報を扱うサイトは作らない。
そらそやろ。
最近のテストって、正常系と異常系といってるけど、その異常って想定された例外の範囲で、実質昔の正常系テストの範囲なのよね。本来の異常系ってのは想定外の事例が発生した場合の事を指し、その時にどうするかの話
異常系とは突き詰めれば正常系なのである
どの開発のどの段階で言う話なのか、どんな目的なのかによるとしか言えん。アジャイルはまるで関係ない。まじ風評。
異常系の管理と設計って何気に大変なんよな。
ベンダーによる正常系のテストも漏れていたため地獄を見たビジネスサイドがいますよ それはテストなのか
製品・工学に限らない。甘い制度設計、性善説での運用、いつの間にか超えてる安全ライン…人間は正常性バイアスの奴隷で、確率思考もリスク見積りも苦手。「発生したこの異常系を、誰も考慮していないのである！」
お金と時間しだいじゃないの
運用でカバーできるなら別に構わないけど、そういうのってシステムというよりツールレベルの話だと思うんだけどな
「故障」の定義を「一切応答しない」とした奴が考えたトランザクションとか
ソフトウェア開発のセルフアセスメントを支援する生成AIの研究があったなと https://www.juse.or.jp/sqip/workshop/report/attachs/2024/1_Self-Assessor_本文.pdf
“ 動けばいーじゃん”という前提があるなら異常系は気にしなくていい。前提と違う機能を作り込んでも過剰品質。前提(仮定)が偽だと言うなら何を結論にもってきてもそれは真になるので、まず前提をどうにかしてもろて
異常系より性能テストが面倒だしヒヤヒヤする
ヘボプログラマーが何か言ってやがる。異常系で本当に大変なのは、以上の原因が特定できるログ設計。これが不要なシステムなら異常系なんて簡単だ。ストンと落ちればsystemctlが再起動してくれる。
うごけばいいってプロトタイプの段階の話では？異常系について客と議論するとかじゃなきゃ考えないよ
異常系の考慮の漏れではなく、そもそもユースケース漏れが起こってるから異常系に落とし込まれないってだけなんだが。
だ、だって「動けばいい」って言われたし…。
オーバーエンジニアリングしすぎんなーってこの時代に、こういう話を見るととても味わい深い
マネージャーが判断すればいいというが人間は将来のリスクを正しく認識する事が苦手なので、まあうまくいくことは少ないよ
異常、準正常の両方考慮できないと今のクラウドAPIを使うことすらままならない
「絶対に問題になる」と進言して「コストがない」と断られたことがあるが、案の定損害賠償沙汰まで発展して部署が解散になったことがある。馬鹿じゃないかと思った。