Friendlyを作った理由 その1

これは「Friendly Advent Calendar 2014」の記事です。

なぜFriendlyを作ったかを書きます。

実は私はWindowsアプリ自動化歴長いんです。
9年くらいはやっているかなー。

と言っても、そればっかりやってるわけではなくて、普通にWindowsアプリ作る仕事をして、そのプロダクトのテスト自動化をやっていたのです。

デグレの恐怖

Friendlyを作った理由の前に、そもそもテスト自動化をなんでやろうと思ったかというとですね・・・。

「デグレ対策」ですね。

デグレの恐怖。皆さん知ってますね。でもおさらいです。

機能1実装

この人は機能1を実装したときにですね、色々考えて再利用性を高めるべく正しくモジュール化したのですね。そして機能1を実装し終わって、テストチームも交えてその機能が正しく動くことを確認してOKとなりました。もちろんここには、お金が掛かっているわけですよ。

機能2実装→デグレ混入

そして、機能2を実装しました。思惑通りBモジュールが、ほぼほぼ再利用できました。でも一部機能追加とか、若干の変更があったわけですね。

そして残念なことにここでデグレが混入してしまったのですね。

この時、彼は先輩の言う通り「ちゃんと」「意識して」デグレが発生しないように「頑張った」のです。

さらにですね、B単体で見たときには機能として不整合が無いように仕上がっていたのですね。「単に機能1の実装と合わなかっただけ」でした。

もちろん機能1に影響が出るのはわかっていましたが、機能1のテストをもう一回やり直すわけにはいきません。そんなお金は用意してもらっていないのです。なので理論的に考えて影響が出そうなところを軽くチェックしてOKにしました。

この時点では気づいてないのですね。

そして、機能2のテストも行われ、またここにお金が積まれるわけですね。

機能3実装

ここでも、機能Bを少しだけ改造して機能3を実装しました。思惑通りです。モジュールBを切り出しておいてよかったですね！工数がだいぶ削減できました。

そして、ここでも機能3のテストが行われ着々と掛け金が積まれていくわけですね。

そしてリリース直前のデグレ発覚

あー、見つかっちゃいました。リリース前に偉い人が何気なく触っていて機能1の不具合を見つけてしまったのです。「なんでテストしてないんだ！」偉い人は怒っています。

でもですね、開発チームはちゃんと一回テストしているのですね。

「えー、そのケースは確認してますよ。ほら」

確かに、前に一度パスしています。ということはデグレですね。

直さなきゃ。

そして調べてみるとですね・・・。

修正箇所は影響範囲が大きいのですね。

何といっても複数の機能から使われていますから。

修正確認を本気でやると凄いお金が掛かりますよね。

で、リリース前なので時間もないし、リスクも高い。

しかも、運が悪いことに、今回は偉い人に見つかってるから、話も大きくなっています・・・。

防ぐには？

正直、デグレってあります。「ちゃんと」「意識」してもなくならないでしょう。

ただ、早期発見したら、修正にかかるコストは減らせます。

例えば、機能2の開発中に発見されてたら、問題はだいぶ小さかったですよね？

だって、影響範囲にまだ、機能2と機能3をカウントしなくていいもの。

現実問題としてリリース前でなく開発中なら、不具合の重みも違いますよね。

それを実現するには、機能1のテストが一回こっきりじゃなくて、その後毎日毎日実行してくれてたら良いのですよね。でもそんなの人間には無理です。お金かかります。

（仮にかからなくても、同じテスト繰り返すなんて精神的に無理です。）

じゃあ、自動化するしかないですよね！

単体テストじゃダメ？

これはですね。よく聞かれます。

まあ、正直に言うと僕がテスト自動化を始めた頃って、そんな単体テストで保障できるような設計のシステムに関わっていなかったので、外部仕様から確認できるレベルで抑えることしか最初から眼中になかったのですね。

まあ、今なら「そこは単体で抑えてたら大丈夫」みたいなのもあると思います。

ただ、結合したときの「思わぬ不具合」みたいなのも絶対ありますし、あと「外部仕様から分かるレベルでの確認が必須」みたいな要件もあります。これはホントにケースバイケースではないかなーと。

ま、そんな感じで僕は「システムテスト自動化」に重きを置いて自動化手法を研究していくのでした・・・

明日に続く・・・

ちょっと、長くなりましたので、今日はここらで切り上げて続きは明日書きます。

Friendlyを作った理由までたどり着きませんでしたね。

正確には「テスト自動化を始めたきっかけ」かなw