テスト自動化 ( Java ) 体験で学ぶ品質向上のキホン｜研修コースに参加してみた

Learning Topics 編集部

今回参加したコースは テスト自動化（Java）体験で学ぶ品質向上のキホン です。

トレタンのアンケートによると、若手社員の約 8 割が新人研修修了後、テスト業務に配属されるそうです。

そんなテストですが、ややもすると、延々とテストケースをこなす、ドキュメントを書く、のようなイメージを持たれがちです。

今回はそんなイメージではなく、品質を上げるアプローチとして、バグをとにかく探すのではなく「想定通り ( = 正常動作) を増やす」「想定通りを増やすコツ」「実際やってみる」というのが体験でき、テストでゲームのような不思議な感覚が味わえました。

このコースの演習では「テストが通らなかったらどうしよう」と考えるのではなく、「最初からテストが失敗している」状態からスタートしてプログラムを書いたので、不安をあまり感じず、そんな感覚になったのかも知れません。

では、どのような内容だったのかレポートします！

コース情報

講師紹介

参加してみたレポートでは久々の登場となる 冨原　祐 さん です。

冨原　祐
現場の技術をどう学ぶか、工夫を凝らした演習をデザインできる講師

品質を上げる正しいアプローチはバグ探しではない

まずはテストをする目的、「品質を上げる」ことについて解説いただきました。

• 「品質を上げる」と言ってもアプローチを変えると行動が変わる
  • バグを減らす（摘出する）作業を行う
    • テスト工程でバグをいっぱい 探す
  • 正常動作 を増やす
    • テスト工程で全ての正常動作を 確認 する

今回のコースはこの「正常動作を増やす」ことで品質を上げる方法がテーマです。

正常動作を増やすとは「想定通り」を増やすこと

「正常動作を増やす」をもう少し詳しく定義します。

• 正しく動く ことを 保証 する
• さまざまな使い方をしても 想定通り 動くこと

つまり、この「想定通り」がどれだけカバーできるかが重要になります。

そこでこの「想定」を考える演習をしてみました。

冨原さんからは「とにかく最初からテストケース（想定）を書くと抜け漏れしやすいので、まず必要なのが観点を洗い出してから、テストケースを考えるのがよい」とアドバイスされました。

• 文字数の観点
  • 0 文字、 7 文字、 8 文字、 9 文字
• 正常パスワードの観点
  • 4 つのうち 3 つを選ぶパターンは 4 パターン、それに 4 つ全てを足した 5 パターンで正常パスワードと判定されること
  • 文字数は 8 文字のみでよい
• 異常パスワードの観点
  • 4 つの種類のうち、 2 つを選ぶパターンは 6 、 1 つを選ぶパターンは 4 、この 10 パターンをテストする
• 最大文字列の観点
  • ここまでは何文字まで入るかの定義がされていないことに気付く
  • 仕様検討時にテスト観点をイメージしていれば仕様漏れにならない
• その他文字列の観点
  • 正常パスワード + 全角文字、制御文字、定義された記号以外
  • 記号の定義が必要なのではないか
  • これも、仕様検討時にテスト観点をイメージしていれば仕様漏れにならない

テスト工程

では、テストはどのように進めるのか、解説いただきました。

現在はシステムが複雑化・大規模化していることに伴って、単体テストが肥大化しているとのことでした。

確かにログイン一つとっても、 2 要素認証、 SNS などを使った認証、音声電話などなど多様化しているので、肥大化しているのもうなづけます。

テスト手法

またテスト工程ごとに使われる手法の例には次のものがあります。

• 単体テスト
  • ホワイトボックスとブラックボックス
• 結合テスト
  • トップダウンとボトムアップ、サンドイッチ
    • ダミー（スタブやドライバ）を使う
  • ビッグバン
    • 作ったものをとりあえず動かす
    • どこで問題が起きたかわかりづらい、どこで修正するか安易に後ろに倒しがち
• 運用テスト
  • 負荷テスト
  • 性能テスト

単体テストはブラックボックステストが主流

その肥大化する単体テストですが、手法はホワイトボックステストではなく、ブラックボックステストだけをやるのが主流になっています。

• なぜか
  • 昔はプログラミング言語 ( C 言語など) の機能が貧弱で、エラーの出力などが弱く、テストしてもわからなかった
  • 現在は言語だけでなく IDE も発達し、エラーとその内容がわかるようになった
• Input と Output に注目するのがブラックボックステスト
  • 入力（パスワード） -> 処理 -> 結果（ログイン）

このブラックボックステストを使って、「想定」を増やします。

テストケース演習

ここで、テストケースを出す演習を行いました。解答は隠していますので、ぜひ読者の皆さまもやってみましょう。

冨原さんから以下のアドバイスがありました。

• あらかじめ出したテストケースでテストすること
• テスト中に思いついた、新しいテストはやらない（テストが終わった後にやる）
• テスト中はメモだけ残す
• あとで、なぜ漏れたのかをふりかえる（観点を増やすことができる）

テスト自動化とは

テストケースを洗い出したのは、テスト自動化につながるからでした。洗い出して自動化すれば、「想定」がどれだけ増えようとも効率的に実施できるようになります。

ただし、洗い出したテストケースしかテストできないので、これまでの「想定」 = テストケースをどれだけ出せるかがポイントになります。

メリット

• 繰り返しテストできる
  • 数百件、数千件でも素早く実行できる
• テストコードを先に書くと、シンプルなプログラムになりやすい
• テストケースと仕様が一致する
  • 仕様や設計とコードとの不一致に気づきやすい

