改善」カテゴリーアーカイブ

BugReport

テストにおけるバグレポートの書き方

あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。

具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断することです。

それらのバグレポートを管理するツールとしてRedmine(使い方はこちら)を使っていました。

そのバグレポートの書き方、テスターとしてのTipsのようなものを少し書いてみます。
#再現手順、発生したソースのリビジョン、可能であればエラーログやスタックトレースを書くなどは当たり前の前提です。

1:実装者の感情面を理解して書く

その機能のプログラマとテスターが異なる場合、何度か同じようなバグに遭遇しているとレポートには「同様の機能でも同じバグが出ていました。きちんと内容の再チェックをお願いします。」などと書きたくなったりします。

実際には正しい行為なのかもしれませんが、重箱の隅をつつくようなバグを見つけ、バグレポートを無慈悲に起票するテスターの存在はプログラマーにとって気持ちの良い存在で無いと感じる人も多いようです。
正確な比喩ではありませんが、(例えそれが正当な内容であっても)自分の作品に「ケチ」をつけられるわけですから。

忙しかったりするとついテスターに向かって「テストのやり方が間違っているんじゃないの?もう一度確認してみてよ!」と感情的に答えたりして、テスターも「(品質の)いい加減なプログラムだからバグになるんでしょ」と応酬が始まってしまいます。こうなると品質の維持、担保などできません。

なので以下を参考にしたりして配慮した書き方をしてみませんか?という提案です。

2:技術面では客観性と主観を混ぜずに書く

1や3に通じるのですが、テストをしていると「あれ?自分の理解ではAと思うが、Bになるな」ということがあります。
そのような場合、バグレポートに客観的に書く部分と主観の部分が混じってしまうことがあります。

管理者としては、客観的な事実(テスト結果)を過不足なく知りたいわけです。
それを読み取れにくくなる主観と客観が入り混じったバグレポートは「テスターへの確認」という余計な時間が取られる存在になります。

もちろん「こう思う」とか「これでテストケースが失敗しているのだから、類似の機能も見た方が良いと思う」という主観を気づきとして書くのは非常に良いことで、問題なのはその書き方です。

3:本来どうあるべきかも書く

テストケースには「~となること」と合格条件が記述しており、「本来どうあるべきか」が明確になっています。

テストフェーズ中では(偶然にせよ)テストケースにない操作の結果、明らかにおかしかったり、「これは仕様と違うのでは?」という動きを見つけることもあります。
その時のバグレポートに「これこれが発生」という事象だけではなく、「本来は~であるべき」とあるのが良い書き方だと考えています。
その根拠となる設計書などドキュメントへのポインタがあればより良いです。

4:修正時に「なぜ?」(真因)を書く

テストフェーズ全般のTipsとして、修正時にバグレポートに対応内容などを書き込みますが、その時に「修正しました」だけでなく「なぜ」そのバグが発生した(混入した)のかという理由もあると未来の類似不具合の防止にもなります。

例えば、条件分岐の書き方を間違えていたとして、それが言語仕様を理解していなかったことがその根本であれば、同様の記述が無いかgrepしてみたりするアクションをするのも良いと思います。

また、設計書の記述を誤解していたのであれば同様の誤解をしていないかどうか、他のメンバーに確認してみたり、言葉なの揺れなどが見つかれば、記述を修正する必要があるかもしれません。

テストフェーズを意義あるものに

どうしてもテストフェーズは後の工程になり、スケジュールにも余裕がないことが多く、開発メンバーはそれまでのプログラム工程で疲弊していることも多々あります。
#それはプロジェクトマネジメントとしては失敗なのですが。

ただ上に書いたような点に少しでも留意すれば、品質の担保をできる最後の砦であるテストフェーズを意義あるものにできるのでは?と思っています。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像:http://www.flickr.com/photos/sajith/3161725149/

会議の費用対効果

IDEA*IDEAのミーティングで使えるちょっとした話法いろいろを読んで会議の費用対効果について考えたことです。

会議の目的

一口に会議といっても、色々な種類や目的があります。

1:ディスカッションやブレーンストーミング
結論が出すことに無理に執着せずに、参加者が色々と考えて、意見を表明して議論すること自体に価値がある場。
2:何かを決めないといけない時
3:報告をする時

このような種類があり、会議によってはテーマごとに種類が異なる場合もあります。

ダメな会議

いずれの種類でも、ダメな会議のパターンで、一番多く見かけるのは、「会議の目的」を誰も分かっていない、もしくはそれぞれ異なる考えを持っている場合です。

事前に決めておく議題(アジェンダ)や何のために集まるのかという目的、またゴールはどこなのかという終了条件といったことが参加者の共通認識として存在していない場合、ダメな会議になりやすいです。

現場から離れている、日常的に忙しいといった人、また異なる立場の利害関係者が多くいる会議ほど、「会議の目的」が決まっていない、またはバラバラなことが多くなりがちです。

このような会議では、始めてしばらくすると「この会議は何のためか?」「そもそも今日の議題は何か?」といった発言も出てきます。そしてそれをすり合わせるために時間を使うことになり、本来話し合いたかった会議の目的の時間は少なくなります。

会議の費用対効果

このような会議の工数を考えてみます。
例えば5人の出席者、2時間の会議だとすると10時間になり、1日8時間労働と考えると1人日以上のコストがかかっていることになります。

