テスターが開発現場にいることのメリット - CAT GETTING OUT OF A BAG
MTBF（平均故障間隔）とかMTTR（平均修理時間）とか、世の中には品質をあらわすための指標が数多く存在するようですが「バグを発見してからプログラマーに伝わるまでの時間」という指標は、あるのかな？ わたしたちのチームは、これが圧倒的に早いです。 といっても、どこかと比較したことはないのだけど、どれくらい圧倒的に早いのか、最近のツイートに補足しながら説明します。 テスターが開発現場にいるときの場合 プログレスダイアログ関連のテスト中にクラッシュしたのでその場でプログラマー(←エース級)に見せたら「お見事！」て言われて（お見事！なんて初めて言われた…しかもエースに…）とログを取るエースの横で感動してたのだけど数時間後にはコミットされ今日はもう直ってた。バグは一瞬だけ光り輝く。— miwa (@miwa719) 2016年5月26日 テストしていると（はて、これはこういう仕様なのか、それともバグ
ベテランプログラマーとバグの調査をしたときのこと - CAT GETTING OUT OF A BAG
隣のチームのベテランプログラマーSさんとバグの調査（どの操作が引き金になってるのか）をしたんだけど、特定するまでの時間が（わたし一人でやるより）断然早くて素晴らしかったな。しかもSさん、いちいち悲鳴あげるから（ああ、こういうのがソフトウェアにとって嫌なのか）が分かって良かったです。— miwa (@miwa719) 2018年8月3日 これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作（入力）が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2 プログラマーに状況を説明する おかしな状態になる前に、どんな操作（入力）をしていたのか。たまたま、関係しそうな画面を４枚ほどキャプチャーしていたので、それを１枚ずつ見せ
チームでテストを共有した話（テストの地図） - CAT GETTING OUT OF A BAG
探索的テストを含む「テスト」をチームで共有したときに、やってみたことを紹介します。キーワードはこの４つ。 ・テストの地図（今回はこれ！） ・ペアテスト ・テストの渡航履歴 ・朝会とテストの夕会 チームでテストを共有した話 「テストの地図」はテストチャーター（のようなもの）を想像してください。 つくりはじめるタイミングは、ざっくりしたユーザー要件と、大雑把な仕様が出てきて「これから○○という機能を作りはじめるよー」というくらいのときです（プログラマーが実装してからだと遅い）。「テストの地図」は、国境と国名と主要な都市くらいしかない、白地図のようなものから、はじまります。 「こんなものを作るんだよね？」 「ここはこんなふるまいをするのかな？」 「仮にユーザーがこういう使い方をするとして、どうなるのがいいんだろう？」 「これまでのデータの持ち方を変えたりする？」 「前にこんなバグ、あったよね」
『テストエンジニアの面接の際にするとよい20の質問』以前の話 - CAT GETTING OUT OF A BAG
先週の金曜日にこんなことがあった。 いつものように、あるストーリーをcloseするためのテストをしていたのだけど、確認している最中に、テスト対象のプロセスが突然終了してしまった。もうこれだけでNGなんだけど、このシステムは特に複雑でね、これまでも不具合の本質的な原因が”スコープ外”と言うのかな、わたしたちが開発している部分の外側にあることが少なくない。 でもまあ、システムを使うお客様からしてみればそんなことはどうでもよくて、やりたいことができないのは、大問題ですよね。 現象が発生した直後、プログラマーMさんに見てもらい必要なログを採取してもらったのだけど、午後もやっぱりおかしい。午前中に問題が発生したときと見た目の現象はほぼ同じなのだけど、プロセスは残っている。かと思えば、うまく動くときもあってね。これは厄介だな…。 周りを見渡したらMさんはいなくて、プログラマーSさんに午前中の状況も話し
品質特性とバグの聞こえる化 - CAT GETTING OUT OF A BAG
午前中に見つかったクリティカルな問題が、お昼休み前には原因が分かり一安心。 会話(問題が起きる前にどんなことをしていたか)とログでだいたいのことは分かるんだなあ。これって品質特性で言うところの「保守性(解析性)が高い」ということだよね？すばらしいなあ。 午後になって、対応してくれたプログラマSさんに「もう原因が分かっちゃったんですねー。早くてびっくりした。すごーい！」と言ったらSさん、 隣でmiwaさんがテストしながら「あ…」て言ったでしょう。気になって(コーディングする手を止めて)miwaさんの画面を見たらあれ(深刻な状態)ですからねー。その場でログとらせてもらってすぐに見れたからですよ！ なんだかわたしまでほめられた気分。うれしいな。 今回のケースは”テスターが問題を検出してからプログラマに伝わるまでの時間”がゼロでした。世の中にはこんなメトリクスがあるのかどうかわからないけど、とにか
丁寧な仕事はチームに伝染する - CAT GETTING OUT OF A BAG
先日、ある機能をテストしていたときの話。 いつもなら瞬時に画像が表示されるのに、今日は5秒くらい待たされる。おかしいな？と思い、別の画像で試してみるとすぐに表示された。どちらも表示自体には問題ない。画像に依存してるのかなあ…（もしかしたらそういうものかもしれない）と思ったのだけど、担当のプログラマOさんに見てもらう。 「確かに遅いですね。チケットあげちゃってください」 結論から言ってしまうと、作り方に問題があるということが分かった。（雑すぎる説明だな。大抵の場合はそうよね。） ええと、表示するときに「無駄な処理」をしてるっぽかった。 わたしはね、Oさんが問題の画像を別のテスト環境にコピーして、確認していたのを知ってる。（テスト環境に依存しているのかを切り分けるためだと思う） それから、その画像の内部的な構成を調べて、同じような画像を作っていたのも知ってる。（その遅い画像だけに起こる特有の問
違和感のつかまえかた - CAT GETTING OUT OF A BAG
ソフトウェアテスト #2 Advent Calendar 2018 - Qiita 24日目の記事です。 qiita.com はじめに 医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。うち１５年くらいはプログラマー、現在はテスターとして日々奮闘中です。 私は開発現場で感じるちょっとした『違和感』を大切にしています。風邪のひきはじめに「なんとなくだるい」「鼻がツンとする」「喉が痛い」「寒気がする」というような違和感を感じた時、症状がひどくならないよう行動を変えるのではないでしょうか。それと同じようにソフトウェア開発の現場で感じる違和感も『注目すべきシグナル』と捉え、活動のきっかけにしています。 この記事では 何を見て違和感をつかまえているのか 違和感をつかまえやすくする工夫 違和感をつかまえたあとのこと 違和感をつかまえるために知っておくと良いこと について記載
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
