名前や数字に潜むワナ（その2）

3回目まして。バグマニアのよっしーです。

前回は「人がつい陥ってしまうワナ」の例として、人名やチケット番号を挙げました。今回も「名前や数字に潜むワナ」シリーズとして、まずは前回に近いところから紹介します。

今月から法改正で「総額表示」が義務付けされました。ECサイトや小売りのシステムに関わっていたら、少し前にお仕事された方もいらっしゃるかもしれませんね。その際に、設計書や仕様書、チケットにはどのようにタイトルが書かれていたでしょうか。ECシステムなら例えばこんな感じでしょうか。

カート画面の法対応（「総額表示」の義務付け）
カート画面における消費税（税込優先）対応

自分で書いていたとしても、コピペをちゃんとしない限り、大体は表記揺れするんですよね。この例ならどの法律改正だったのか特定できますが、単に「税対応」「法改正対応」って書かれると、数年後に何のことだっけ？になりかねません。何の税金だか、何の法改正なのか不明ですから。税金は消費税だけじゃないですし、法律なんて覚えられないくらいありますよね。

結構ありますよね、ざっくり書かれていて主語や対象が一目見ただけでは判らないチケット。そのようなチケットは、将来の修正時に検索で引っかからなくて、影響範囲の調査から漏れる可能性がありますので要注意です。もちろん直す頻度や影響範囲は関わっているシステム次第ですが、アバウトなタイトルはバグ発見では狙い目になります。

ドキュメントにある文章そのものはソースみたいに後で動くことはないですが、それを読む人はそのテキストで判断してソースや別のドキュメントにつながる何らかの行動を取るはずです。ですので、具体的に記載して（似ていたとしても）特定できるようにしたいものです。

またチケットのタイトルだけでなく、GitやRedmineのコメントでも、何をするためのチケットやコミットなのか、意図や目的、根拠を書いておけば、表記揺れがあったとしても特定はできます。情報の不足なく簡潔に書ければベストですが、それはそれで技術（国語力）が必要ですから、後々判断ができるように長くても他と区別することを優先にしましょう、くれぐれも。

さてドキュメントやGitやRedmineに書かれた文章ではなく、その後動いてしまうソースの中ではどんなことに気を付けると良さそうでしょうか。例えば

daily_sum と daily_cal なんて function や
currency_code と currency_number なんて変数

があるとしたら、どうでしょうか。ネーミング一つでグッと危険度が増してしまいます。命名規則としてルール化されていて、それをちゃんと守って、きちんと区別して使い分けられていれば問題ないですが、ソフトウェア開発の現場でそこまで徹底されている所は多くはないでしょう。

このようなバグを発見早期にするために、名前や番号がどこまで似ていて、どこで何を探すって決めるのか、それぞれの現場によるものだと思いますし、迷うところでしょう。そんな時は、例えば大きな市場影響になりそうなところ、過去の不具合票に多くあるところ、開発がたまに漏らす「ここまずそう」など、ベテランQAにはある程度勘所があると思いますので、その中で探したり、開発に聞いてみるのも手です。

「人がつい陥ってしまうワナ」は、開発対QAという構図ができにくく、お互いの納得度が高いので、聞いたり実際に調査したりといったハードルが低いです。そんなに時間もかからないですし、ついでに気にするのに向いていますから、何かのレビューや会議の折にでも使えそうか試してみてはいかがでしょうか。

次回はちょっと視点を変えて、名前や数字とは別の「人がつい陥ってしまうワナ」についてお伝えします。

それではまた。