河野大臣（当時）のポストから西暦のテストについて考える

テスト設計 技術

はじめに

本記事はソフトウェアテストの小ネタ Advent Calendar 2024で投稿することを忘れていたが、2024年に起こった出来事なので、今年中に公開しようとした記事となります。

本記事執筆のキッカケ

当時、デジタル大臣だった河野太郎氏がこんなポストをしていました。

このポストから学べることがいくつかあるので、考えてみたいと思います。

目次

学びその1：上の役職の人が声をあげると最優先課題になる可能性がある点

今回の場合は直属の上長では無いですが、デジタル大臣が声をあげた結果、その課題の優先度が最優先となってしまうかもしれません*1。

このような事象は度々発生します。

課題自体は解決できるかもしれませんが、そこにかける工数によって、他の課題解決に割ける時間が減ってしまうことこそが問題です。

学びその2：主観で課題を述べている点

今回のようなUI面での指摘は、主観で述べていることが多いです。その結果、優先順位を付けるのが難しくなる可能性があります*2。

今回の場合、どうすれば良いのか

QAや専門家が今回の点を指摘する場合は、今回の事象のどのような点が問題なのか/どのような部分をテストすべきか言語化するところから始めるべきかもしれません。

テスト条件

「何をテストすべきか」を示すものをJSTQBでは「テスト条件」と呼びます。*3

今回の場合、生年月日の選択肢に対してのテスト条件を考えてみます

現実的な選択肢を提示しているか

この方が述べている通り、最高齢の方（1908年）よりも昔の西暦を選択肢にする必要はないかもしれません。特に日本の場合は戸籍がしっかりしているので、さらに昔の西暦に更新される（最高齢の方が発見される）ことはないでしょう。また仮に発見されたとしても、その選択肢を使うのは1人だけですので、例外的な運用で処理しても良いかもしれません。

利用者のボリュームゾーンあたりを選択肢としているか

この方が述べている通り、利用者のボリュームゾーンあたりから選択肢が始まっているかを考えてみるのも良いかもしれません。

デフォルトの選択肢を空欄にしているか

より多くの利用者が操作しやすいということを考えると、最初から一番多いボリュームゾーンの西暦を選択した状態で始めるのが良いと考えるかもしれません。しかし、空欄にしていないと、選択するという意図をせずとも次に進めてしまうという別のトラブルが考えられます。

必須項目であり、確定申告という公的書類を作成することを考えると、元々の実装通り、デフォルトの選択肢は空欄であることが好ましいように思えます。

おわりに

今回は河野大臣（当時）のポストを元に、確定申告の西暦選択におけるテストについて考えてみました。

今回の事例には直接当てはまらないかもしれませんが、先日行われたWACATE 2024 冬にて、ユーザビリティの作り込み方についてのワークショップがあったため、参考として貼っておきます。特に資料後半の「人間中心設計によるライフサイクル」が参考になるかと思います。

speakerdeck.com

*1:なお、個人的には全く興味を持っておらず見ていないよりは、河野大臣のように見てもらっている方がありがたいと思います。問題はそれが伝え方によって最優先になってしまう点です。

*2:これは「河野大臣の指摘の仕方が良くない！」と伝えたいわけではありません。専門家でもない一般ユーザーが指摘をすること自体は否定されるものではありません。ただし、専門家が同様の指摘の仕方をしていた場合は改善点がありそうな気がしているので、今回話題にしています。

*3:JSTQBではテスト分析の成果物として定義されています。JSTQBの最新版シラバス（ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02）には以下のように書かれています。

テスト分析の作業成果物には、（優先順位を付けた）テスト条件（例えば、受け入れ基準など、4.5.2 項参照）、およびテストベース内の欠陥についての（直接修正しない場合の）欠陥レポートが含まれる。