はじめまして、さっちゃんです。
私は普段、テスト研修の講師を担当しております。今までは、テスター経験者や開発経験者向けに研修を行っておりましたが、 今回は、テスト未経験である2022年4月採用の新卒者向けに研修を行いました。
その中で、未経験者ならではのつまずきポイントや特徴が見え、「テストにおいて大切なこと」について逆に気付かされたこともあったため、全2回の構成でお伝えしていきたいと思います。
今回の第1回では、未経験者向けにどういった研修を行ったかと、未経験者ならではのつまずきポイントについて紹介し、第2回では実際に研修生が行ったテスト設計の紹介と、そこから気付かされたことについて紹介していきたいと思います。

テスト研修で行った内容

まずは、約30日間のテスト研修で、どういった内容を行っているのか下記に記載します。


これらを、資料を用いての説明と、演習で実際にテスト設計(ドキュメント作成)を行うことで学んでいただきました。

講師をしていて悩んだポイント

自分自身がテストをする際に考えていること・やっていることをそのまま伝えよう!という意気込みで講師をしていましたが、正直・・・・

どこまで教えたらいいのかわからん!

という気持ちがずっとありました。
テストの世界は奥が深いもので、いわゆる「正解」が何なのか、私自身も悩んでしまうことがあります。プロジェクト毎に異なる対応、異なる考え方が必要で、こういうときはこうして、ああいうときはああして…と伝えていたらキリがありません。

例えば、「正常系・準正常系・異常系」の説明をしようとしても、

A社:エラー表示は全て”準正常系”です!
B社:エラー表示は開発仕様書で定義しているので”正常系”ですね
C社:準正常系?うちは正常系か異常系かしかありませんよ

といったように、切り分け方は会社単位や人単位でも違っていたりします。
そこで、私はベースとしてこのように考えて研修を行いました。
受講者へはできるだけ多くの方法を教えて、引き出しを増やしてもらおう!
「正解」がプロジェクト毎に変わるのであれば、どんな状況にも対応できるよう、
とにかく引き出しを多く持ってもらうことが、この先テスト業務を行っていくうえで重要だと考えたのです。

まずは、JSTQB FLシラバスの内容に沿って作成した資料をもとに基礎知識を教えた後、
実際のプロジェクトではどういった事例があるか、今までの経験をもとに補足説明し、
どのようなテストを行うかは、ステークホルダーとの”会話”が大切だという話をしました。

ステークホルダーとの”会話”とは?

ステークホルダーからいただく開発仕様書・要件定義書などをもとにテスト計画・テスト設計を行っていきますが、先述の「正常系・準正常系・異常系」の考え方に違いがあるように、そのプロジェクトで適用されている用語やルールについて認識齟齬がないか、しっかり確認しておく必要があります。
また、テスト対象となるシステム・機能の仕様についても、誤った理解のままテストプロセスが進んでいってしまうと、正しくテストが行えなくなってしまうため、ステークホルダーとテスト担当者で認識合わせをしておくことも重要です。

経験者向けの研修の際にも、大多数が「とにかく学んだテスト技法を使っていれば大丈夫だろう!」と考えてしまう節があったため、今回はチャット・通話・クラウドサービス等を使用しながら、ステークホルダーとの”会話”に重点を置きながら研修を進めていきました。

研修生の皆さんは、最初は緊張や「何を確認したら良いのか分からない」という理由から、やや会話が少なめでしたが、後半には感覚を掴めてきたのか、しっかりと会話をしながら進めることができるようになっておりました。

ただ、このほかにも未経験者ならではのつまずきやすいポイントが様々なところにあったため、紹介していきます。

テスト未経験者がつまずきやすいポイント

