稼働しているシステムの機能変更は意外と難しいものです。Webページのレイアウト変更や表示の算出方法の変更は比較的気軽に対応することができますが、気を遣わないと思わぬ問題が発生してしまう場合もあります。
今回は実例からシステム変更時に注意したい設計とテストについて大事だなと思った点を備忘として残しております。
テスト不備によるバグの例
モバイルSuicaで2017年12月から一部のユーザーがアプリにログインできない現象が発生しているようです。
今回の問題はセキュリティ強化のためにログインパスワードの最大桁数を8桁から20桁に変更したところ、9桁以上のパスワードを設定していたユーザーがパスワード不一致となったようです。
原因としては、アップデート前から9桁以上入力可能でしたが、システムは8桁までしか利用しておらず、9桁以降は捨てていました。
ユーザーは今まで9桁以上の入力でログインできていましたが、アップデートによって20桁まで認識するようになった結果、データベースとの不一致が起こったようです。（ユーザーはこれまでどおり9桁以上を入力するも、システムには8桁まででしか記録されていないため）
考察
ご紹介したモバイルSuicaの実例は、アップデートで不具合を修正した結果、不具合がある状態で登録されたデータに不整合が起きた例です。
そもそものパスワードの扱い等に関する議論もあるかと思いますが、今回は”テスト（システムテストや受入テスト等）で見つけられたはずの不具合である”という観点で考えます。
テスト時には大切な事項はたくさんありますが、今回はモバイルSuicaの不具合を防げた可能性のあるテストの観点をメモとして残しています。
受入テストでは生データも仕込むべき
今回の場合はおそらく、テスト時に「修正前のパスワードが8桁までしかないから、8桁のテストをすればよい」という観点でテストを実施してしまっていたと考えられます。
テストでは「都合の良いデータ」を準備してテストを実施しているプロジェクトが多々あります。
業務内容も何も知らないプログラマーが単体テストで行う場合は１００歩譲って（ダメだけど）良いとして、仕様を把握している方が行うシステムテストや受入テストでは「都合の良いデータ」ではなく実際に登録されている「生データ」を用いてテストをすることは私は必須と考えます。
実際に普段使いをする
これはテストとはちょっと毛色が異なりアプリやWeb等で公開されているサービスに限りますが、当アプリのシステム関連の関係者がみんながモバイルSuicaアプリを使っていれば、数名は9桁以上のパスワードを設定している人がいたでしょう。
9桁以上のパスワードを使用している人であれば今回の仕様変更に対して「アレ、9桁以上パスワード入力しているのにシステムでは8桁までしか判断してないの…？？」と違和感を覚えたはず。
（違和感が無かったならシステム屋向いていない…）
最後に
今回は実例を挙げて簡単に考察してみました。
新米のプログラマ・エンジニアはプログラミング（コーディング）が自分の仕事と思っている方も多いはず。しかし開発現場で経験を積めばわかりますが、一瞬で終わるけどテストに時間をかけるということも多々あります。
プロジェクトを通して最も多く工数をかけるべきは、ドキュメントでもプログラミングでもなくて
テストなんです。
ITエンジニアにとってプログラミングができることは
“当たり前”で、どれだけテストでバグを洗い出しバグが無い状態で仕上げられるかが最も重要なことです。
開発現場はテストが命！
