Enterprise Test Forum 2011に行ってきた。あるいは「良い設計」はどこから生まれるのか？
Enterprise Test Forum 2011 に行ってきた。
プログラムはこちら
以下、感想などのメモ書き
- 【基調講演】人海戦術のテストはもう時代遅れ〜自動化で工数を10分の1に〜
- リプレース案件での単体、シナリオ、性能テストについての報告。24Webサーバ+DBサーバ。５ヶ月くらいの納期
- コールセンターのバッチシステムリプレース案件。とにかく短納期。
- 本番、リプレース先の環境で同じデータ、同じバッチを実行させてDWHが更新された行のみコンペアするなどで時間を短縮した。
- 性能テストもシナリオを作る時間がなかったのでピークタイムのSQLを解析してリバースしてシナリオを作った。
- テスト自動化導入と成功の鍵
- 二人で同時にセッションするという変わったスタイルのプレゼン。正直聞きづらかった。
- テスト自動化で思ったよりも効果が上がらないのは「テストの実行」だけを自動化しているから。
- テストには設計、構築、実行、分析、レポーティングなど様々な段階がある。全体をみれば自動化出来る部分はもっとある。
- 自動テストの落とし穴。テスト自動化以前の問題を解決しないと自動化のメリットは享受できない。
- 悪い設計
- 闇雲なテストケース
- コードメトリクスと組み合わせて闇雲なテストから脱する。
- テストを自動化すると管理コストが発生する。管理コストと、自動化によるメリットのバランスを取ることが大事。
- 失敗事例から学ぶデータベーステストの勘所
- 前半は製品の宣伝っぽかったのであまり聞いていなかった。ごめんなさい。。。
- テストデータのセキュリティを考えているか？
- テストにはそれっぽいデータを使いたい。件数もそれなりにほしい。
- ついつい本番データを使ってしまいがち。事実、89％の企業で本番データを用いたテストを行なっているという調査結果。
- その本番データ、本当にセキュアな環境で使っていますか？
- セキュアな環境でないならマスキング大事。
- 単純なマスキングはデータのカーディナリティ(種類)を小さくしてしまう。性能テストの際などは、カーディナリティを下げない工夫が必要。
- DBにチューニング機能が付いているならば、まず使ってみるべき。
- OracleEnterpriseManagerも最近は多機能化＆見やすくなってきたので使ってみてほしい。Oracle SQLDeveloperでも可。
- Oracle製品でも実行されているSQLから性能テストのシナリオをリバースして作成するものがあるらしい。
「良い設計」はどこから生まれるのか？
面白かったのは、「テストの自動化には良い設計が必須」とすべてのプレゼンターが口をそろえて言っていることだ。
テストの自動化が作業の効率化に寄与するかどうかは、テストスクリプトの作成だけではなくスクリプトのメンテンナンス性も大きく関係する。
メンテンナンス性の低いテストスクリプトや、変更があるたびに作り直さなければいけないテストスクリプト、テストの前準備に手数がかかるスクリプトは
オーバーヘッドが大きく、作業の効率を落とすことにもなりかねない。
しかし、システムの設計はテストツールベンダーが口をだせるところではない。
「きちんと疎結合のシステムを設計して、効率をあげられるテストをおこなってからツールを評価してほしい」というのが本音だろう。
一方で気になったのが、そのツールベンダー側からTDD（テスト駆動開発）の話が一切出なかったことだ。
僕も所詮なんちゃってTDDをやっている身分なので偉そうなことは言えないが、TDDで開発をしていると
やはり「テストしやすいコード」あるいは「疎結合の設計」になりやすいと感じる。
これは結合テストや性能テストをおこなう際にもある程度メリットになるだろうし、開発の中心にテストが据えられることで
開発者の意識がテストに向くという効果もある。
テストツールベンダーとしては推奨して損はない開発手法だとおもうのだが、今回はどのベンダーもTDDというキーワードすら出してこなかった。
ここに何らかの思惑があったのか、単に関係のない部分だとおもっていたのか分からないが、テスターやQAからみたときの
「良い設計」にするための施策はどんなことが考えられるのか？ぜひ突っ込んで聞いてみたい。
