[ooaa main]  [object pasta2]   [essence] (旧blogはこちら)  [flickr]  [myspace]  [View Eiichi Hayashi's profile on LinkedIn] 

JJaSST'09 Tokyo

いってきました JaSST2009東京。

http://www.jasst.jp/archives/jasst09e.html


現地で内容をもとに、こんどの新しいお客さんたちといろいろ議論できたものおもしろかった。


見たのはTDDライブセッションとパネルセッション,HPの品質の考え方について。


ポイントだけメモ

  • TDDで行うテストは品質保証のためのテストではない。 テストコードの網羅率は担当の努力目標、管理対象ではない。
  • 結果として品質保証テストでのバグは非常にすくなくなる。
  • 従来の画面操作によるテストはそのまま行いそのうえにプログラム工程の一部としてテストコード作成とコーディングを行う。
    • メモ:TDDで行ったテスト項目と品質のためのテスト項目はかぶる部分があるはず、そこをうまくマネジメントして効率化できるかも。
    • メモ:テストコードはプロダクトコードの2倍ぐらい。
  • 仕様領域から可能なすべての条件を洗い出そうとするとテストケースは無限になってしまう。
  • テストにかけるリソースをどこにどうわりふるかがポイント。 
  • 最小コストになるポイントは不具合によって発生するコスト曲線とテストにかかるコスト曲線のバランスをとった点
  • すべてがテストできないことと、有限のテストリソースをどう有効につかうかの観点をユーザーに見える化する。
  • リスクとテストコストのバランスについてユーザーに意思決定してもらえるようにする。
  • メモ:テスト条件空間については、仕様領域からだけテストケースをだしていたら、テストリスクの低いところにもテストコストをかけてしまう危険がありそう。
  • メモ:パネルで、少し話しにでていたがプログラムの構造を実質有効なテストケースを少なくするように設計することが可能だと思った。
    • メモ:機能の単位、依存関係の凝集度が適切であれば、おなじ作成品質でもバグ発生率が高いテストケースを少なくすることができるはず。(要検証。)