このためテストコードを先に書く開発するスタイルもあるとのことで、このあと紹介されました。

ちなみに、 OSS に対してプルリクエストを出すときは、テストコードが求められることが増え、その場合はテスト自動化ツールを動かして OK がでないとマージされません。世界的にもテスト自動化は標準的になっています。

デメリット

• テストコードを書く工数がかかる
  • 一般的には本体のプログラムと合わせて 1.5 倍～ 2 倍ぐらい（慣れると減らせる）
• 学習コストがかかる
  • 本体のプログラムそのものを書くのも、はじめは慣れない
• 仕様が変わればテストケースもメンテナンスする必要がある

テスト駆動開発 ( TDD Test Driven Development )

先程紹介されたテストを先に書く TDD を紹介いただきました。

• 先にテストを書いてから本体のプログラムを書く (テストファースト)
• 最初はすべてテストが失敗する ( 失敗するとテスト結果が赤 [Red] になっている)
• プログラムを書いていくと、徐々に成功するテストが増える ( 成功するとテスト結果が緑 [Green] になっている)
• 進め方は以下の通り
  1. テストを書く Red
  2. 最小限の仮実装 (どれだけダーディでもよい。コピペも可。最悪テストの値を使っても良い) Green
  3. リファクタリング (プログラムをクリーンにする) Refactoring

冨原さんは現場で TDD をやったことがあり、プログラムを書くのがゲームのようで楽しかったとふりかえってらっしゃいました。

このあと JUnit など単体テストのフレームワークを紹介いただき、単体テストをやってみます。

JUnit でテストコード演習

行った演習は以下のようなものです。

コントローラ Controller などのような Web アプリケーション特有のテストではなく、「検証」クラスをテストします。

1. テストコード UserValidatorTest.java のコメントに仕様があるので確認
2. 仕様に基づいて、テストコードを書く
   • メモの項目などで仕様も漏れている
3. 本体プログラム UserValidator を書いたらテストしてデバッグしていく
   • テストコードと本体コードが異なるケースもある
   • バグもあるので、それを探しみよう
4. 余裕があれば、他のプログラムもやってみましょう

package validator;

import static org.junit.Assert.*;
import org.junit.Test;
import entity.User;

public class UserValidatorTest {

	@Test
	public void validatorTest001(){
		UserValidator target = new UserValidator();
		//テスト用のユーザーを作る
		User user = this.createNormalUser();
		//最初はエラー無しで正常動作、次にそれぞれのエラーパターンを動作させるのが定番
		assertEquals(target.validate(user), true);

		//正常なパターンも、実際には範囲があるので複数テストする。
		//【実装】ユーザIDが4文字

		//エラーになるパターン
		user = this.createNormalUser();
		user.setUserId("aaa");
		assertEquals("ユーザIDが3文字",target.validate(user),false);
		assertEquals("ユーザIDが3文字",target.getMessage(),"userIdは4文字以上で入力してください。");

		user = this.createNormalUser();
		user.setUserId("");
		assertEquals("ユーザIDが空文字",target.validate(user),false);
		assertEquals("ユーザIDが空文字",target.getMessage(),"userIdを入力してください。");
	}

	private User createNormalUser() {
		User user = new User();
		user.setUserId("fortest");
		user.setPassword("PASSWORD");
		user.setUserName("fortest");
		user.setAddress("東京都新宿区");
		user.setMail("dummy@dummy.com");
		user.setMemo("オートテスト");
		return user;

	}
}

package validator;

import entity.User;

// アノテーションでバリデーションしてしまわず、テストコード学習用に 1 つ 1 つチェックする仕様にしている
public class UserValidator {
	String message = "";
	public boolean validate(User user) {
		//userIdのチェック、必須入力
		if(user.getUserId() == "") {
			//userIdは必須なのでエラー
			message = "userIdを入力してください。";
			return false;
		}
		//userIdは4文字以上とする
		if(user.getUserId().length() <= 4) {
			message = "userIdは4文字以上で入力してください。";
			return false;
		}
		// userId は 20 文字以下とする
		// Todo:実装すること

		//user_nameは必須
		if(user.getUserName().isEmpty()) {
			message = "ユーザー名を入力してください。";
			return false;
		}

		// 住所は任意なので制限なし

		// メールアドレスも制限なし

		// メモも制限なし

		message = "";
		return true;
	}
	public String getMessage() {
		return message;
	}
}

テストコードと実装の違いを解説いただきながら、テスト結果が緑色になるようプログラムを修正していきました。

この体験がとても新鮮で、テストコードがナビゲーターのようになっていて、「動くかなー、テスト通るかなー」という不安がなく、とても楽しいものでした。

このあと結合テストの演習として、ブラウザ操作を自動化できる Selenium も実行してみたところで、このコースは修了しました。

まとめ

重箱の隅をつついても、とにかく「バグを探す」より、「想定通り」の動作を増やして、テストで確認するというのは、とても人間的でヘルシーな考え方でした。

その「想定 = テストケース」を増やしてもよいように、テストフレームワークを使った自動化をやっていこうというのは自然ですね。

また途中で触れた TDD のやり方、テストコードを書いてからプログラムを書くという体験は、不安がなく、とても新鮮でした。

テスト自動化は開発者にとって「心理的安全性」を育むものなのだと感じられたコースでした！

label SEカレッジを詳しく知りたいという方はこちらから !!

SEカレッジ
IT専門の定額制研修　月額28,000円 ～/ 1社 で IT研修 制度を導入できます。
年間 670 コースをほぼ毎日開催中!!

Learning Topics 編集部

SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。