経験者向けの研修では、「テストの考え方」や「テスト技法」に重点を置いて説明していますが、未経験者にとっては「ほぼ全てが聞きなれない単語」であるため、単語の意味も交えて研修を行っていました。
ですが、単語も考え方も技法も短期間で一気に覚えるのは非常に苦労していたようです。
最後の演習では皆素晴らしいテスト設計ができていましたが、それまでにたくさんの苦労・苦悩があったのではないかな?と思い、今後の研修の参考とすべく、アンケートを取ってみました。

ヒアリングした内容としては、
「つまずいたポイント」と「その理由」と「どうしたら理解できたか?」となります。
12名に「つまずいたポイントについては複数選択してOK」とお伝えし、回答いただきました。

ブラックボックステスト技法については全員が何かしらつまずくポイントがあったようですね。さらに細分化してみました。

バラつきはありますが、デシジョンテーブルテストが一番多かったようですね。
反対に、境界値分析については特につまずくことなく理解できていたようです。

デシジョンテーブルテストでつまずいた理由については、以下のような意見がありました。

Aさん

デシジョンテーブルと状態遷移表の違いが分からなくなりました。
N/A (Not Applicable)や、「入力結果が”無効(動作しない)”になるもの」に焦点を当てることで理解できました。

どちらも”表”になっており、有効な動作・無効な動作などの出力結果を洗い出すのに役立つ技法であるため、たしかに似ていますね。
まずはN/A・無効になる「入力条件」や「状態」を考え、それを基に、

入力条件は同じでも「状態」によって出力結果が変わるものを”状態遷移表”でまとめ、
入力条件が異なることで出力結果が変わるものを”デシジョンテーブル”でまとめる

と捉えると良いかもしれませんね。

Bさん

デシジョンテーブル自体の作成方法や役割は理解できましたが、入力条件等が多くなると
その分デシジョンテーブルの量も膨大になり、作成するのが大変でした。
研修中は、入力条件がどんな条件であっても出力結果が変わらない場合は、
同値分割法を使用してその部分を省略するなどの対処をしていました。

デシジョンテーブルテストでは、「全ての入力条件の組み合わせ」を整理すると、いとも簡単にテーブル自体が肥大化してしまい、整理に時間を要してしまいますね。
「省略する」というのは、デシジョンテーブルテスト・同値分割法・仕様をしっかりと理解しているからこそできる技ですね!

但し、「省略しても良いかどうか?」はプロジェクト毎に異なります。
その組み合わせが重要な機能であれば、省略せずに100%網羅するテストケースを作成する必要があるかもしれない、という考え方も常に持っておきたいですね。

デシジョンテーブルテストでの省略方法や、同値分割法の考え方については、
本サイトの別記事にも掲載しておりますので、ぜひ併せてご一読ください。

▼デシジョンテーブルテストでの省略方法

▼同値分割法

ブラックボックステスト技法はとても便利な半面、使いどころ・使い方を誤ると、正しいテストが行えなくなってしまう可能性があります。
その判断を身に着けるためには、ある程度鍛錬を積んでいく必要があるため、未経験者がつまずきやすいポイントとなっていそうですね。

(次回以降の研修内容を少し考え直してみよう・・・)

最後に

今回の記事では、未経験者向けにどういった研修を行ったかと、未経験者ならではのつまずきポイントについて紹介させていただきました。
経験者向けの研修では、研修生自身が過去の経験から実際のテストをイメージすることで理解しやすかった部分が、未経験者はその「イメージ」するものが無いため、理解までに時間を要してしまうようでした。
ただ、苦労しながらも最終的には皆さんテスト設計・テスト実施が行えるようになっていたため、完全未経験からでも30日間の研修で立派なテスト担当者となれました!
これからの活躍がとても楽しみです。

後日公開予定の後編では、実際に研修生が行ったテスト設計の紹介と、そこから気付かされたことについて紹介していきたいと思います。

SHARE

  • facebook
  • twitter

SQRIPTER

AGEST Engineers

AGEST

記事一覧

AGESTのエンジニアが情報発信してます!

株式会社AGEST

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST