単体テストを中心としたテストレベルの話

鈴木三紀夫 @mkoszk

@kyon_mm TEFへの返信の前にツイートで。要求工学の基礎では要求のスコープというのが定義されています。ビジネス要求、システム要求、ソフトウェア要求がそれに当たります。これを僕は社内研修でずっと「要求のレベル」と読んでいたんです。テストレベルとの対比で言っていたんですね。

鈴木三紀夫 @mkoszk

@kyon_mm 対比すると、受け入れテスト、システムテスト、単体／統合テストになるからです。でもね。それは要求のレベルじゃなくて、要求のスコープだと指摘されて、最初は何を言っているのか分からなかったんだな。だけど時間が経つにつれて分かる部分が増えてきたんだ。

鈴木三紀夫 @mkoszk

@kyon_mm さて、本題に戻すと、テストレベルやテストフェーズとしての区分けは見直した方がよいと思っているとして、テストのスコープとして捉えるのであれば、認めることは可能でしょうか。

鈴木三紀夫 @mkoszk

@kyon_mm ちなみに、ＭＬにあった単体テストの例「画面単位でのテスト」は、組込みの人の中には理解できない人もいると思います。ソフトウェア工学では画面単位のテストは結合テストになるからです。僕はにしさんと全然話がかみ合わなくて絶望したことがあるんだ。

鈴木三紀夫 @mkoszk

@kyon_mm 「それ、モジュールやクラスに分けないで、１つのプログラムで画面を作っているの？」　そんなことはありません。　「複数のコンポーネントの組合せでできているんでしょ。」　はい。　「それ、結合じゃん。」　いや、その、単体って言っていまして。　「社内ででしょ。」　・・・

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

@mkoszk 僕の想像だとスコープとしてとらえるとプロダクトコードベース(クラス、パッケージ、ライブラリ、最終的なバイナリ、など)で考えてしまうのですが、他にどのような捉え方があるでしょうか？

鈴木三紀夫 @mkoszk

@kyon_mm 画面やサブシステムもスコープだよね。

鈴木三紀夫 @mkoszk

@kyon_mm 要求工学との対比で、スコープという言葉を使ってみたんだけど、テストでスコープというと別の意味になるから、ややこしいかったですね。意図が伝わるとよいのですが。

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

@mkoszk テストスコープとテストレベルを上手く区別できていないのですが、テストスコープを定める場合に先にいったような具体例があがるならその名前を使えばいいと僕は思ってしまうのですが、それらをまとめて単体/結合というほうが便利な場合があるのでしょうか？

鈴木三紀夫 @mkoszk

@kyon_mm スコープ概念を持ちだした理由は、「単体／結合の区別は必要ない」と言ったとき、ビッグバンテストを意図しているというふうに解釈される可能性があると思ったから。工程とレベルは異なるというのが僕の意見だけど、一緒だという意見の人もいるので、スコープという言い方をしたんだ

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

@mkoszk なるほど。その点に関してMLの質問でもお気遣いいただいてありがとうございました。僕も工程とレベルは独立していると思います。

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

@mkoszk 僕も新人のときに初めてコードを書いて、初めて単体テストするときに同じような疑問を持っていたのを思い出しました。

鈴木三紀夫 @mkoszk

@kyon_mm 前職のとき、「単体テストの定義を教えて欲しい」という人がたくさんいたんだ。僕の答えは決まっていてね。社内で単体テストというときは、ソフトウェア工学とは関係ありません。契約の単位です。または進捗報告の単位。

鈴木三紀夫 @mkoszk

@kyon_mm 受託開発の場合、単体テストまでは請負契約で、結合テストからは準委任契約になることがあります。請負契約ですから瑕疵責任が発生します。責任が取れる範囲までを便宜的に単体テストまでというケースが多いのです。結合というと範囲が広くて責任取れないので。

鈴木三紀夫 @mkoszk

@kyon_mm 契約の言葉だから、契約単位つまりプロジェクト毎に違っていたり、同じチームで保守していても案件毎に異なるケースがでてくるのです。「単体テスト」という言葉が、アトミックなレベルのテストという意味では無いのです。まぁ、これは質問者が期待する回答では無いんだけどね。

鈴木三紀夫 @mkoszk

@kyon_mm 質問する若い子は、プロジェクトが変わったり、案件が変わる毎に、やるべきテストが変わるから困惑しているのです。だから、会社として統一的な見解を出して欲しい。それには応えず、契約の言葉だから契約単位によって定義が異なるという見解は、期待はずれの回答なんだ。

鈴木三紀夫 @mkoszk

@kyon_mm 戻すと、単体／結合テストの区分けに意味が無いという意見の場合、 snsk さんのような立場の人と、 kyon_mm さんの立場の人がいて、それぞれ意見は重なり合う部分もかなりあるけど、立ち位置が異なるため発言の意図が違うということはよくあるので、確認したんだ。

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

@mkoszk なるほど。僕の言っているやり方だと「（外部へのリリース後のテストを鑑みた上で）外部へのリリースまでのテストをプロジェクト毎に定義しましょう」になります。結果としてsnskさんと同一になる可能性もありますが。

鈴木三紀夫 @mkoszk

@kyon_mm 契約の話は置いておいて、概念としての話をすると、きょんさんは、テスト工程だけにしておいて、その中でプロジェクトに応じて段階的にテストをすればよいという意見だと思います。「段階的に」というとレベル概念で、「範囲を広げて」というとスコープ概念になりますが。

鈴木三紀夫 @mkoszk

@kyon_mm 僕もその意見に賛成で、現実と摺り合わせるなら、テスト計画で段階的、または実施範囲をそれぞれ定義して、開発工程に割りつけるのがよいと思っています。これは、一般的にテスト計画の話でね。テスト計画の研修とかを受けると教わると思いますよ。

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

@mkoszk はい。そうなるんだと思います。あとはその分類したテストそれぞれを顧客にどう見せるかは企業次第になるのかもしれません。

鈴木三紀夫 @mkoszk

@kyon_mm そこまで分かっているのだったら、心配しなくてもよかったかも。(^^;)　前職のときスタッフ部門にいました。そのとき、いろいろな現場から突き上げ食らっていたので、ついつい口を出してしまいました。

鈴木三紀夫 @mkoszk

@kyon_mm まぁ、より現実の話をすると、いちいちプロジェクト単位で段階を区切って、または範囲を定義していくというのは、プロジェクト毎の負荷が高い。そのため、幾つかのバリエーションを会社標準として作っておいて、テスト計画を作る時にそれを参照するやり方が一番多いかな。

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

@mkoszk そうですね。アプリケーション毎に例えば「今回はRIAに凝っている」とかで異なってくると思うので、そういった差異部分を認識して標準ベースに推敲するのが現実的だと思っています。

鈴木三紀夫 @mkoszk

@kyon_mm 組織の標準を批判するのではなく、上手く使いこなした方がいいですからね。