画面動作テストを少しずつ効率的に進めるには

画面動作テストを少しずつ効率的に進めるには

Webアプリや業務システム、スマートフォンアプリの開発において、「画面動作テスト」は品質を左右する重要な工程です。『ボタンが反応しない、入力エラーが正しく表示されない、レイアウトが崩れる」等、こうした不具合はテストの段階で出来るだけ見つけておく必要があります。今回は画面動作テストを効率的に進める為のちょっとした考え方、実践ポイントを書いてみようと思います と思います。

1. テスト仕様書の内容を確認する

まず最初にすべき事は、テストに使用するテスト仕様書の内容を事前に確認しておく事です。
例えば以下の内容をさっと見て確認しておくことが重要になります。

• どの程度のテスト項目があるのか
• テスト内容は項目によってまとめられているか
• ユーザーが利用する画面なのか、管理者が利用する画面なのか
• 必要になる事前設定は何か　等々……

事前に確認しておく事で、最初から画面テストに取り掛かるよりもテストを行いやすくなります。必要であればテスト開始前に対象の画面を一通り見ておくのも良いでしょう。テスト仕様書の上では、同じ画面内の内容が複数の個所に飛んでいたとしても、事前に内容を掴んでおけば複数回画面を行き来する事なく一度に確認する事も出来るようになります。最も同じ画面のテスト項目は、テスト仕様書作成時点で纏めておくのが望ましいですが。

必要な条件・動きの流れ、そう言ったものを事前に確認して目的を明確にするだけで、実際にテストに取り掛かる時の余計な確認時間を減らす事が出来るのです。

例として以下のテストがあったとします。

■前提
・テスト項目数：150件
・1項目あたり：3分

▼ 改善前総工数
150 × 3分 ＝ 450分（7.5時間）

これを事前確認をする事でテストに取り掛かる時間を減らせた場合
■事前確認による削減
0.5分削減 × 150件 ＝ 75分削減
450 − 75 ＝ 375分（6.25時間）
計：1時間15分削減

勿論、毎回全てこのような結果になるとは限りませんが、テストに対する取っ掛かりをつかめているだけでも進行速度に差は出るのです。

2. 正常系と異常系を切り分ける

テストの流れにおいては基本的に正常系の動作と異常系の動作確認を行う必要があります。この時に効率を下げる大きな原因にテストの流れが整理されていない事があります。テスト仕様書の項目で『正しい動作の確認→エラーの確認→正しい動作の確認』といった流れになっていた場合、これに素直に従っていると逆に時間が掛かる場合があります。

正常系の動作と言うのは画面遷移を含む事が多く、入力→結果を確認する事になります。これの間にエラー動作を確認しようとすると、同じ画面を何度も何度も行き来する事になります。これが悪いとは一概には言えませんが、テスト項目が多ければ多いほど効率が悪化します。

そこでおすすめなのは、『まず正常系を一通り確認し、その後に異常系をまとめて検証する方法』です。あちこち行き来すると、状態管理が複雑になり確認漏れが発生しやすくなります。

同じ様に例を出してみましょう。
切り分けを行わず、順番通りにテストを行っていた場合は画面の往復が多発します。それを項目を切り分けて画面の移動を減らした場合は、操作そのものの回数を減らせるので確実に時間を短縮できます。
 
■正常系／異常系分離
150件中 約40％の項目で画面移動が発生と仮定
150 × 40％ ＝ 60件
60 × 0.5分 ＝ 30分削減
計：0.5時間削減

3. データ準備をしておく

画面動作テストで意外と時間を奪われるのが、テストデータの準備です。テストの動作確認には様々な条件のデータが必要になります。これらをそのテスト項目までやって来た時に、その都度用意していると時間のロスが大きくなってしまいます。

• 特定ステータスのデータ
• エラー発生用データ
• 上限値・下限値データ

事前にテスト仕様書の内容を確認し、上記に一致するデータが必要だと分かれば予め全てのテストデータを登録しておくと、動作確認時に手早く行なう事が出来ます。例えばユーザーデータである場合、「●●の確認用データ」といったメモを任意の入力欄に設定しておいたり、ユーザー名そのものに直接つけてしまうのも良いでしょう。そうしておく事で、管理側での大量のデータ確認においても見つけやすくなるわけです。テストデータについては日付を振っておく事も重要です。データ登録時の日付を残しておけば、後日確認する際にも何のテスト実施時に追加された物なのかも分かり易くなります。

ただこの時、単純に『エラー』と名をつけて後ろに番号だけ振っていく場合、後日再確認する時に何のデータか分からなくなったり、有効状態なのか分からなくなる場合もあるので、余程単純な内容でなければこの様な名づけは避けるべきです。

その都度データを用意するよりも事前に纏めてデータを用意する方法は、個人的におすすめです。体感的にもデータ入力の度にテストの手が止まるので、いい流れで作業で来ていたとしてもそれを失ってしまう事になります。しかし、事前に用意しておけばその流れを失う事はありません。

また事前準備の方が早くデータを用意できるのは、テスト仕様書を予め確認しておく事による内容把握にも繋がっています。

■テストデータ事前準備
データ必要件数：30件と仮定
その都度準備：30 × 2分 ＝ 60分

◆事前一括準備：20分
→ 60 − 20 ＝ 40分削減
計：約0.7時間削減

4. 記録を残し、改善する

一回の効率化だけでは、更なる効率化は完成しません。

• どこで時間がかかったか
• どんな不具合が多かったか
• 抜け漏れはなかったか

これらを振り返り、次回のテストに反映させることが重要です。地道な改善を繰り返すことで、テストは複雑な内容であっても、過去よりも効率的に確認を行う事が出来るようになります。

また登録したテスト用データについても、残しておくものと削除するものを整理しておく必要があります。テストによっては大量のユーザーデータを登録する事もありますが、この時のユーザーデータを全て残しておくか判断する必要があります。管理側でのリスト表示を圧迫したり、データ検索時の妨害になる事もあり得るからです。ただ単純に消しておくと言う判断をするだけでなく、その中で有用なものを残しておくといった判断も、効率化には必要になります。

5. まとめ

テスト仕様書を利用して画面動作テストを効率的に進める為には、様々な経験や工夫が重要です。そして効率化とは単純に作業を減らすことではなく、無駄を減らして経験を積み再利用出来る部分を増やす事です。テスト仕様書を単なる『テスト前に確認する物』として終わらせるのではなく、『実施するのにどうすればいいか』と考える準備としても利用すべきです。

そしてその積み重ねが、画面テストを少しずつ効率的に進められる糧となります。

最後にどれくらい変わるのかと言う例をまとめておきます。

また次回はこの内容を踏まえて、更に改善取り組みを行う事で更なる時間短縮を行う事が出来ます。これらはあくまでのテスト実施者による一例であり、全て同じ効果がある訳ではないのは理解しておいてください。また、テスト時間を短縮できるのは良い事ですが、『効率的である』事と『ただ時間を削る』事は意味合いが異なります。時間を削る事が目的となりテストの質が劣化していては意味がない事も、同時に理解しておきましょう。