プログラマーの不機嫌なんてただのお気持ちなんだから無視して良し。むしろ怒らせるくらい細かくチェックした方が品質は上がる。
再現率100%の手順を書いてくれるだけで神デバッガーだけど、人間だから伝え方で脳への負荷が違う
違いは丁寧さじゃなく『相手に求める次の動作』を指定したか否か。Aは命令、Bは質問——バグ報告もタスクの受け渡し、粒度こそ本体では？
デバッガーは自分の仕事してるだけなのにいちいち変な文つける必要なくね?最初の1文だけで十分や
デバッガーがどれだけ信頼されているかにもよると思う。ユーザーからの“バグ報告”って普通に「仕様（または規格）だ。ちゃんと読め」というレベルのものもけっこうあるわけで。
↓Aはお願い・依頼してるだけで命令じゃないし、ただの定型文/Bがバグだとわかると言ってる人もおかしい。鵜呑みにせず仕様や要件を確認しないとだめ。そもそも直接報告してるのが組織としてヤバそう。
そんなんで機嫌悪くなるやつ、俺はお前のママじゃないんだと言え
AIが担うから言葉は統一されるよ
本当に仕様のものとかも多く報告に来るから、Bの方がすぐ納得できるのわかる。問題ないでしょうか？いう質問に対して「問題あります！なおします！」って一旦反応を返せるのもでかい
再現率を言うなら分母の数も言って欲しい派
仕様に無いということまで確認してある情報の違いなのか？
別に機嫌は悪くならないけど、「それがバグかどうか、仕様漏れか、誤解か、前提ミスか、誰担当か」などそう言うの調べるのに軽く30分かかったりする。なおこれが増大するのがAI駆動開発。人間のQAの方が優秀。
自分はBの表現使ってる。「これは意図した挙動ですか？」「◯◯のとき意図しない挙動になるかもです」と99%バグだと思っていてもボカした緩い表現をする。お互いすぐに非を認める信頼関係がある職場なら寸止めで十分
落ちるとかエラーになるとか明らかな問題なら「確認お願いします」だけでいいけど結果だけ渡されて確認しろって言われても何を？ってなるでしょ
仕様の有無を確認してくれるのは助かる。バグっぽく見えても仕様(運用回避含む)の場合もあるし。なんでAとBを比べたらBが上だが、Aでもそんな問題はないようには
「仕様に沿ってない」ってとこまで確認するのが「デバッガー」の仕事なんだからそりゃ A. だとプログラマーが「めんどくさっ」ってなるのもわかる。仕様に沿ってるのにバグ扱いして報告してくる人おるしな。
前文に「バグです」とか、最後に「すぐ修正を」とか、タグに「バグ」とか設定してあるとムム？となるかもだけど、確認依頼の体ならどちらも別に。要件定義漏れならそう伝えるし、仕様外の挙動なら直す行程入るし。
何も判断しない言い回しを嫌う人いるよね、こんなんで機嫌悪くするプログラマー無脳
再現手順は必須として、意図通りの実装及び挙動なのか？と参考にした仕様書の箇所も追記して優先度付けしたらチケットを回そう。健闘を祈る。
A:確認したよ。それで？ B:仕様と違うのではなく仕様にないのね。ならそれが仕様です。／どうあるべきなのかも書いて欲しいし、そもそも間でSEが仕事しろ
確認するかどうかはこっちの自由だ、バカめ！ もとい、一行目だけでいいしバグJIRA的なやつって大体一行目までじゃない？
手順と条件が分かればいいからAで十分な気はする。Bだとしても仕様書の確認はいる気がするし。
人によって受け取り方とか気になるところとか対応とか違うから正解ってないんだなって思った
そのプログラマーが三流もしくはモドキなだけだ。テスターに渡せる仕様書がちゃんとある現場なんてほとんどない（自分は仕様書しっかり書くタイプ）
どっちの言い方でも、再現率100%の方法をセットで教えてくれるなら普通にありがたい。「私の環境では発生します」とかだと「知らん」としか思わない。
別に言い方は何でもいいけど、再現100%の手順さえくれればいいよ
そうか、デバッガーって発注者ではないんだもんな。とすると、編集現場で校正や校閲からの「指摘」でも反応が割れることがある、あれかしら／デザイナーからの相談や質問でもイラつく人とかいるしな。
事実を言っただけなのに機嫌が悪くなるというのでプログラマーが言う側ではなく言われる側なのは珍しい。
なんにせよ「機嫌悪くなる」人と仕事したくないんだよな。いい大人が仕事中に機嫌悪くなるなるなよ。めんどくせえ。
どう考えてもケースバイケースでしょ。あと受け手側の気分。Bの方は場合により慇懃無礼で遠回しにチクチク言われてる気もしてよりイラッとする場合もある。
再現手順があるのは◎、ただし仕様を確認するのはプログラマーではないはずなので、仕様を確認した上で「仕様ではXXのはずですがYYとなります」が望ましい。明確なバグではない場合はほぼ仕様の考慮漏れの印象。
バグ報告は「○○の状況で○○したら、○○になるはずが○○になった」のフォーマットでしてもらってる。言い回しはさておき、○○になるはずの情報が抜けていると報告の意図が伝わりづらい。
Aの書き方だと「上に壁があるときに上キーを押すと上に行かずその場にとどまります」みたいのも含まれちゃうので、仕様と違うとか直感と違うとかバグと判断した理由を付すべきとは思う。機嫌悪くなるこたないが。
100%再現する→大体しない→調べる、調べる、調べる→対応端末外でした→キレる。
どうしても丁寧さではない気がする。観点を示さない、回答の選択肢を示さない「確認をお願いします」って言葉は認知負荷高い。
仕様との不一致を確認するところまでがデバッガーの仕事って事かな。
プログラム組んでた側だけど怒る気持ちがわからない
明らかなバグならAでよいけど、そうでない場合はAだと「何を？」ってなる。基本的に仕事の流れを理解して次の工程に繋がらないコミュニケーションは最悪。プログラマは合理的な思考する人が多いから。
プログラマがまず知りたいのは、仕様かそうでないか。その動作が仕様ならバグじゃない。仕様でないならバグなので直さないと。Aが嫌われるのはプログラマの責務が分かってなさそうだからかも。
バグ報告に余計な文章つけるな。
経験上そうやって連絡が来る時は仕様ですってケースが結構あるので、仕様とどう違うのか、とかどうあるべきなのか、とかを添えてくれる人は仕事してて楽なのはあるよねぇ。
報告テンプレート使えばいいだけの話。Aには「期待していた挙動」を書くべきだけどテンプレートの項目にそれがあれば書かざるを得ないので。
QAテスターは「普通に考えれば問題ないだろう」とかいう独断は厳禁で、仕様書にない挙動は全部仕様質問しろというマニュアルとなっている なので仕様書をちゃんと作ろうね…（戒め）
バグチケットに仕様書リンクして、ここの記述と挙動が合わなくて、正しくはこうなのに実際はこうなっちゃってる、まで書くぞ。なぜなら修正も自分だから遅かれ早かれ全部調べるので。小規模プロジェクトなので。
再現率100％のバグばかりだったら言う方も苦労しないだろうが
「△△が発生します」で何が想定動作なのが伝わらないのが駄目という話でしかないし、普通の現場なら事象と想定動作を書くフォーマットはあるはず
確認して回答しろよ。デバッガーに仕様書や内部文書を全部公開されてるならAIで確認させてから流すだろ、今の時代。その辺隠蔽していてドヤるなよ
手順も発生率もぬけてる報告もあるから、この例だとAでもBでもありがたいけどなあ
実際にちゃんと仕様を確認したなたらせっかくだから伝えたほうがいいよね～。資料と挙動を横並びで見せられればグーノネサンキュー。実は確認してなくて「𝕏でそう言うといいと聞いた」だったらぶっころしますよ🔪❤
ちゃんと不具合報告してくれてるなら怒らない。でも、不具合報告に要望混ぜて出してくるのはちょっとピキッとくる。そういうフェーズは過ぎてるので。
碌な聞き取りもせずに再現率100%って言って求めてる連中ら、自分で書いた分岐条件理解してなさそう
不具合報告にわざわざ敬語で謙って対応のお伺いをたてたりする？普通は「区分」「重要度」「現象」「再現率」「再現方法」「本来の動作」程度を報告して、後は管理者の仕事
別にデバッガーから来てもなんとも思わん。PdMから来たらお前の伝え方が悪い/お前が決めた仕様だろと思うけども
今でいうテスターがデバッガーって呼ばれた時代は確かにあったね、懐かしい。私は社会人1年目は「デバボ (デバッガーボーイ)」て呼ばれてたわ。
100%再現条件の時点で前向き
そもそも報告の方法は指示があるはずでこんな状況にはならないと思うが
医者に患者が疾患名を言うのと似ている。結果バグなのかもしれんが、検証し確定する前に「バグです」とプログラマー以外から言われると「何言ってんの？」という気持ちは解る。
Bでも結局仕様かどうかは自分で確認するわな。情報は気持ちとか曖昧な内容とか入れないで短い方がいい。
AIに聞いたらどっちも機嫌よく対応してくれると思う（ちなみにAIの普及で無くなりやすいと言われてる職業はデバッガーよりプログラマー）
前者は仕様を知ろうともせず、なんか変だからとぶん投げている。後者は仕様と違う事を確認してくれてるので全然違うのは当たり前。
まずは自分でデバッグなんて一切やってないくせにデバッガーなどと名乗るのをやめよう。君は見つけただけだ、直してない。デバッガーというならパッチをよこせ
そのプログラマーがそのコードを書いてないケースだと納得する、すでに前任者はいないわけです
このAB比較はよくわからんが、ワイがシステム開発してた頃は「バグ」といわずに「不具合」というようには徹底してたな
「A という結果を期待して B をしたけど C になります」が満たされてたらほかはあまり気にしないかな。 「仕様にない」よりも何を参照して仕様にないと判断したのか教えてほしい (文書が誤ってる場合もあるので) 。
バグトラックシステムに登録してくれればええんやで
“◯◯で◻︎◻︎すると再現率100%で△△が発生します。ご確認をお願いします。” 期待している事象を伝えような。
どっちでもいいやろ。そのプログラマがめんどくさいやつだという話。バグ報告にもマナー講師が必要なんか？
変なプログラマに当たっただけな気がする
これで本当に不機嫌になるプログラマーなんているのだろうか、適性がないのと違うか
普段のコミュニケーションでもかけ違いはあるけど、仕事になるともっと複雑になっちゃうこともあるんだね〜。
バグ出しておいて機嫌悪くするようなカスは相手する必要ないやろ。バグは出るものとして報告する方もされる方も淡々とやるべき。なんでバグ出した側の機嫌取らないといけないのよ。
外国人居住者数で言うと、東京都豊島区は外国人の割合は既に13%（外国人だけで3.8万人）を越えてる。 大阪府大阪市は外国人の割合は既に7%を越えてる。東京新宿区は14%を越えてる。
「AをしたらBになります」だと「はぁ、そうですけど」となることがあるので、期待結果を書いてほしい。何を期待して「バグ」だと判定してるのかを探る往復が発生すると機嫌が悪くなることもある
仕様確認したけど違うよってのはセットで言ってもらえると助かるが再現方法だけでもめっちゃありがたいやん
“→確認しろだから、受け取って確認して思考して作業のモードにはいる →応答が薄いから機嫌悪く見える” に1票
心底どうでもいいな。そもそもお互い仕事をしているだけの者同士、顔色伺う必要なんぞない。するべき仕事を素早くこなそうぜ。それでプログラマが気分を害しても、そいつの問題だわ。
自分のイメージとは真逆だった 確定な事象について これって仕様ですか？ みたいな確認調で聞かれるのを煽りと感じる人が多い印象を持ってる
どっちにしろ本来期待する結果を併せて書いて欲しくはある。
Aは、んなことある？と思ったけど、「ほんとか？」「100%て何回やったんだよ」「どうせ仕様を知らないだけだろ」が頭に浮かんできた。Bだと、仕様にフォーカスするので直接間違いと指摘されるよりはいいかもね。
「非合理に見えるけど仕様通り」ってケースに該当するかどうか。Bの方が内容が一つ多いもの。
転職後の最初の仕事がバグ出しだった。実力を見極められてたっぽい／テスト計画が不十分、その計画書のレビューも甘い、と指摘した結果「じゃあアナタがやってね」とQAの統括をすることになりました（墓穴）
これプログラマーと話す時は相手の人間性の未熟さを考慮したコミュニケーションが必要と言われてんのになんでわかる〜って喜んでるんだ
これプログラマーだけじゃなくて、普通のコミニュケーションスキルだと思う。相手のミスっぽいものを指摘するときに相手を立てながらというのは大事な事。
その割に向こうは乱暴な物言いだったりする。いや、いま付き合いのある人はめっちゃ親切だけど。
Bは不具合か否かの最終判断をプログラマに委ねている。Aはプログラマの次の行動を指示しているのがウザい、裁量権の侵害に感じるのかも。Aくらいの文面でイラつかんでもいいやんとは思うが。
再現率100%の手順どっちが調べる業務範囲なんだろうな。わりと揉めがち。ロジック知らんしプログラマー側調べるんでしょ。追加資料が必要ならプログラマーからデバッガーに資料採取依頼して切り分けるべきだ。
〇〇という仕様外動作をします。再現手順は以下の通りです。ご確認くださいで十分かな。例示されてるやつだとどっちでもいいです。
断言できるけど間違いなくどっちでも変わらんよ エビデンス、証跡とログだけ載せてくれれば後はなんでもよいです
再現手順を伝えられているのであれば十分に仕事しているし、それ以上は個体差に依存する問題で普遍的な最適解は無いので悩むだけ無駄
バグレポートに期待する反応と実際の結果の差は書いてほしい派です
aは期待値がないので論外。bは「仕様にない」と言っているので期待値を仕様から読めなかったことがわかるので仕様書の抜けの指摘として有効。こうあるべかと提案あるとなお良し。
再現率100%な時点でめっちゃラッキーなケースやんな。こんなんで機嫌悪くなってたらプログラマ失格やわ。
デバッガーがプログラマーにバグ報告をするとき伝え方で反応が全く変わることがあったが何がダメだったんだ？「言っていることは同じ？」「このケースだと明らかに違う」
プログラマーの不機嫌なんてただのお気持ちなんだから無視して良し。むしろ怒らせるくらい細かくチェックした方が品質は上がる。
再現率100%の手順を書いてくれるだけで神デバッガーだけど、人間だから伝え方で脳への負荷が違う
違いは丁寧さじゃなく『相手に求める次の動作』を指定したか否か。Aは命令、Bは質問——バグ報告もタスクの受け渡し、粒度こそ本体では？
デバッガーは自分の仕事してるだけなのにいちいち変な文つける必要なくね?最初の1文だけで十分や
デバッガーがどれだけ信頼されているかにもよると思う。ユーザーからの“バグ報告”って普通に「仕様（または規格）だ。ちゃんと読め」というレベルのものもけっこうあるわけで。
↓Aはお願い・依頼してるだけで命令じゃないし、ただの定型文/Bがバグだとわかると言ってる人もおかしい。鵜呑みにせず仕様や要件を確認しないとだめ。そもそも直接報告してるのが組織としてヤバそう。
そんなんで機嫌悪くなるやつ、俺はお前のママじゃないんだと言え
AIが担うから言葉は統一されるよ
本当に仕様のものとかも多く報告に来るから、Bの方がすぐ納得できるのわかる。問題ないでしょうか？いう質問に対して「問題あります！なおします！」って一旦反応を返せるのもでかい
再現率を言うなら分母の数も言って欲しい派
仕様に無いということまで確認してある情報の違いなのか？
別に機嫌は悪くならないけど、「それがバグかどうか、仕様漏れか、誤解か、前提ミスか、誰担当か」などそう言うの調べるのに軽く30分かかったりする。なおこれが増大するのがAI駆動開発。人間のQAの方が優秀。
自分はBの表現使ってる。「これは意図した挙動ですか？」「◯◯のとき意図しない挙動になるかもです」と99%バグだと思っていてもボカした緩い表現をする。お互いすぐに非を認める信頼関係がある職場なら寸止めで十分
落ちるとかエラーになるとか明らかな問題なら「確認お願いします」だけでいいけど結果だけ渡されて確認しろって言われても何を？ってなるでしょ
仕様の有無を確認してくれるのは助かる。バグっぽく見えても仕様(運用回避含む)の場合もあるし。なんでAとBを比べたらBが上だが、Aでもそんな問題はないようには
「仕様に沿ってない」ってとこまで確認するのが「デバッガー」の仕事なんだからそりゃ A. だとプログラマーが「めんどくさっ」ってなるのもわかる。仕様に沿ってるのにバグ扱いして報告してくる人おるしな。
前文に「バグです」とか、最後に「すぐ修正を」とか、タグに「バグ」とか設定してあるとムム？となるかもだけど、確認依頼の体ならどちらも別に。要件定義漏れならそう伝えるし、仕様外の挙動なら直す行程入るし。
何も判断しない言い回しを嫌う人いるよね、こんなんで機嫌悪くするプログラマー無脳
再現手順は必須として、意図通りの実装及び挙動なのか？と参考にした仕様書の箇所も追記して優先度付けしたらチケットを回そう。健闘を祈る。
A:確認したよ。それで？ B:仕様と違うのではなく仕様にないのね。ならそれが仕様です。／どうあるべきなのかも書いて欲しいし、そもそも間でSEが仕事しろ
確認するかどうかはこっちの自由だ、バカめ！ もとい、一行目だけでいいしバグJIRA的なやつって大体一行目までじゃない？
手順と条件が分かればいいからAで十分な気はする。Bだとしても仕様書の確認はいる気がするし。
人によって受け取り方とか気になるところとか対応とか違うから正解ってないんだなって思った
そのプログラマーが三流もしくはモドキなだけだ。テスターに渡せる仕様書がちゃんとある現場なんてほとんどない（自分は仕様書しっかり書くタイプ）
どっちの言い方でも、再現率100%の方法をセットで教えてくれるなら普通にありがたい。「私の環境では発生します」とかだと「知らん」としか思わない。
別に言い方は何でもいいけど、再現100%の手順さえくれればいいよ
そうか、デバッガーって発注者ではないんだもんな。とすると、編集現場で校正や校閲からの「指摘」でも反応が割れることがある、あれかしら／デザイナーからの相談や質問でもイラつく人とかいるしな。
事実を言っただけなのに機嫌が悪くなるというのでプログラマーが言う側ではなく言われる側なのは珍しい。
なんにせよ「機嫌悪くなる」人と仕事したくないんだよな。いい大人が仕事中に機嫌悪くなるなるなよ。めんどくせえ。
どう考えてもケースバイケースでしょ。あと受け手側の気分。Bの方は場合により慇懃無礼で遠回しにチクチク言われてる気もしてよりイラッとする場合もある。
再現手順があるのは◎、ただし仕様を確認するのはプログラマーではないはずなので、仕様を確認した上で「仕様ではXXのはずですがYYとなります」が望ましい。明確なバグではない場合はほぼ仕様の考慮漏れの印象。
バグ報告は「○○の状況で○○したら、○○になるはずが○○になった」のフォーマットでしてもらってる。言い回しはさておき、○○になるはずの情報が抜けていると報告の意図が伝わりづらい。
Aの書き方だと「上に壁があるときに上キーを押すと上に行かずその場にとどまります」みたいのも含まれちゃうので、仕様と違うとか直感と違うとかバグと判断した理由を付すべきとは思う。機嫌悪くなるこたないが。
100%再現する→大体しない→調べる、調べる、調べる→対応端末外でした→キレる。
どうしても丁寧さではない気がする。観点を示さない、回答の選択肢を示さない「確認をお願いします」って言葉は認知負荷高い。
仕様との不一致を確認するところまでがデバッガーの仕事って事かな。
プログラム組んでた側だけど怒る気持ちがわからない
明らかなバグならAでよいけど、そうでない場合はAだと「何を？」ってなる。基本的に仕事の流れを理解して次の工程に繋がらないコミュニケーションは最悪。プログラマは合理的な思考する人が多いから。
プログラマがまず知りたいのは、仕様かそうでないか。その動作が仕様ならバグじゃない。仕様でないならバグなので直さないと。Aが嫌われるのはプログラマの責務が分かってなさそうだからかも。
バグ報告に余計な文章つけるな。
経験上そうやって連絡が来る時は仕様ですってケースが結構あるので、仕様とどう違うのか、とかどうあるべきなのか、とかを添えてくれる人は仕事してて楽なのはあるよねぇ。
報告テンプレート使えばいいだけの話。Aには「期待していた挙動」を書くべきだけどテンプレートの項目にそれがあれば書かざるを得ないので。
QAテスターは「普通に考えれば問題ないだろう」とかいう独断は厳禁で、仕様書にない挙動は全部仕様質問しろというマニュアルとなっている なので仕様書をちゃんと作ろうね…（戒め）
バグチケットに仕様書リンクして、ここの記述と挙動が合わなくて、正しくはこうなのに実際はこうなっちゃってる、まで書くぞ。なぜなら修正も自分だから遅かれ早かれ全部調べるので。小規模プロジェクトなので。
再現率100％のバグばかりだったら言う方も苦労しないだろうが
「△△が発生します」で何が想定動作なのが伝わらないのが駄目という話でしかないし、普通の現場なら事象と想定動作を書くフォーマットはあるはず
確認して回答しろよ。デバッガーに仕様書や内部文書を全部公開されてるならAIで確認させてから流すだろ、今の時代。その辺隠蔽していてドヤるなよ
手順も発生率もぬけてる報告もあるから、この例だとAでもBでもありがたいけどなあ
実際にちゃんと仕様を確認したなたらせっかくだから伝えたほうがいいよね～。資料と挙動を横並びで見せられればグーノネサンキュー。実は確認してなくて「𝕏でそう言うといいと聞いた」だったらぶっころしますよ🔪❤
ちゃんと不具合報告してくれてるなら怒らない。でも、不具合報告に要望混ぜて出してくるのはちょっとピキッとくる。そういうフェーズは過ぎてるので。
碌な聞き取りもせずに再現率100%って言って求めてる連中ら、自分で書いた分岐条件理解してなさそう
不具合報告にわざわざ敬語で謙って対応のお伺いをたてたりする？普通は「区分」「重要度」「現象」「再現率」「再現方法」「本来の動作」程度を報告して、後は管理者の仕事
別にデバッガーから来てもなんとも思わん。PdMから来たらお前の伝え方が悪い/お前が決めた仕様だろと思うけども
今でいうテスターがデバッガーって呼ばれた時代は確かにあったね、懐かしい。私は社会人1年目は「デバボ (デバッガーボーイ)」て呼ばれてたわ。
100%再現条件の時点で前向き
そもそも報告の方法は指示があるはずでこんな状況にはならないと思うが
医者に患者が疾患名を言うのと似ている。結果バグなのかもしれんが、検証し確定する前に「バグです」とプログラマー以外から言われると「何言ってんの？」という気持ちは解る。
Bでも結局仕様かどうかは自分で確認するわな。情報は気持ちとか曖昧な内容とか入れないで短い方がいい。
AIに聞いたらどっちも機嫌よく対応してくれると思う（ちなみにAIの普及で無くなりやすいと言われてる職業はデバッガーよりプログラマー）
前者は仕様を知ろうともせず、なんか変だからとぶん投げている。後者は仕様と違う事を確認してくれてるので全然違うのは当たり前。
まずは自分でデバッグなんて一切やってないくせにデバッガーなどと名乗るのをやめよう。君は見つけただけだ、直してない。デバッガーというならパッチをよこせ
そのプログラマーがそのコードを書いてないケースだと納得する、すでに前任者はいないわけです
このAB比較はよくわからんが、ワイがシステム開発してた頃は「バグ」といわずに「不具合」というようには徹底してたな
「A という結果を期待して B をしたけど C になります」が満たされてたらほかはあまり気にしないかな。 「仕様にない」よりも何を参照して仕様にないと判断したのか教えてほしい (文書が誤ってる場合もあるので) 。
バグトラックシステムに登録してくれればええんやで
“◯◯で◻︎◻︎すると再現率100%で△△が発生します。ご確認をお願いします。” 期待している事象を伝えような。
どっちでもいいやろ。そのプログラマがめんどくさいやつだという話。バグ報告にもマナー講師が必要なんか？
変なプログラマに当たっただけな気がする
これで本当に不機嫌になるプログラマーなんているのだろうか、適性がないのと違うか
普段のコミュニケーションでもかけ違いはあるけど、仕事になるともっと複雑になっちゃうこともあるんだね〜。
バグ出しておいて機嫌悪くするようなカスは相手する必要ないやろ。バグは出るものとして報告する方もされる方も淡々とやるべき。なんでバグ出した側の機嫌取らないといけないのよ。
外国人居住者数で言うと、東京都豊島区は外国人の割合は既に13%（外国人だけで3.8万人）を越えてる。 大阪府大阪市は外国人の割合は既に7%を越えてる。東京新宿区は14%を越えてる。
「AをしたらBになります」だと「はぁ、そうですけど」となることがあるので、期待結果を書いてほしい。何を期待して「バグ」だと判定してるのかを探る往復が発生すると機嫌が悪くなることもある
仕様確認したけど違うよってのはセットで言ってもらえると助かるが再現方法だけでもめっちゃありがたいやん
“→確認しろだから、受け取って確認して思考して作業のモードにはいる →応答が薄いから機嫌悪く見える” に1票
心底どうでもいいな。そもそもお互い仕事をしているだけの者同士、顔色伺う必要なんぞない。するべき仕事を素早くこなそうぜ。それでプログラマが気分を害しても、そいつの問題だわ。
自分のイメージとは真逆だった 確定な事象について これって仕様ですか？ みたいな確認調で聞かれるのを煽りと感じる人が多い印象を持ってる
どっちにしろ本来期待する結果を併せて書いて欲しくはある。
Aは、んなことある？と思ったけど、「ほんとか？」「100%て何回やったんだよ」「どうせ仕様を知らないだけだろ」が頭に浮かんできた。Bだと、仕様にフォーカスするので直接間違いと指摘されるよりはいいかもね。
「非合理に見えるけど仕様通り」ってケースに該当するかどうか。Bの方が内容が一つ多いもの。
転職後の最初の仕事がバグ出しだった。実力を見極められてたっぽい／テスト計画が不十分、その計画書のレビューも甘い、と指摘した結果「じゃあアナタがやってね」とQAの統括をすることになりました（墓穴）
これプログラマーと話す時は相手の人間性の未熟さを考慮したコミュニケーションが必要と言われてんのになんでわかる〜って喜んでるんだ
これプログラマーだけじゃなくて、普通のコミニュケーションスキルだと思う。相手のミスっぽいものを指摘するときに相手を立てながらというのは大事な事。
その割に向こうは乱暴な物言いだったりする。いや、いま付き合いのある人はめっちゃ親切だけど。
Bは不具合か否かの最終判断をプログラマに委ねている。Aはプログラマの次の行動を指示しているのがウザい、裁量権の侵害に感じるのかも。Aくらいの文面でイラつかんでもいいやんとは思うが。
再現率100%の手順どっちが調べる業務範囲なんだろうな。わりと揉めがち。ロジック知らんしプログラマー側調べるんでしょ。追加資料が必要ならプログラマーからデバッガーに資料採取依頼して切り分けるべきだ。
〇〇という仕様外動作をします。再現手順は以下の通りです。ご確認くださいで十分かな。例示されてるやつだとどっちでもいいです。
断言できるけど間違いなくどっちでも変わらんよ エビデンス、証跡とログだけ載せてくれれば後はなんでもよいです
再現手順を伝えられているのであれば十分に仕事しているし、それ以上は個体差に依存する問題で普遍的な最適解は無いので悩むだけ無駄
バグレポートに期待する反応と実際の結果の差は書いてほしい派です
aは期待値がないので論外。bは「仕様にない」と言っているので期待値を仕様から読めなかったことがわかるので仕様書の抜けの指摘として有効。こうあるべかと提案あるとなお良し。
再現率100%な時点でめっちゃラッキーなケースやんな。こんなんで機嫌悪くなってたらプログラマ失格やわ。