入社1ヶ月目でやったこと〜ソフトウェアテストプロセスに基づいたテストケース作成を行ってみた〜

はじめに

この記事は10X 創業6周年アドベントカレンダーの15日目の記事になります。

昨日はアプリケーション開発部のjojoさん*1が、「10Xに入社した、そして4ヶ月後…」という記事を公開しています。

本記事では2023年5月に10Xに入社した私が、入社1ヶ月目に実際に行った、ソフトウェアテストプロセス（以下、テストプロセスと表記）に基づいたテストケース作成についてお話しします。

テストプロセスに基づいたテストケース作成を行おうとしたきっかけ

皆さんは以下のようなテストケースを作成していないでしょうか？

注意：この画像は極端に良くない例を提示しています。実際の業務で作成したものではありません。

このようなテストケースは、作成者以外が見ると非常に分かりづらいものとなってしまっています。

上の画像は極端な例として示しましたが、少なからず分かりづらいと感じてしまうものが10X内の成果物でも存在していました。

このような状況を改善するために、テストプロセスに基づいたテストケース作成をすることにしました。

前提：プロセスとは何か？

Wikipediaには以下のように書かれています。

プロセス（process）は、英語で「過程」「工程」を意味する外来語である。プロセッシング (processing) と言った場合は、「処理」を意味する。

入力を出力に変換する過程を示し、工業では「工程」と呼ぶ。

手続き(procedure)に着目し、対象を所定の手続きによって別のものに変換する活動を表す場合もある。

プロセスの例

定義だけ見ても分かりづらいと思うので、簡単な例を用いて考えてみましょう。

例えば、以下の計算問題を解いたとします。

これの答えは48ですが、ここでは計算結果ではなく過程（＝プロセス）に着目します。

人によっては、計算問題を見た瞬間に「48だよ！」と答えた人がいるかもしれません。

人によっては、掛け算をやって割り算をやって引き算をやると考えたかもしれません。

人によっては、まずはどの計算順序でやれば良いのか考えるところから始めたかもしれません。

人によっては、繰り下がりの計算であると気付いて、筆算で計算したかもしれません。

これらのどれが正しいかというのはありません。どれも正しいです。ここから、「人によってプロセスは違う」「プロセスを細かく分けることができる」といえます。

なお、プロセスを細かく分けることで、どこが間違いなのか気付きやすくなります。そこから、レビューもしやすくなることが分かります。

テストプロセスを考えよう

テスト活動に対して過程や工程を表したものをテストプロセスと呼びます。

（弊社10Xの状況ではなく）一般的に、テストプロセスがきちんと定義されていなかった時代には、テスト実行を行う前の内容を「テスト設計」や「テスト準備」と一括りに呼ぶことが多かったです。

一方で、JSTQB（Japan Software Testing Qualifications Board）では、以下のようにテストプロセスを定義しています*2。

「テスト設計」と一括りに呼んでいた部分を「テスト分析」「テスト設計」「テスト実装」に分けて表現しているのが特徴です。

冒頭で示したテストケースの例は、「テスト分析」「テスト設計」「テスト実装」が混ざって表現されているように見えたので、これらをきちんと分けて表現してみたというのが、入社1ヶ月目で行った内容です。

今回定義したテストプロセス

今回は以下の定義でテストプロセスを表現します*3。

テスト分析

「何をテストするか」を導き出す工程です。

今回は「テスト対象分析」「テスト要求分析」「テスト設計技法の選択」という3つに細かく分けました。

テスト対象分析

テスト対象となっているもの（プロダクト・機能）は何者なのかを明らかにする工程です。

この工程がないと、「今、自分はどんな機能に対して確認しようとしているのか」が迷子になってしまう可能性があります。

テスト要求分析

テスト対象となっているものに対して、「これができていればOKだよね」と言えるための条件（テスト条件）が何かを明らかにする工程です。

テスト分析の中でも一番の肝と言えます。

これが無いと、例えば「画面仕様書通りに実装されていたのでOK」というテストの進め方になってしまうかもしれません。そうではなく、「画面仕様書通りに作成はされているが、その実装の仕方だと今回の機能をお客さんがきちんと使えない」と指摘する必要があります。

テスト設計技法の選択

テスト要求分析で導き出したテスト条件を満たすために、どのようなテスト設計技法を用いるべきか選択する工程です。

ここで、テスト条件1つに対して選択すべきテスト設計技法が複数出てくると、そもそもテスト条件を分割すべきかもしれないことが分かります。

テスト設計

「どのようにテストするか」を導き出す工程です。

ここでは、テスト設計技法などのモデリング技術を用いて、いかに関係者が分かりやすい形で表現できるかを重要視します。

テスト実装

具体的な値を用いて、テスト実行をするのに必要な内容を書き出す工程です。

この工程では以下の作業を行います。

テスト実行に必要なデータの準備
テスト実行をするための手順書作成（手動テストの場合）
テストスクリプトの作成（自動テストの場合）

テスト実装時になって初めて、具体的なテスト値を用いることが多いです。

なお、一般的によく言われる自動テストは「テスト実装の自動化」であることが多いため、自動テストを作成する場合でもそれまでのテストプロセス（テスト分析、テスト設計）を行うべきだと思います。

記事冒頭の例が分かりづらかった理由

改めて、記事冒頭で示したテストケースを見てみます。

これが分かりづらい理由はいくつかあります。

テスト設計の成果物（1枚目の画像）で、「なぜこれを水準として記載しているのか」「何を気にしているのか」といった記載が無い
- テスト分析の内容がうまく表現できていない可能性がある
テスト設計の成果物（1枚目の画像）で具体的な値を指定しており、テスト詳細設計の成果物（2枚目の画像）が1枚目の画像の書き写しのような形になっている
- 1枚目の画像が、テスト設計のプロセスではなくテスト実装のプロセスを表現しているように見える

なお、おそらく、この成果物を作成した人もテスト分析やテスト設計といったプロセスで行うべき内容を頭の中で考えていたはずです。しかし、それを言語化し成果物に落とし込めてないように見えました。頭の中で考えて終わっていた部分を明確に成果物としてアウトプットするために行うのが、テストプロセスに従ったテストケースの作成となります。