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君のはじめての仕事がソフトウェアテストであったという設定を用いて、新人さんが最低限押さえるべきポイントを説明してきました。詳しくは今までの回を再度読み直していただくとして、もう一度意識していただきたい点について、いくつかあげてみます。
ソフトウェアテストそのものについての理解を深めるべし
最近は変わってきたとはいえ、まだまだソフトウェアテストは、学校や新人研修では体系的に学習することができない場合がほとんどです。プログラムの書き方を少し習っただけで現場に投入されることもあるしょう。
したがって、現場に配属された当初は、テストについてはほぼ知識がない状態です。自分だけがそうだと思って悲観しないでください。全国にいる多くの新人エンジニアが同じ道を歩んでいます。プログラムが書けないからと言っておざなりに仕事をするのか、ひとつテストについて勉強してやろうと思うかは、皆さんの判断次第です。
テストという仕事を与えられ、その仕事に対して自分なりにしっかりとやろうと思ったならば、テストそのものについて勉強してください。今は、基礎的な知識を習得する時期なのです。決してプログラムを書いている同僚と比較しないように。
テストはやみくもに行うなかれ
テストは何も考えずにやみくもに行うものではありません。テストの目的をしっかりと押さえ、計画的に実行する必要があります。
ときどき「適当にテストしといて」と言う人がいるそうですが、適当に行うテストはテストとは言いません。 テストやテストという仕事にはなんらかの目的があることを意識し、そこをしっかりと押さえる必要があります。
仕様書をプログラムを書くときと同じように読むべからず
テストを行うにあたって、その情報源となるテストベースの代表的なものは仕様書です。仕様書は、プログラムを書くときとテストケースを書くときとでは読み方が異なります。仕様書はテストベースとして読み解く場合、設計の観点ではなく、テストの観点から読む必要があります。
テストケースを行き当たりばったりで作成するな
テストケースは作ろうと思ったらいくらでも作ることができます。ですが、テストケースが増えるということは実行時間が増えるということでもあります。いかに短時間で効率的に危険なバグを発見するかには、テスト戦略が必要です。
戦略的にテストケースを作るために、テストケースを「設計」しなければなりません。テストケースをいきなり書くという行為は、プログラムコードをUMLやフローチャートを作成せずにいきなり書くのと同じことです。テストを設計するには、テスト技法の知識が必要です。なお、本サイトにはテスト技法を解説した記事があります。本記事とあわせてお読みください。
テストケースの書き方をマスターせよ
テストケースは大抵の場合、日本語で書かれます。日本語は曖昧な表現が多いだけに、注意して書かなければ、曖昧なテストケースになってしまいます。テストケースは誰が読んでも意味がわかり、間違えずにテストができるように注意して作成する必要があります。
また、テストケースは自然言語だけではなく、表や図として表現されることがあります。どのようなテスト技法を使うかによって書き方が変わることに注意しましょう。
テストケースをレビューせよ
テストケースそのものに欠陥が混入されていたら、つまり、誤ったテストケースを書いていたら、当然のことながら適切なテスト実行はできません。テストケースのテストとして、レビューを実施する必要があります。
一つのテストケースを実行するにも、多くの準備と実施時間が必要です（特にシステムテストに近くなればなるほど）。
誤った記述のまま実行してしまうことで手戻りが発生するのは、プログラムのバグと全く同じです。プログラムはテストを行うことでバグを見つけられます。テストケースのテストは通常行いません。テストケースの場合、レビューがそれに当たるのです。
なお、レビューはテストケースの作成時のみでなく、テスト設計書などの作成時に行うことで、早期にテストとしての品質を確保することができます。
テスト実行は記録し、報告書を作成せよ
テストケースの実行結果は合格・不合格だけを記録するのではなく、その他にも記録すべき情報があります。この記録をしっかりとっておかないと、バグを発見したときの解析が困難であったり、再現手順を見つけるために再度テスト実行を行う必要が出てきます。
そして、テスト実行が終了したとき、今回行ったテストがどのような結果であるかを報告書にまとめねばなりません。この報告書が、テストを終了してよいかどうかの判断の材料になるため、報告先が理解できるものを作成する必要があります。
気づきをメモせよ
さて、この「気づきをメモせよ」は第1～5回の連載中には出てきていませんが、基本中の基本です。新人のころは、見るもの全てが新鮮で覚えなければならないことばかりです。先輩に聞いたこと、自分で調べたこと、気づいたことは、その都度メモを取らなければなりません。
本連載記事でも、A君が先輩達の指導を受けていました。さまざまなアドバイスをもらっています。その指導内容や自分の気づきをノートに書いていなかったらどうでしょう。1つ2つの事柄は覚えていられると思いますが、すべて覚えているのは難しいでしょう。
先輩から同じような仕事を任されたとき、覚えていなかったらどうでしょうか？ 優しい先輩ならば再び教えてくれるかも知れませんが、それを期待してはいけません。
まとめ
新人さんは、まずこれらのキーワードを胸に刻んでください。これがしっかり意識して仕事を行えないと、より高度なテストはできようもないのです。
今後さらにスキルアップするために
さて、これまでの連載では、現場に配属されて始めて担当した仕事がテストだったときに最低限押さえておくべきことを解説しました。しかし、これはあくまで最低限であり、この内容を押さえたからといって、今後の仕事もうまくいくとは限りません。むしろ押さえるべきポイントは山のようにあります。
たとえば、
- テストのプロセスを理解する
- テストの技法を理解する
- テスト対象の技術についての理解を深める
- テスト対象のドメインを理解する
などがあります。
これからさらに成長するための情報は、本Webサイトのテストエンジニアステーションの記事が手がかりとなるでしょう。成長するためには自分の中にない情報に沢山触れ、咀嚼する必要があります。また、それを実際の業務で実践し、身につける必要があります。
スキルアップは自分のために行うことです。将来を考えて自分への投資と位置づけて、積極的に取り組みましょう。
おわりに
今回の連載はいかがだったでしょうか？
この連載で紹介したポイントは、配属されたばかりで、まだ右も左もわからない新人さんのために書いているため、プロのテストエンジニアから見ると「そんなの常識だろう」というような内容です。ですから、最後まで読んだ新人さんは「これだけできればもう大丈夫」と思わずに、あくまでもスタートラインにたつための準備ができたというくらいと理解してください。
設計技術を極めるのは大変ですが、テスト技術を極めるのもまた大変です。目標を高く持ってスキルアップに励んでいただけたらと思います。
