今回の記事は、「過去の自分に教えたい、ソフトウェア品質の心得を投稿しよう by QualityForward Advent Calendar 2024」に投稿する記事になります。
絶対にやってほしいテスト
システム開発をするとき、テスト設計をしてテスト項目を決めていきますが、絶対やってほしいテストがあります。
それは、
意図しない入力
のテストです。
モンキーテストとも言われます。
何、猿にやらせるんかい！？
いやいや、違うんです。
仕様を知らない人にパッとアプリを渡して正しい使い方ができるか、もしくはランダムな操作をしてもらって不具合が出ないか、というテストです。
これは、いかに綿密にテスト設計しても、どこかに潜んでいるかも知れぬ未知なるエラーに遭遇できます。
「そんな入力するわけないでしょ」
と思いますよね？
そう思っているエンジニアの現場にいたこともある私は、
「 いるんだよ！ 」
と声を大にして叫んだことがあります。
叫んだけれども、そこはあれですよ。
権力に負けたというかなんというか、モンキーテストをテスト項目でゆるく設定してしまったことがあります。
社内システムなので大きな問題には発展しなかったものの、ヒヤリハットで挙がってきた時には反省しました。
なので、テスト項目には、 必ず 意図しない入力を考慮してください。
ソフトウェア品質の心得、それは、
「そんな入力するわけ、、、 あるよねぇ 」
を当たり前にすることです。
こうしたテスト内容は、テスト管理ツールで管理しておくと、過去のテストを見返して実装に反映できますので、是非ともテスト結果のバージョン管理も行い、反省する時間を少なくしましょう。
FileMakerでの「そんな入力」をテストするには
我らのFileMakerは、システム開発を専門にしていない人でも、思ったアプリが作れる、というのがとても魅力的です。
レイアウトの設定がそもそもスクリプトに相当するようにすごく単純化されていて一発で実装が済む、というのも開発時間の短縮に一役買っていますよね。
反面、レイアウトでの設定を怠ってしまうと、「そんな入力」を引き起こしてしまいます。
まず、「そんな入力」が起きるのを防ぐ準備（実装）をしておきましょう。
準備：入力設定を状況に合わせて設定(実装)する
「そんな入力、、、」をなくす第一歩は、入力設定を状況に合わせて設定することです。
テストではなく、実装の段階で、可能な限り状況に合わせます。
以下のような販売レイアウトを例に進めましょう。
(1) オブジェクト移動するキーを使い分ける
入力を素早く済ませたいために、タブやエンターキーで移動したいことがあります。
そのために、オブジェクトに移動するのに仕様するキーを指定します。
しかし、備考欄のように改行を含ませたい入力もあります。
その場合は、リターンキーやエンターキーをオブジェクトの移動に指定すると、改行文字列が入力できず、とても不便な使い勝手になってしまいます。
なので、改行が含まれると想定する入力フィールドでは、タブキーだけの移動にする、などの対策が考えられます。
(2)入力された情報に付加する
また、金額や数値入力では、３桁区切りや通貨記号を付加した状態で表示したいこともありますね。
入力された数値が円なのかドルなのか、マイナスなのかプラスなのか。
あやふやな部分を減らしておきましょう。
(3)使用する媒体に合わせた入力方法を選択する
ipadやiPhoneでこのレイアウトを表示して使用する場合は、数字だけ入力したいのに通常のキーボードがシュッと表示されると入力しづらいものがあります。
このストレスを軽減するために、インプットメソッドやタッチキーボードタイプの設定もしておきましょう。
この設定をしておくことで、金額欄に文字が入力される回数は少なくなるでしょう。
(4)入力可否を設定する
自動計算したり、一度設定したら変更したら困るフィールドもありますね。
そういうフィールドは入力ができないように設定したり、マージフィールドなどにするなどで対策が可能です。
(5)タブ移動順を設定する
そのほか、タブ移動の順序も流れに沿って入力できるように設定しておくと、商品コードを入力した後に備考欄に移動して無理やり入力させられる、、、というのを防げます。
タブ順を指定して、ノリに乗って入力してもらいましょう。
タブ順移動を設定する前はレイアウトにフィールドを配置した順番になっています。
なので、「全て消去」でタブ順設定をクリアし、設定しなおします。
表示のみのフィールドや、自動設定されるフィールドはタブ移動しないようにして、入力ミスしないようにします。
小さいことですが、「そんな入力するわけない」に対応する大きな一歩です。
テスト：わざと入力してみる
そして、入力テストです。
単価欄は数値であることがわかっていますが、わざと文字を入力して「ほれみろ」と言いましょう。
単価欄にドル金額を入力し、小計金額がおかしい、と叫んでみましょう。
商品コードを入力した後に備考欄に移動したら、「チッ！」と舌打ちしましょう。
備考欄で改行できなかったら、「なんでやねん」と呟きましょう。
嘘です。
テスト項目は結果とともに管理して見える化しておきましょう。
テスト：見える化する
QualityForwardを使った、テストの管理で見える化してみましょう。
そして、実行。
おっと、備考欄で改行が入らなかった模様。
今日やったテストの結果を見える化し、修正と再テストにつなげます。
まとめ
入力に関するテストはFileMakerに限らず行うと思いますが、FileMakerに特化した設定など、意外と忘れがちです。
自分だけが使うから、部署でしか使わないから、とにかく処理ができればいいから、という立ち位置から、一歩前進して使いやすい、そして「そんな入力するわけない」という思い込みを無くしましょう。
そして、テスト工程で大事なのは実施するテスト項目の選定ですが、次に大事なのはエビデンスです。
いつ、誰が、どのような条件でテストをし、どのような結果が出て、エラーの場合はどういう画面だったのか、などを残し、品質の担保をしておきましょう。
他の皆さんのソフトウェア品質の心得、ここで出会えます。
過去の自分に教えたい、ソフトウェア品質の心得を投稿しよう by QualityForward Advent Calendar 2024