こんにちは。まーくー＆くまねこです。
ゆるっとシリーズ第6話です。前々回、前回から引き続き、学び直し回です！
書籍「基本から学ぶソフトウェアテスト」を読んで、現在でも活かせる内容があるのか？ないのか？会話形式でお話しさせていただきます。
最後まで楽しんで読んでいただければ幸いです！
自己紹介
まーくー
QA業界経験2x年のベテラン（おじさん）エンジニア。
過去のミスに愕然とする事ってありますよね？えっ？ありませんか？私はあります。。。
くまねこ
QA業界経験1x年のエンジニア。
ジムに行った後、「運動したし、食べまくるぞ！」ってなる日ありますよね？僕はいつもです。。。（元の体重に戻りつつあります）
イラストby くまねこ
何やらまーくーが愕然としている模様…何があったのでしょうか？
今日も二人のやりとりをお楽しみください！
今日も仲良く学び直し！山あり谷ありの探求の旅？？？
 | ぐあああぁあああああ！（突然の叫び！） |
 | あらっ、まーくーさん、どうしたんですか？Knock knock Downしてますね…？（愕然として青ざめている…何があったんだろう…？） |
| く、くまねこさん、、、書籍「基本から学ぶソフトウェアテスト（第4版）」P.83の欄外を見てくれぇ・・・ |
| は、はいっ！ふむふむふむふむ…（ふむむ…何があるんだ？？？） |
| ここだよ…こ、ここぉ～！Woo～！ |
訳注：原著は1993年に執筆されており、2000年問題はそのころまだ騒がれていなかった。
基本から学ぶソフトウェアテスト
| 今までの学び直し記事で、「20年前の書籍を紹介している」って書いてたけど、原著は30年前のものだったんだぁ。。。 |
| 30 years ago～！…そうみたいですね♪（もっと昔だったのかぁ…ますますエインシェント！でも、何を取り乱しているんだろう？） |
| 全世界に公開されている記事で30年前のものを20年前のものと、虚偽の記載をしてしまった。もう取り返しがつかない・・・。原著に裁かれているような気がするぅ…ぐあああぁあああああ😢 |
| ちょっと落ち着いてくださいよ。まぁ日本では20年前に発売された書籍だから問題ないんじゃあないですか？This book was made in Japan！We live in Japan！さっ、今日は第5章、第6章から学び直していきましょう！ |
| （えっ？あっさり？Why？取り乱した自分が恥ずかしい。。。そんな自分に負けないためにあれを使おう…）お、おぉ。そ、そうだね。ま、学び直して行こう！Bigbang⤴？ \🐻/ → 🌎 → ✨🐻ﾉｼ Hello World✨ |
| Yeah～！ \🐼/（訳：まーくーさん、BigBang使ってここまでの流れを再創生したのは良いけど…うっかり自分から「学び直ししよう」って言っちゃった～！ぐあああぁああああ～！(((🐼)))） |
第5章 障害の報告と分析を読んで
| まずは「本章のねらい」からですね。本章では「障害レポートをどう使えばプログラマとスムーズに意思疎通できるかを説明する。」とあります。 |
| 「バグチケット」「バグ票」「バグレポート」「障害票」など現場によっていろいろな呼び名がありますよね？ |
| そうだね、本記事では書籍に記載のとおり「障害レポート」で進めましょう！ |
| はーい。 |
| 障害レポート以外でもプログラマとのコミュニケーションは取る必要があるけど、テスト担当者としてプログラマと障害のやり取りをする一番重要なツールが障害レポートだ。これが上手く書けないといわゆる「バグピンポン」が発生してしまう。 |
| 🐼ﾉ💡あ、プログラマとテスト担当者で障害レポートが行ったり来たりするやつですね。なかなかこちらの言いたいことがプログラマに伝わらず悲しくなってくるやつですね。 |
| でもテスト担当者の書く障害レポートの内容が不十分だったり、書き方が悪かったりすることが原因で発生することが多いんだ。テストを実施する立場で言えば、この章はとても重要だね。 |
| 心して掛かります！ちなみに「本章で紹介するレポートは、紙での運用を想定している。」っていうのは、時代を感じますね。 |
| いまはほとんど障害管理システムを使っていたり、表計算ソフトなんかで表にして運用することがほとんどだからね。でも第一報は紙って現場もまだあったりするよ。 |
| えー。びっくり。そうなんですねー！障害管理システムでも紙でも基本的に内容はいっしょですよね？本章で記載されている以下をちゃんと理解して、良い「障害レポート」が書けるよう学び直します💪 |
・障害レポートの項目
基本から学ぶソフトウェアテスト
・質の高い障害レポートの書き方
・再現性のある障害分析の方法とコツ
・障害を再現させる方法
| おぉ、冒頭にとても良いことが書いてあるね！ |
障害を見つけたら、その場でレポートを作成せよ！
基本から学ぶソフトウェアテスト
| メモを取ってあとから書こうとしても、時間が掛かったり、曖昧な記述になってしまったり・・・すぐに書くって大事ですよね。 |
| うん。すぐに書けないこともあるけど、極力早めに書いた方が良いのは間違いない！障害を早く開発側に報告できるしね。次にレポートの内容について記載すべき項目があげられているよ。 |
| ふむふむ…ふむふむ…書籍に記載されている障害レポートのフォーマットを見てみると、現在の業務でも使っている項目は網羅されているようです。共感したのは、障害検出～報告までのところです。実際のテスト中に障害と思われる現象を検出した時、今までの手順や条件などを整理しながら、必要なことをなるべく簡潔に開発チームに伝えられるように心がけています。 |
| GOOD！障害レポートの報告内容によって問題の重大さの認識や、開発側のデバッグ効率などに影響を与えるから、改めて理解して実践できるようになっておきたいところだね。 |
| あと、スケジュールに余裕がないピリピリした状態でも開発チームと良い関係で進めていけるよう、障害レポートの表現にも気を付けています。ちょっとした気配りをするだけで、テスト担当者・開発者間の行き違いや感情的な衝突を防いだりできるので、言葉遣いも重要ですよね！ |
| 誰が言ったか知らないが、「バグを憎んで人を憎まず」ってのが大事だよね☝ |
| ですね（心に刻みます！）。次は「再現性のある障害の分析のコツ」＆「障害を再現させる方法」！これは興味のある方も多いのではないでしょうか？ |
| だよね。まず障害の分析として以下を挙げている。 |
・最も致命的な現象を明らかにする
基本から学ぶソフトウェアテスト
・最も簡単で制約の少ない条件を明確にする
・同じ障害を発生させる別の手順を見つける
・関連する障害を探す
| ふむふむ。上記の情報がそろっている障害レポートなら、開発者もプログラムの修正がしやすそうですね！ |
| 続いて「再現性のある障害の分析のコツ」＆「障害を再現させる方法」が詳しく記載されているよ。 |
| ここは特に現在のテスト担当者にも活かせる内容ですね！障害を検出したときって、上記ポイントを明らかにするために、過去にさかのぼって操作や条件を思い出したり整理したり・・・考えること多いですよね。 |
| この書籍の分析のコツや障害再現方法を参考にすれば、テスト経験が浅くても良い障害レポートが書けそうだね。 |
| 焦ってると頭の中だけで考えてながら進める事が多いですけど、色々やり過ぎて迷子にならないよう、上記ポイントを押さえつつメモを取りながら進めていくと良いかなって思いました。 |
| オーゥケイ！そんな我々が報告した障害レポートがどこへ行こうとしているか、くまねこさんは知りたくないか～い？ |
| Yeah～！ \🐼/（訳：突然エンジンがかかった？？？とりあえず乗っておく～！） |
| このまま第2部、第6章も読んでいくぞー！カモォン！ |
| Yeah～！ \🐼/（訳：ぎゃー！） |
第6章 障害管理システム を読んで
| 6章は障害管理システムについて。私もくまねこさんも、障害管理システムとして独立して管理しているプロジェクトや、Redmineなどを使ってタスクと一緒に管理するプロジェクトを担当したことがあると思うけど、ここでは前者の意味合いで書かれているかな。 |
| 現代ではアジャイル開発のように短いスパンで設計～テスト～リリースするプロジェクトも多いですし、本書は30年前のものの書籍だからウォーターフォール開発前提の重厚な内容だとすると、導入が難しいところもあるかもしれませんね。 |
| ただ本章のねらいでも「障害レポートを報告後どうするかを述べる。」と記載されていて、「障害を管理する」という点では共通して学べることもあると思うから、読み進めていこう。 |
| まず、「障害管理」というところではテスト対象で報告された障害の可視化（重大度の大きな障害が何件あるか、修正された件数が何件あるか等）ができる点は当然良い点として挙げられると思います。 |
| 製品の品質状況やプロジェクトの状況を可視化することができるよね。 |
| ただ可視化したことで、人や管理の問題（誰がどれぐらい件数を出しているのか、起こりえる問題など）についても言及があって、改めて障害管理システムの与える影響について考えさせられました。 |
| そうだね。正しい運用をしないと、プラスの影響だけでなくマイナスの影響も出てしまうんだね。 |
| やはり、テスト担当としてプロジェクトに参画すると、自分の実績って「どれぐらいのペースでテストを消化しているか？何件の障害を検出して報告できたか？」というのが大きいと思います。 |
| 報告した障害レポートの数を競ったり、人の障害レポートの数をみて「あ、自分の報告少ない！」って焦ったりね😅 |
| そうそうそれです！でも、障害管理システムで集計された数字が他のテストメンバーや開発メンバーに与えるマイナスな影響についても言及されていて、プロジェクトを運営する側は正しく障害管理システムを運用しなければならないとわかり、とても参考になりました。 |
| そうだね。マネジメントする立場からすると、ある程度数字で判断しなければいけない場面ってあると思うけど、障害管理システムのいちばんの目的は下記にもあるように「障害の発生/修正状況を管理する」ということだから、そのことを意識して使っていくよう注意が必要だね。 |
障害管理システムは、修正すべきバグを修正するためにある。この目的に直接関係ない事は、二の次である。
基本から学ぶソフトウェアテスト
| はい。また、テスト初心者であっても本章を読むことで、プログラマやプロジェクトマネージャー等さまざまな役割のメンバーが、それぞれの視点で障害管理システムを利用する際に考えなくてはならないことが分かると思います。 |
| 障害管理システムが備えておくべき要件と各役割の全体像を理解するには良い記載かも知れないね。次に、障害管理システムで出力できるレポート関連について記載があるけど、どうかな？ |
| 検出した障害の一覧というところで、基本的な項目や出力できるレポートの種類は現在とあまり大きな差異はないように思います。ちょっと結びつけるには強引かもしれませんが、以前の記事で話した「目的に対する最終的な成果」についての報告で、出力したレポートを使ってテスト担当として障害傾向や品質状況についての考えをコメントできるようになると、より説得力のある報告ができると思いました。 |
| そうだね。ここで学んだことを活かして、障害管理システムを使いこなしていきたいね！ |
まとめ
| 今回は障害関連ということで見てきたわけだけど、どうだったかな？ |
| 第5章の障害報告については大事なポイントが整理されていて、自身がやっていたこととの比較から良い学び直しになりました。障害報告フォーマットについては、今までの経験からすると新しい発見はあまりありませんでしたが、基本は陳腐化しないものであるということが実感できてよかったです。 |
| 学び直してるねぇ(笑) |
| （茶化さないでくださいよー）また、現場によって障害報告フォーマットの項目が異なることもあるので、そういった場合には「改善提案」という形で今回学び直したフォーマット項目に留意しつつ、不足部分があれば提案して、導入するメリットまで説明できるようにしていきたいです。 |
| 良いね！紙で障害レポートを書くことを前提にしていたり、時代を感じる記載はあったけど、全体的に現在でも大事にすべきポイントが多々記載されていたね。私もテスト結果のレポートなどを提出する時には、第6章に書かれている「障害管理システム」の運用の考え方やフォーマットを参考にして、今後の活動に役立てていきたいと思う！ よーし、第2部もこの調子で学び続けていかなければ…バーイ！🐻ﾉｼ 三 |
| Yeeeeeeeeeeaaaaaaaaaah！ \🐼/ （アンコール！アンコール！） |
次回予告
| 三🐻ﾉｼ（戻ってきた）さて、今回はここまでにしようか。 お互いJSTQBのALの学習は進んでないけど(笑)、次回はどんな感じかな？ |
| 次回のまーくー＆くまねこは、 |
| JSTQB ALTM試験、勉強する気ある？どうでしょ！（仮） |
| JSTQB ALTM試験、受けるかも？受けないかも？どっちでしょ！（仮） の２本でーす。 |
 | 最後まで読んで頂き、ありがとうございました！ よろしければ、過去のゆるっと♪シリーズもお楽しみください！ 次回もまた見てねー🐻ﾉｼ 三 🐼ﾉｼ 三 |
🐻ゆるっと♪シリーズ🐼
第1話 ゆるっと♪ファームウェアテストよもやま話
第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験
第3話 ゆるっと♪どうやってる？探索的テストの世界！
第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！
第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！②～あきらめてしまわないでね 難しさ感じても～
