今回は、「実機の操作からプログラムチェックリストを起こす方法」というテーマでお話しします。
かつてはドキュメントからテスト項目を起こす方法が一般的でしたが、昨今のスピード開発を考えるとあまり現実的ではなくなってきました。
実際の現場でもドキュメントが古いケースやそもそもないケースも珍しくありません。
よって動作中のシステムやソースコードからテスト項目を起こすという作業も必要です。
時代の変化に合わせて柔軟にテスト手法を転換していきましょう。
本記事の内容は以下の通り。
・システム動作からチェックリストを起こす手順
・実機操作からより網羅性の高いチェックリストを作るためには
実機操作からチェックリストを起こす手順
・実際にシステムを操作をする
・操作内容と結果を記録
・結果を観点に落とし込む
・チェックリストの作成
実際にシステムを操作をする
マニュアルや仕様書がある場合はその手順通りに操作してみましょう。エラーとなる操作も含めて全ての操作を実施します。
また、作業中に思いついたことがあればそれも試してみましょう。
私がQAにいた時は、元々チェックリストでやる予定だったものよりも「思いつきで操作したもの」、「オペレーションをミスったもの」の方が不具合に当たる可能性が高かったです。
実際に操作してみるとドキュメントから機械的に項目を起こすだけでは見えないテスト観点が見えてきます。
思いついたことはどんどん試していきましょう。
操作内容と結果を記録
操作したらオペレーションと結果を書き出します。後から全く同じ操作ができるように書き出す内容はできるだけ具体的な方がよいです。
・オペレーションの内容
・応答時間
・ポップアップメッセージ
・コンソールメッセージ
などできるだけ具体的な内容を記述しましょう。
テスト観点に落とし込む
記録した内容をテストの観点をテスト観点に落とし込んでいく作業です。
オペレーション内容をベースに大項目~小項目にテスト観点をまとめていきましょう。
項目の切り分けはざっくりとでよいです。
私が作る場合の切り分け方は以下の通り。
大項目:システムの各機能
中項目:条件を記述
小項目:詳細なオペレーションを記述
上記を表にすると以下のようなイメージになります。
大項目 | 中項目 | 小項目 |
機能1 | 条件1 | オペレーション1 |
オペレーション2 | ||
条件2 | オペレーション3 | |
機能2 | 条件3 | オペレーション4 |
条件4 | オペレーション5 | |
オペレーション6 |
チェックリストの作成
作成した観点表をチェックリストに落とし込んでいきます。
チェックリストはどのようなものでもよいですが、今回はマトリックスを作成する場合を例に説明します。
マトリックスとは以下のような表のことです。
上段はテストの条件、下段は実施後の確認内容を記述します。
日付欄には日付を追加します。右側はテスト項目です。
テスト項目は以下のようにチェックや確認するところに「〇」で記述します。
テスト項目は縦で1件です。(上記の場合は10件。)
条件で「〇」がついている点について条件設定や確認を行います。
例えば上記例の1件目なら「条件1」と「条件A」が条件で、「確認1」と「確認2」がテスト後の確認内容です。
テストの実践方法
テストの実践方法には、印刷して実施する方法とパソコン上でやる方法があります。
印刷して実施する場合はチェックした項目をペンでチェックしていきましょう。パソコンで実施する場合は、〇を●に書き換えるなどチェックしたことがわかるようにしておきましょう。
実機操作からより網羅性の高いチェックリストを作るためには
上記のチェックリストは実際の動きをチェックリストにしただけです。なのでそのままだとデグレード確認くらいにしか使えません。
より高度なチェックを行えるようにチェックリストを改善していきましょう。
改善内容は以下の通り。
・結果の妥当性を評価
・ユースケースをリサーチ
・イレギュラーなこともやる
結果の妥当性を評価
現在の動きが妥当なのか?という点を評価します。
例えば、
「ボタン押してこの画面が出るのは正しいのか?」
「結果は正しいけれど応答が遅い」
「ボタンの位置が見つけにくい」
「画面遷移が多くて操作が面倒」
などです。
時代によって要求されるスペックは変わっていきます。
以前は正しい動きであっても、現在も正しい動きとは限りません。
動作が正しいからOKではなく、時代に合った動きかも評価しましょう。
ユースケースをリサーチ
ユーザは開発者が思いつかないような使い方を平気でします。マニュアルやヘルプに「こういうことはやらないように」と書いてもそもそもマニュアルなんて読みません。
開発ばかりしていると「こんなことはしないだろう」という思い込みができやすいのでユーザの考えがだんだん理解できなくなります。
私も新人の頃は割と不具合を見つけるのが得意でしたが、開発を続けていくうちにだんだんユーザ視点が減っていき不具合が見つけにくくなりました。
ユーザ視点を失わないためにもユーザがどのような使い方をするかリサーチすることが大事です。
リサーチ方法は以下の通り。
・営業や顧客に聞く
・エンドユーザにアンケートする
・自分で実際に実機を操作して使用感を確かめる
また、他社製品を使うことで自社にはない使い方が見つかるかもしれません。自社製品だけではなく自社製品も積極的に使ってみましょう。
イレギュラーな操作もやってみる
マニュアルや仕様書通り操作しているだけでは不具合を見つけにくいです。マニュアルから大きく外れたオペレーションもやってみましょう。
思わぬ不具合が見つかる場合もあります。
終わりに
今回はシステムの実際の操作からチェックリストを作成する方法を紹介しました。
昨今のスピード開発を考えるとドキュメントからテスト観点を起こす方法だと遅いですし、効率もよくありません。
また、実際に操作してみるとドキュメントから機械的に起こすだけでは見えないテスト観点も見えてきます。
積極的に実機を操作して新しいテスト観点を生み出していきましょう。
Pythonの始め方>>Pythonプログラミングの始め方まとめ