![[ARK-Web SandBox]](image/sandbox.gif "[ARK-Web SandBox]")
- バックアップ一覧
- ソース を表示
- 「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート は削除されています。
- 1 (2006-09-27 (水) 11:46:40)
- 2 (2006-09-27 (水) 12:28:58)
- 3 (2006-09-28 (木) 09:34:12)
- 4 (2006-09-28 (木) 09:34:12)
「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート?
目次 †
このエントリーは †
06/09/26に行われた「プロジェクト成功のためのソフトウェアテストの勘所」の講演をメモしたものです。メモは基調講演（高橋 寿一さん）を中心にまとめています
日時・場所 †
- 日時
- 2006/09/26
- 場所
- 青山ダイヤモンドホール
記法 †
- 赤字は強調
- 青字は進地の感想、思いつき
基調講演 †
- 演目
- 「テストの自動化の理論とその実際」
- 講演者
- 高橋 寿一さん
ソニー 株式会社 情報工学博士
- 領収書のテストの額がすさまじい（期末で）
- テスト屋さんは忙しい（寝ずにな感じ）
- あまり徹夜をせずにHappyな方向を模索したい
- 今ソニーはユーザ事例はナーバス（火を噴いたりね^^）ということで学者の立場から発表します
- James Whittaker(高橋さんの大学院時代の先生）
- マニュアル（道・仕様）を少しでもはずれると危険（バグ）に遭遇
- ソフトウェアは道を広げる作業
- ユーザ満足度の観点からハング/フリーズはクリティカルなイメージ
どんなに使いやすくてもクリティカル。安心して使えるソフトのリリース。その為にあるテスト。 - 自動化は広い道を作るためにという認識が重要
- マニュアル（道・仕様）を少しでもはずれると危険（バグ）に遭遇
- ソフトウェアテストとは
- 「バグを全部見つけるのは無理だと心得よ」 by Cem Kaner
- 「エラーはみつからないだろうという仮定のもとにテストの計画をたててはいけない」 by J.D.Mayers
- ソフトウェアテストとはバグを見つけること
- バグを見つけられなければどんなに自動化、効率化しても無意味
- 最初にプランニングしてからツールの選択をしなくては
（製品によってプラン、ツールは変わってくる。そしてどんなバグを見つけるかによっても） - ツール利用が望ましい一般的局面
早いタイピング、大量データ、長いRun時間のテスト
- バグがよく見つかっているところからさらにバグは見つかる傾向
- ツールの高い、安いとかどちらがいいとかって話は無意味
- まずはテストありきで考える（ツールありきではない）
- テストの本来の目的
- バグを見つけること、品質保証
- 自動化の目的
- コスト削減＆効率化
- 本来のテスト手法を見失っていないか？
- テスト手法を知らずに自動化してないか？
- たとえば？
- テストデザインもしないでプログラマに自動化ツールを書かせる（せめてデザインはしてよ）
- 自動化の罠
- 戦略無しの自動化（自動化率90%とかのアホいことを言ったりとか。それでバグ見つかってる？）
- 期待が大きすぎる（自動化がすべてのバグを見つけて品質保証するわけじゃない）
- 戦略的なトレーニングがない（ツールのトレーニングは戦略レベルに達しておらず低レベルなものが多い）
- ツール選択ミス
- ツール会社の罠
- Microsoft Test のマニュアルの１ページ目の図
※ツールを使えば２回目以降の繰り返しではコストが激減し、固定化している図- ２回目以降は自動化すればコストかからないの嘘
たしかに理論的には正、だけど実務的には間違ってるよ。
自動化のメンテナンスコストがあるよ（費用↑）
仕様が変わったときにいちいちツールのコマンドやスクリプトを変えないといけないよ
- ２回目以降は自動化すればコストかからないの嘘
- Microsoft Test のマニュアルの１ページ目の図
- 繰り返し愚考の罠
- 20%に80%からバグが発見。50%のモジュールにはバグは含まれていない。
50%部分に対して（自動化）スクリプト書かないこと - 『プログラムバグが出るところは開発者が上手く直せない箇所である』
だから回帰テストが必要になったり、この部分に自動化テストする意味がある
- 20%に80%からバグが発見。50%のモジュールにはバグは含まれていない。
- ほとんどのバグは自動化コードの設計、コーディングしている時にみつかる
- たしかに経験上テストケース書いている時に殆どのバグが見つかることが多いなぁ
- 何も考えずに自動化しても何のコストメリットも品質メリットもない
- 効率とコスト削減
- 開発工程でテストがしめる割合は41%（プロジェクトやデータ採集方法によって違うけど）
- コーディングはわずか13%、デザインは25%
- テストにお金がかかって黒字が出ない。ソニーでも。コストを抑えたい。
テストエンジニアにはビジネスセンスも必要。
- 開発工程でテストがしめる割合は41%（プロジェクトやデータ採集方法によって違うけど）
- 自動化ありきじゃなくていい（自動化でバグが見つからないなら）
オフショア（典型的な中国のオフショアコストは25万円/月） ＜ OR ＝ OR ＞ 自動化 ツール（100万とか超えるよ？しかも、固定資産税もかかる）
で決定するべき
- テストの自動化Ｘ％とかは全く無意味な数字
- 「テスト網羅率100%です」などといった頭の悪いこと言わないようにしよう
- コスト削減したいなら、自動化より先に作業の無駄を減らすこと
- 無駄なテストケースを減らす、開発スタイルの無駄を減らす
- 無駄なテストケースを自動化すると全てごみ化しますよ
- 最近のソフトウェアは組み込みだったらソースは100万行超える。ので、テストケースが軽く1万行超える->メンテナンス不可能な領域
- 自動化が向くテスト
- スモークテスト
- パフォーマンス
- API
- 向かないテスト
- 回帰テスト（賛否両論あり）
- 動画、グラフィックス、サウンド
- 戦略的なテスト自動化
- パフォーマンス、ロングランテスト
- ユニットテスト（高橋さんは開発者がやるべきことと認識）
- 統合テスト
- スモークテストの自動化
- スモークテストの自動化
- ウォーターフォールではスモークテストしない
- ライフサイクルモデルならデイリーでスモークテストする
- スモークで引っかかったらテストに耐えられないとみなす
- スモーク突破後に自動回帰テストはいい感じ・・・だけどナーバスな領域
自動化すべきか否か？成功させるにはセンスと経験が必要。初心者にはオススメしない - M社ではテスターがすぐにプロジェクトに入る・・・これは仕様変更による自動化コストの無駄が発生するリスクがある・・・が、かなり上手くやれば・・・どうか？ともかく難しいのは確か。
- データ指向自動化テスト（メインストリームになりつつある）
- 入力データの管理（別ファイルなどにして）
- 戦略的な自動化は今後必須になる
- ソフトウェアはデータ(Data)と振る舞い（Behavior)
- データのバグが殆どです（Nasaのロケットとか、携帯とか世間を騒がせた問題も）
- 単純な振る舞いのバグは自動化しなくても見つかる、だから、自動化ツールによる振る舞いの自動化に感動してちゃだめ！！
Seleniumを使ったテストでも気をつけなきゃいけない部分だな
- 単純な振る舞いのバグは自動化しなくても見つかる、だから、自動化ツールによる振る舞いの自動化に感動してちゃだめ！！
- データのバグが殆どです（Nasaのロケットとか、携帯とか世間を騒がせた問題も）
- ソフトウェアはデータハンドリングにこそ意味があり、そこにバグが潜む
- 状態遷移テスト
- 複雑度が増している
- GUIになっているし・・・
- 状態遷移は状態遷移図を書いた後、自動化する価値がある
- 回帰テスト（リグレッションテスト）
- 上手く自動化する手法はない。自動化には最深の注意が必要
- コーディング上の注意
- 自動化コードが増えちゃうとメンテコストが増えちゃう
- 組み合わせテスト、境界値分析をして使って入力データを減らす工夫が大事
- データファイルを必ず作る（メンテ向上）
- フロー変更が頻繁にある
- GUI自体のテストを自動化しないこと
- データをチェックポイントに使うこと（ボタンの文言とかを判定に利用しないこと）
- GUIテストツール（ツールそのものがGUIという意味）はサブルーチン化が難しいので・・・スタートアップ、終了処理は共通ルーチンを作成した方がいい
- まとめ
- 一般的なテスト手法を勉強すべし
- 自動化テストを勉強すべし（なんでも自動化とかありえない）
- 身の丈にあった自動化(50%のコスト減とか夢をみない。いっても20〜30%と心得ること）
- 自動化は【著しく】コストを下げたり、生産性を【著しく】向上するものではありません
主催セッション１ †
- .NET/Java向けのテスティングツール（DevPartner Studio 8.0）の紹介
- 静的ソースコード解析機能（ネスト数、変数命名規則、exec()利用とかのチェック）はパートナーさんによる成果物のチェックに使えるなぁ。というより使いたい。品質をコードレベルで積み上げていくことにも繋がるし。OSSで探すか、簡易なものを作るかしよう
- ソースコードの読みやすさの指標としてサイクロマティックメトリクスを利用とのこと
- ソースコードの読みやすさのメトリクスを自社用に何か定義できないだろうか？サイクロマティックメトリクスの勉強からやるか
- テスト網羅率（ガバレッジ）はクリティカル部分（全体の20%）だけを意識すれば充分だと思う。ただし、どの部分がクリティカルか、その箇所の網羅率を計測してあげるための工夫は必要だね。まずは、リスク分析か・・。
主催セッション２ †
- キャプチャー/リプレイ + データ指向テスティング機能といったツール(Test Partner 5.4J)の紹介
- キャプチャー/リプレイ型は再生タイムという縛りを受けるし、手作業が減るからといってバグがそれで見つかるわけでもなし、単に対外的に公開する網羅率を上げる役割ぐらいしか果たせないのでは？有効な利用シーンは限定される印象
- 紹介されたソフトウェアの印象は紹介者の人の顔や態度と共に思い出すんだなぁ
ユーザ事例セッション †
- 演目
- 「全ては品質確保のために！開発現場での品質積み上げとテスト自動化事例」
- 講演者
- 齊藤 裕之さん
(株)NEC情報システムズ ユビキタス事業部 ユビキタスソリューションG
- 元々はNECの中央研究所と連携していた研究開発部隊
- 最近は研究成果を製品化する要求が多くなり、品質に対する意識向上が必要になってきた
- 自動化のきりわけには工夫とノウハウが必要
- 自動化が検査フェーズにおいて果たす役割は品質向上ではなく劣化防止
- プロセス間通信ミドルのプロジェクトで検査用スタブを作成して自動化しようとしたが失敗。手作業の方がコスト的にメリットがあった。
- 無理に全ての単体検査を自動にする必要はない
- テストファーストの定着は難しい。特にスケジュールが遅延してくると・・・意識改革が必要。
- 品質意識の向上と導入したツールの効果測定のために、自動化したテストケース数やテストケース作成割合などを見積り、計測して公開している。うちも必要だよなぁ。
- 品質意識向上のために、コードレビュー記録をとって集計プログラムを作成して、結果をフロアに張り出している。開発者全員が品質情報を把握する。品質の「見える化」。
- コードレビューに含んでいる要素
- レビュー時間、人数、検出したバグ数、設計バグ／実装バグの種別判定
- オフショア利用している。コード受け入れ時に静的コード解析を活用
- 組み合わせ検査には自動化ツールは活用できると思う
- 自動化は工数削減より、品質リスクの低減とチームメンバの負担軽減により重要な効果がある
- ツールにはメンテコストが必ずかかるので、削減工数とメンテコストを比較して導入を検討するべき
- キャプチャー/リプレイ型ツールでは再生するマシンによって再生タイミングが異なり、エラーが生じてしまうことがある。オフショアで問題に
- 無理に再生タイミングを調整するより、同じ構成のマシンを送りつけた方が安上がりだったのでは？
- キャプチャー/リプレイ型ツールはまたファーストバージョン作成時には要準備
- 画面があることを前提としているから
- 通常の開発では、検査工程に遅延のしわ寄せがくることが多い・・・充分な検査時間が取れない場合が多い->検査工程で開発できるスクリプト数には少なめを覚悟する必要あり
- 充分な検査時間が確保できない問題にはどう対処すべきだろうか？仕様化や設計工程に割り込むか？どうやって？仕様や設計が変化した場合に生じるロスとの兼ね合いは？
- バグの収束曲線を見せられたが、計画値をどうやって出せばいいか？過去の計測が必要だと思うが、現状できてない。
- データドリブンでも、機能ドリブンでもない、用途ドリブンのテストは考えられないか？
- 検査工数とデバッグ工数をどうとらえるか？包括するか？検査によってバグが見つかればデバッグ工数は増え、デバッグすれば再検査の為に検査工数は増える。相互に増加関係にあり、かつ、明確なゴールラインはひけない。故にバーンダウンチャート化も難しいか？（新しいバグが見つかるたびにチャートが跳ね上がるとか？）
