テスト仕様書.xlsx ツッコミまとめ

注意書き

mohikanz Advent Calendar 2023 の 12月3日担当記事です｡
リモワについて書きたかったんですけど､スプラも新シーズン始まって時間が足りないため､1年の総括として転職先で経験したテスト仕様書へ突っ込んでいきます｡

明日は､ゆいなさんの記事です｡

前提

実務であったツッコミどころの多いテスト仕様書.xlsx へ突っ込んでいきます

テスト仕様書がエクセル?という部分には突っ込まないことを前提としています｡

おかしい日付を入力する というテスト項目

• ｢おかしい｣という現象はコンテキストによって変化するためテスト項目として不適切である

  • 例えば､誕生日という文脈において､未来の日付は｢おかしい｣といえるため､テスト者によって適切なテストを行えないことが明白である

• 修正例

  • エラーと表示される見込みの具体的な日付をテスト値に設定する
  • 9999/12/31 システムの寿命として､まず存在し得ないため仕様側で考慮されているかどうかを通すためのテスト値
  • 2023/11/40 日付としておかしい文字列

絵文字不可 のインプット

絵文字 と指した場合､以下のテスト項目についてパスするかどうか､わからないため明確にエラーと予期される値を設定するべき

• 環境依存文字
  • ㍾㍽㍼㍻㋿ 他
• 4バイト文字
  • 髙﨑 など氏名で使われる可能性のある文字
• 絵文字
  • 🐯🐱🐶🐵 他
• 他､状況によって問題となる可能性のある文字
  • <>?;& 他

未満､以内､以降 などの混同

• 日付等で紛らわしいですが､こちらも明確なテスト値を記載することで問題なし

9 は 10 未満である ◯
10 は 10 未満である x

9 は 10 以内である ◯
10 は 10 以内である ◯

9 は 10 以降である x
10 は 10 以降である ◯

一つのシートに､テスト前提の違う似たようで違うテスト項目を並べない

• 例､管理者権限を持つユーザのテストと一般ユーザ権限を持つユーザのテストが同じシートに縦に並んでいる
  • かつ､テスト内容が微妙に違う場合など､テスト者の認知能力への負荷試験ですかね?
• テスト者が間違える可能性が高く正常にテストが実行されない可能性が高くなる

解決

• テスト項番を揃えてユーザごとにテストを行うことで明確に権限テストができていることを担保できます｡

1000パターンに近いテスト項目を一つのシートにまとめる

• テスト者に対する負担､および保守性の低下を招くので適切な粒度でテストを分割する
  • 例 更新機能
    • ユーザ権限､管理者権限
    • テスト条件､対象データ 自分､他人などでシートを分ける
• そもそもパターンが多ければいいという話ではないので､テスト対象と条件は適切に設定すること
• 分けておくことで､条件追加時に修正が容易になることが明らか
• かつ項番ごとに行うテストを整理することで機能がどういった権限で整理するべきかを明確にできます｡

操作後の確認対象となるテスト結果を一つのセルに詰める

• 保守出来ないこと､網羅性が明確にならない点から明らかに悪い

  • 想定例(bad)
    • ユーザ区分 編集､担当､作家
    • テスト結果(編集) a,b,c,d,e,f ができること
    • テスト結果(担当) c,d,f ができること
    • テスト結果(作家) b,d,f ができること

• 以下のように書くことで､追加や変更および把握が容易になります｡

  • 縦､横は状況次第で選んでください

テスト対象	編集	担当	作家
a	◯	x	x
b	◯	x	◯
c	◯	◯	x
d	◯	◯	◯
e	◯	x	x
f	◯	◯	◯

凡例:◯ 処理が正常に完了すること
凡例:x 処理が完了せず､エラーページへ遷移すること

テスト対象がリリース単位で1ファイルになっている

• テスト仕様書は最低限機能ごとに整理すること
  • 今後､機能が追加される場合､同一のテスト仕様書を使い回せるはずです｡
• アジャイルでもウォーターフォールでも考え方は同様

たった1枚のシートを共有するために､1ファイルになっている｡

• テストに入った時点で仕様確定しといて･･･？(理想論)
• 神テスト仕様書を作る前に､テスト仕様書に書くべきこと書くべきでないことを整理すること
  • 参照する必要のあるシートがあっても､別ファイルなどシートの値を参照するようなテスト仕様書.xlsx は bad です｡

仕様を把握している人間にしかできないテスト

• 前提となるデータについて解説をしていない(条件を確認できない)､仕様を開示しないなど
  • 限度はありますが､最低限のことは書く必要があります｡
  • 例 一般ユーザが作成したデータ(4件分)など

エクセルを使っているのにテスト達成率が手動集計

• エクセル使う意味ー

まとめ

• テスト仕様書はやはりテストコードを書くことに気をつけることや､リーダブルコードで学んだ内容を転用できると思います｡
  • 一つのファイルに全仕様を詰めたロジックを書くことはまず無いと思います｡
  • テスト実行する環境で変わるビジネスロジックへテストコードを書くこともないでしょう
• エンジニアとしての転職は初めてなので､今後もネタには尽きないでしょう｡良いお年を