費用対効果を考えた場合、この会議の成果として(直接、間接はありますが、1人日分以上の成果を出さないとその会議は失敗したと考えられます。

だからこそ、会議の進行役は目的や議題を参加者に周知しておき、参加者はどのような目的かを理解し、自分なりの考えや報告する内容をまとめておくことが必要になります。

※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Texas Military Department via Visual Hunt / CC BY-ND

ふりかえり

KPT法を使う場合に気をつけること

 以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
 
 KPT法の優れている点は以下の3つと思います。

1つ目:サッとできる。

 紙とエンピツがあればすぐにその場でできます。

2つ目:見える化できる。

 付箋紙等を使えば「見える化」されることで、改善される感がより実感できます。

3つ目:ブレストしやすい。

 手軽に行えるので前準備も特に必要なく、みんなでやりやすく、良いブレーンストーミングができる可能性が高くなります。

KPTの難しい点

 逆に「これはKPT法では難しい」と思ったこともありました。
 KPT法では「悪かった点(Problem)」に対し「改善点(Try)」を行いますが、このTryが抽象度が高いぼやけた内容だと「なんとなく」な内容になり、そのアクションリストも曖昧なものになります。
 つまり「Problem」に対する表面的な「Try」でしかなく、『真因』まで分析できていないからです。

 製造業の現場に多い「なぜを5回繰り返す」「なぜなぜ分析」など、考えに考え抜き、その真因を導き出すのが「根本的な改善」というものです。

 ただ、(KPT法に比べ)時間がかかり、また、「なぜ?なぜ??」と突き詰めるのはパワーも必要なのでなかなかそこまで踏み込めないこともあります。

 話を戻すと「Problem」に対する表面的な「Try」を立ててみたところで、その「Try」は的外れかもしれません。

 この手の改善プロセスは、割とすぐに目に見える効果が出ないとしんどくなり、必須でも無い故に「やっぱり無駄なので、止めようよ」となりがちです。
 そのためにも、小さな成功体験で良いので、それを体験する時を導入する時の最初の目標にすることもあります。

 「Keep」も同様で「なぜそれが良かったのか?/良くできたのか?」が分からず、「なぜかな知らないけど偶然出来た」レベルでは、再現性の低い事象となります。
 その結果、習慣として定着せず、安定した高いパフォーマンスを出せなくなります。

 最初からヘビーウェイトなプロセスで深掘りするのもしんどいものですし、そもそも全ての「Problem」に対して必要があるか分かりません。そしてもちろんそんな時間もありません。

 ですので、どれを重点的に深掘りするか「見える化」するためにKPT法を使い、そこから重点的な項目に深掘りの技法を使うのが私にとってはしっくり来る改善のパターンだと感じました。

自分が議事録を書く際に気をつけていること

「議事録」は社内外の会議、打合せ、レビュー等のアウトプットです。
良い議事録を書く留意点、テクニックは色々あり、例えば…

1営業日以内に書く

記憶は曖昧で、かつ、あっという間に別のタスクが入ってくるので、早めに関係者に配布し、必要なアクションを起こしてもらうよう促します。

決まった事、決まらなかった事を明確に書く。

議事録は日記ではないので、「で、結局、どうなん?」が必要です。アクションが必要な決定事項には、いつ/誰が/どのように…5W1Hですね…を書きます。

事前に議事録を作成しておく

会議前にアジェンダ的な議事録(事前に会議の流れ、テーマを想定する)を用意しておき、それに基づき会議を進め、内容を穴埋めの要領で記述することで素早く議事録を完成させます。

(結論以外に)その結論に至った途中経過や他の意見も記述するようにする。

これについてちょっと考察します。
まずはメリットから。

■メリット
1:議論時の検討内容が後で分かる。
2:何故その結論になったが分かる。
3:検討の経緯が第三者から分かる。
 

その結果、「議論の蒸し返し」(あれってどうなったっけ?)、「検討内容の漏れ」(この結論の前に別の手段も検討したのか?)を防ぐことが出来ます。

次にデメリット。

■デメリット
1:議事録が見にくくなる。
2:議論の内容を書くのが難しい。

往々にして白熱すると早口になり、論理的に話すのも難しくなります(この辺、『言葉』と『文章』には断絶があります)。
その流れを書くとなると書記に高い能力が必要になります。
馬鹿正直にそのまま書くと台本のような議事録になってしまいますし(苦笑)。
※余談ですが、これは議事進行を整理してスムーズに行う(ファシリテーション)ことである程度は解消出来ると思います。

で、最後に過程を書いた方が良い例えを上げると…

■例
お客様と「資産データ一括取込機能の1次フェーズ導入の可否について」(やけに具体的ですが)と打合せで議論します。
そして議事録には「資産データ一括取込機能の1次フェーズ導入はしない。 理由:導入コストの費用対効果が見込めない為」だったとしましょう。

結果だげが記載されている議事録だけだと「コスト面は検討したが、ユーザのメリット、デメリットは検討したのだろうか?」となり、「そもそもコスト面というが、いくらかかるから…なのだろうか?」「簡易的機能で実現出来る方法は検討したのだろうか?」等々の疑問が出てきます。

実際の会議では様々な議論、あっちこっちに行く話の中で出ていると思います。
これを文字にして、論理立てた議事録を作るのは難しいのでっすが、これらを検討したことが議事録に記載されていると、先程挙げたメリットが得られます。

うまく運用出来ているプロジェクトでは副次的な効果として、参会者の中には、過程を書かれることを意識してか、会話、発言が(白熱してもちょっと一息付いて)論理的になるように意識して(後で議事録に書きやすいように)話す人も出てきたりしました。

会議の工数は「時間×出席人数」なわけで、工数のかなりの割合を占めます。
なので、会議の時間を無駄にしたくないなぁと思うわけです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: amboo who? via Visualhunt / CC BY-SA