開発現場に根強く残る8個のバグレポートアンチパターン - Qiita
ex-mixi Advent Calendar 2017 - Qiita 9日目をいただいた @kkakizaki です。 株式会社ミクシィの在籍期間は2008年から2016年までで、 QAマネージャーとして、次々に巻き起こる品質保証上の課題を何とかするお仕事をしていました。 現在は株式会社サイバードにて、同じく品質保証部門の長として、 品質保証だけではない様々な課題解決に勤しんでおります。 折角の ex-mixi なので、今回は この記事 の続きです。 前回の記事は2012年に書かれたものですが、 現在も繊細なエンジニア達が死にやすい状況に変わりはなく、 影響の大きな死因の1つとして「イケてないバグレポート」が存在しています。 BTS にイケてないバグレポートが増殖してしまう現場の方は、 この記事をテスターに叩きつけてやってください。 アンチパターンその1：敬語 テスト業務が受発注関係で
英語によるhadoop系メーリングリストへのバグレポート提出ガイド - 科学と非科学の迷宮
hadoop アドベントカレンダー 2011、1日目及びその他空いているところ全部を担当する @shiumachi です。 27日は誰もいないようなのでこれを27日とします。 id:showyou さんの担当でした。28日目とします。showyou さんすいません 基本 テンプレ的に書くとこんな感じ。 「本来は……であるべきだが、実際にはこうなっている」 前半は should を使い、but/in fact/however/while などを使って逆接でつないで次の文を書く。 以下の項目があるとレスポンスしやすい。 項目名 内容 概要 数行程度で何が起きたか書く 症状 特に、ログに例外が吐かれてたら必ず貼り付けること 直前にどんな作業をしていたか 何か特殊な作業を行っていたら、その手順を書く 再現性の有無 そのまんま 再現方法(わかっていれば) そのまんま 可能なら、該当 conf ファイ
バグレポートはこう書け - バグレポートのための単文集
バグレポートはこう書け - バグレポートのための単文集 バグレポートのための単文集 send-pr とか bugzilla に投げるときとか、なんて書いて いいのかわからんのよね。 というわけで、とにかくいろんな文章をまとめてみる。 心構え バグレポートの目的は何か? バグを伝えることである。 よりよい英語を書くのが目的ではない。拙い英語でもいいから、 とにかく書け。ネイティブスピーカーなら、変な英語でもそれはそれで通じる。 日本語ネイティブは FreeBSD-users-jp:72469 を理解できるっしょ? それと同じ。 I'll take a look at this, as inetd is my problem. (inetd のバグレポートを受けて) inetd の件は俺が仕込んだバグなので、このレポートの面倒みるよ 異議なーし No objection from me. 2台
TOEICで125点しかとれないような人でもできる英文バグレポートの方法。 - tokuhirom's blog
または、Pros と Cons をまちがえて書いてしまうような人でもできる英文バグレポートの方法。 まあ小手先のノウハウだけど、俺はこうやってるよ、という話。 ともかく再現可能なテストケースをかく再現可能なテストケースを書けば、コミュニケーションコストを大幅に削減することが可能。これは日本人同士の場合でもそうだし、プログラマにとっては必須の技能の一つであるから、是非身につけて実践するべき。 マルチスレッドに起因するものなど、再現可能なテストコードがかきづらいものはともかく、それ以外であれば、再現テストコードを書くべき。 再現テストコードを書けない場合、そもそも自分がバグの原因を把握できていない場合がおおいので、そんな状況でなれていない言語によるコミュニケーションをとるのは困難。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
