ちょっと前の話、「ソフトウェアテストの7原則」のオマージュとして、「ソフトウェアバグの7原則」というのを思いつきました。
キッカケは冗談だったのですが、思いのほかいろんなアイデアをいただきまして、「ならちゃんとやろう！」として、「ソフトウェアバグ*1の7原則 Ver.1.0.0」として、2022年7月4日に公開したのでした。
勝手版・ #ソフトウェアバグの7原則 Ver.1.0をリリースします。ドラフト0.9にいただいたご指摘を反映しました。ご意見いただいたみなさまに感謝します。
— Kazu SUZUKI (@kz_suzuki) 2022年7月4日
ご意見はこのツイートにぶら下げてください。いつか反映します、いつか、多分・・・。
月曜にして、すでにやりきった感。 pic.twitter.com/7mRqYgzUGc
急ごしらえで、強引に7つに統合したこともあり、違和感のあるもの、洗練されていない部分もあると思いますが、眺めてみてもらえると幸いです。
ソフトウェアバグの7原則 Ver.1.0.0 (2022/7/4)
前提
- ここで「原則」は、「いろいろな状況で当てはまるパターン」のこととする。
- 「テストの7原則」には「欠陥の集合」についての言及がある*2ので、ここでは「個々の欠陥」を扱う。
1. テストしなければバグは見つからない
バグは、テスト*3をして初めて見つかります。知識だけ増やしてもバグは出ないし、怪しい場所を避ければそこにあるバグは見つかりません。テスト、テスト！
テストで見つからなったバグは、永遠に眠ったままか・・・、本番環境で見つかることになる！
ので、「テストでしか見つからない」というと語弊はあるのですが、ここで言いたいのは「勉強や検討を一通り済ませたら、早々にホンモノ使ってテストしようぜ！」みたいな勢いを表現したものです。
2. バグが単体で存在するとは限らない
1つのバグを見つけたら、近い箇所に似たバグがきっと見つかります。あるバグが他のバグの発現を隠していて、直したと思ったらまた問題、となることもあります。
この項目は、いただいた複数のアイデアを強引に1つに押し込んじゃっています。。
前半は、いわゆる「類似不良」を意図していました。ある間違いに起因するバグがあれば、同じような間違いを他にもしていることが多いというお話です。
後半は、あるバグを直してその部分が正しく動いたことによって、他のバグにぶつかるといった状況のことを意図しています。修正範囲や影響確認の見誤りによる問題ですね。
3. 再現できないバグはない
バグは、単純・単一の条件で発生するとは限りません。いくら試しても再現しないこともあります。それでもやはりバグには、何らかの発生条件があるはずです。
これは、『ソフトウェアテスト 293の鉄則』の鉄則077からの引用として、いただいたアイデアです。
もちろん現実には、時間・工数・能力の制約があったり、真にレアレアな発生条件だったりして、「再現できなかった・・・」となることはあるでしょう。ここでは、「現象には原因があるはずで、その特定をサクッとあきらめてはならん」という教えとして取り上げています。
ついでに、こんなツイートを思い出しました。
物理学者「プログラムは思ったとおりではなく書いたとおりに動く」
— 加藤岳生 (@takeokato719) 2019年7月15日
コンパイラのバグ「果たしてそうかな？」
ハードのバグ「ナイーブすぎやせんか？」
計算ノートのバグ「俺もいるで」
近似のバグ「私をお忘れか」
宇宙線「ちょっと前を通りますよ」
4. バグの重要度は状況に依存する
開発者目線では簡単なバグでも、運用上大きな影響を持つかもしれません。ある時点では軽くても、時間が経って重大なものに変わることもあります。
チケットに、「重要度」というフィールドを持たせているチームは多いと思います。この重要度を、開発者としての立場だけで判定してしまうと、改修の優先度付けを誤ってしまうかもしれません。「ユーザ影響」ってやつをしっかり考えて、ユーザ目線での「重要度」を決めるのがよいでしょう。
ちなみに、「テストのブロッカーになるからすぐに直す必要がある」といったものは、「重要度」ではなく「緊急度」「優先度」みたいな別のフィールドにするのもいいと思います。
5. 修正の大きさとバグの大きさは関係ない
「簡単な修正」「軽微なコードフィックス」だからといって、その作業におけるミスのもたらすバグの影響が「簡単」「軽微」とは限りません。
「バグの大きさって何？」というご指摘をいただきました。確かによくないタイトルです。
言いたかったことは上の通りで、簡単な修正だと気が緩みかねないので、イマシメ的な項目です。
いまさらですが、#4と若干重複していますね。
6. 「レア」のはずのバグが本番で牙をむく
テスト環境よりも、現実の環境の方が多様で複雑です。「レアケース」だったはずの発生条件が、本番環境であっさり起きることもあります。
若いころに、「本番環境は魔窟」とか、「レアと思ってても、ユーザが多ければだいたい起きる」とか、さんざん言われました。そういう意味では、バグチケットにありがちな「発生頻度」というフィールドは、「レア＝当面直さなくてもいい」とミスリードしてしまうリスクがあります。
テストでいろいろな条件を尽くしたつもりでも、本番環境におけるシステム構成、タイミング、運用期間、ユーザ操作は、それを軽々と越えてくると考えておくのがよいのでしょう。
なお、発生頻度については、以下のような記事を書きました。
7. 「運用でカバー」ではカバーしきれない
プログラムを直すのは大変なのでマニュアルに明記して、運用チームやユーザに回避してもらう・・・。多くのチームがそう期待し、結局そのバグを踏みます。
UXで有名なヤコブ・ニールセンさんの言葉に、こんなものがあります。
コンピュータ上のドキュメントに関するニールセンの第一法則: 誰も読まない
マニュアルにいくらデカデカと「注意事項」を書いても、それが読まれるとは限りません。読まずに問題が起きてしまった場合、「いやマニュアルに書いてあるじゃないですか！」と言い張れるものか・・・言い張ったとして、それが長期的にいい結果につながるか・・・。
暫定措置としてどうしても必要な場合はありますが、「恒久的に運用でカバー」は、いい結果をもたらさないでしょう。
?. バグと認めなければバグではない
バグと認めたら負け、なんて・・・ そんなこと言う人はいません・・・よね？
これは、この原則の話のキッカケとなった、ネタでございます。
バグじゃない、仕様だ！
おわりに
あらためて「解説」めいたものをつけてみると、やっぱりまだまだ取捨選択・洗練が必要かなーとも思います。
Ver.2.0を作りたい方、あるいは自分版を作ってみたい方、ぜひ検討してみてくださいませ！
