TEFに燃料投げたら秋山さんが答えてくれた

あきやま🍠 @akiyama924

きょんさんのメールがおもしろいから、答えてみる。でも、きっとにしさんから、MLでこたえてよーって言われるかも言われないかも。

あきやま🍠 @akiyama924

「単体テスト/結合テストなんて存在しない」っていうのは、論理的にはすぐ間違いだって証明できる。だって、うちの会社で存在しているから。

あきやま🍠 @akiyama924

けど、そういうことを言いたいのではないだろうから、何で存在しているか？って疑問に答えてみる。きょんさんは若いからビッグバンテストというのを知らないのかもしれません。ビッグバンテストというのはすべてができてから初めてテストする方法で、マイヤーズの本にも載ってたような気がします。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@akiyama924 MLにそれぞれ経緯を答えるようするつもりですー。にしさんにリプライもらいましたw

あきやま🍠 @akiyama924

大昔は、全てが出来上がってからテストしていたのですね。でも、もっと早い段階からテストってできるんじゃない？ってアイデアが出て、単体テストや結合テストなんていうのが生まれました。

あきやま🍠 @akiyama924

だからISTQBのテストの一般原則にもある「原則3:初期テスト」っていうのにもあっていると思うんですね。＞単体テストや結合テスト

あきやま🍠 @akiyama924

だから、私はテストレベルというのは、ソフトウェア開発（コーディング）のフェーズに合わせて考えるべきだって思っています（というか良くそう話しています）。だから、クリーンルーム手法のような開発方法論を採用していたら単体・結合はないですね。でも、きょんさんの言っているのは違うと思う。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

.@akiyama924 「単体/結合テストなんて存在しない」http://t.co/eXJgD6rC は「テスト戦略,テスト分析でカテゴライズしたテストをわざわざ単体/結合テストっていうものに再度カテゴライズせずに最初にカテゴライズしたもので実施すればいい。」っていう意味です。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

っていうのをもう少し詳細？にMLに明日あたりなげます。

あきやま🍠 @akiyama924

ということで、2つ目の「テストなんてないほうがいい」に移ります。これについては、「*複雑な*テストなんてないほうがいい」だったら大賛成です。巨大な組合せ表や、複雑な状態遷移図のテストのようなものは、しないですむようにすべきです。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

秋山さんが僕の爆弾に答えていてとても面白いTLになっています。

あきやま🍠 @akiyama924

けどねぇ、「テストなんてないほうがいい」って言われると、（何をテストと呼ぶかという話になってしまうかもしれませんが）人は誰でも間違えるからテストしようよと思います。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@irof 過激な発言が役にたった！（お

あきやま🍠 @akiyama924

ま。100年くらい先の世界では、人の代わりに、人工知能がテストしているかもしれませんけどね。いずれにしても、テストは無くならないと思いますし、無くすべきとは思いません。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

これあとでTogetterにしておこう。誰かに紹介するときにTogetterは便利だと知ったので。

あきやま🍠 @akiyama924

3つ目の「全網羅ができないとお思いですか？」に移ります。これは質問形式ですね。まず、テスト対象によりますね。Hello world!を出力するプログラムなら全網羅できますよね。ってそういうことじゃないよね。

あきやま🍠 @akiyama924

リリース日までの有限な時間（せいぜい1年）が与えらえた時に、1万行くらいのプログラムの全網羅テストができるか？ということを考えると、今度は、全網羅の定義によると思います。マイヤーズの本にあるようにプログラム構造の視点からの全網羅はできません。

あきやま🍠 @akiyama924

しかし、全網羅の定義を「そのソフトウェアの利用者達が出会う可能性のあるバグを全て出し切る」というものであれば多くの場合可能と思います。だから、この問題は、きょんさんの全網羅の定義を聞かないとわからないです。

あきやま🍠 @akiyama924

最後の、「証明できれば問題ない」っていうのはなんのことでしょう？　形式手法を使って証明できればバグはでないってことでしょうか？？

あきやま🍠 @akiyama924

仮に、そうだとした場合、証明するために付加したコード自体に間違えがある場合があります。せいぜいできるのは「仕様とコードの間の不整合の問題がなくなる」といったところですが、それでも大規模になると実時間では証明が終わらないですよ。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

MLで全部答える方がいいんだろうな。Togetterにしておいて、リンクはる形でいいか。

Kenichiro Ota @oota_ken

@akiyama924 Coqみたいな定理証明ツールを使えって命題を証明できれば、サンプリングであるテストは不要ってことだと思います。。

あきやま🍠 @akiyama924

と色々書いたけど、4つとも良いテーマですよね。真剣に考えるべきと思います。私の書いたことだって正解かどうかなんてわかりませんしー。

Kenichiro Ota @oota_ken

@akiyama924 後者は全く持って同意です。で、前者は命題の証明というのはその命題に対する関数が定義できるならばその命題は真ということらしいので関数自体が定義できれば、その関数自体が誤っているということはありません。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

なんか最終的に秋山さんにほめられた！わっほい！