前回のながれ
A君はようやくテストを実行することができましたが,その際,きちんと記録をとっておらず報告書も作成しませんでした。これでは,バグを直す設計者やテストの仕事を与えたM先輩に有益な情報を与えられるはずもありません。A君は再度テスト実行をやりなおす羽目になってしまいました。
A君はK先輩に言われたとおり,記録をとりながらテストを実行しました。また,バグそのものやバグの影がないか,注意深く観察を行うことで,より有益な情報が含まれる記録をとることができるようになりました。
再度テスト実行した記録やその報告書をK先輩に見てもらったところ,新人の初めての仕事としては及第点だろうと言ってもらえました。
全ての作業に苦労しただけに,A君の達成感もひとしおです。A君はK先輩にお礼を言い,M先輩のところに向かいました。
- A君「M先輩,お時間よろしいでしょうか? テストが終わったので報告したいのですが」
A君は,以前K先輩とレビューをしたことを思い出し,まずM先輩の時間の都合から聞きました。
以前のA君であれば,いきなり「テスト終わりました」と用件を伝えたでしょう。同じ職場で働いている他の人たちは,それぞれに仕事を抱えています。相手の都合を考えることができるということも,仕事をやるうえでとても大切なことです。
- M先輩「お,終わったんだね。さっそく内容を聞かせてもらえるかな?」
A君は事前に印刷してきたテスト報告書を先輩に渡し,テストの結果と概況,そしてテスト担当者としての見解をかいつまんで説明しました。
ひとしきり静かに聴いていたM先輩は,A君の説明が終わり,いくつかの質問をした後,こう言いました。
- M先輩「まだまだつたない点はあるけれど,初の仕事でこれだけできれば及第点。今後もこの調子で頑張ってくれよ」
- A君「ありがとうございます!」
- M先輩「こちらこそありがとう,おかげで大変助かったよ」
苦労しただけあってM先輩の言葉を嬉しく感じるA君です。
ひとつの仕事が終わり達成感を感じられると言うことはとても大切なことです。なぜならば,真剣に打ち込まないと達成感は得られないからです。仕事が終わったときに達成感を得られなかったとしたら,それは,真剣には取り組まなかったからかもしれません。
また,M先輩は最後にA君をねぎらう言葉をかけています。読者の方々で部下を持っている方々も多いと思います。部下であろうと,こちらが仕事をお願いしている相手です。必ずお礼を言いましょう。小さなことですが,とても,とても大事なことです。
M先輩は続けます。
- M先輩「さて,仕事がひとつ終わったところで重要な仕事がもうひとつあるんだ」
「それは振り返りだ」 - A君「振り返り…… なんですか? それは」
- M先輩「今回悩んだことや苦労したこと,そして学んだことがたくさんあると思う」
「それらを整理することで,次の仕事に活かすことができる」 - A君「わかりました,やってみます!」
A君は,先輩のいうように,今回の自分の仕事を振り返ってみることにしました。
連載第1回から5回までを振り返ってみよう
プロジェクトやひとつの仕事が終わったら,その内容を振り返ることは長いエンジニア人生を送る上でとても大切なことです。本連載ではA君のはじめての仕事がソフトウェアテストであったという設定を用いて,新人さんが最低限押さえるべきポイントを説明してきました。詳しくは今までの回を再度読み直していただくとして,もう一度意識していただきたい点について,いくつかあげてみます。
ソフトウェアテストそのものについての理解を深めるべし
最近は変わってきたとはいえ,まだまだソフトウェアテストは,学校や新人研修では体系的に学習することができない場合がほとんどです。プログラムの書き方を少し習っただけで現場に投入されることもあるしょう。
したがって,現場に配属された当初は,テストについてはほぼ知識がない状態です。自分だけがそうだと思って悲観しないでください。全国にいる多くの新人エンジニアが同じ道を歩んでいます。プログラムが書けないからと言っておざなりに仕事をするのか,ひとつテストについて勉強してやろうと思うかは,皆さんの判断次第です。
テストという仕事を与えられ,その仕事に対して自分なりにしっかりとやろうと思ったならば,テストそのものについて勉強してください。今は,基礎的な知識を習得する時期なのです。決してプログラムを書いている同僚と比較しないように。
テストはやみくもに行うなかれ
テストは何も考えずにやみくもに行うものではありません。テストの目的をしっかりと押さえ,計画的に実行する必要があります。
ときどき「適当にテストしといて」と言う人がいるそうですが,適当に行うテストはテストとは言いません。 テストやテストという仕事にはなんらかの目的があることを意識し,そこをしっかりと押さえる必要があります。
仕様書をプログラムを書くときと同じように読むべからず
テストを行うにあたって,その情報源となるテストベースの代表的なものは仕様書です。仕様書は,プログラムを書くときとテストケースを書くときとでは読み方が異なります。仕様書はテストベースとして読み解く場合,設計の観点ではなく,テストの観点から読む必要があります。

