テストエンジニアにはビジネスセンスも必要。「テスト網羅率100%です」などといった頭の悪いこと言わないようにしようコスト削減したいなら、自動化より先に作業の無駄を減らすこと無駄なテストケースを減らす、開発スタイルの無駄を減らす無駄なテストケースを自動化すると全てごみ化しますよ最近のソフトウェアは組み込みだったらソースは100万行超える。自動化すべきか否か?成功させるにはセンスと経験が必要。初心者にはオススメしないM社ではテスターがすぐにプロジェクトに入る・・・これは仕様変更による自動化コストの無駄が発生するリスクがある・・・が、かなり上手くやれば・・・どうか?ともかく難しいのは確か。状態遷移は状態遷移図を書いた後、自動化する価値がある回帰テスト(リグレッションテスト)上手く自動化する手法はない。自動化コードが増えちゃうとメンテコストが増えちゃう組み合わせテスト、境界値分析をして使って入力データを減らす工夫が大事データファイルを必ず作る(メンテ向上)フロー変更が頻繁にあるGUI自体のテストを自動化しないことデータをチェックポイントに使うこと(ボタンの文言とかを判定に利用しないこと)GUIテストツール(ツールそのものがGUIという意味)はサブルーチン化が難しいので・・・スタートアップ、終了処理は共通ルーチンを作成した方がいいまとめ一般的なテスト手法を勉強すべし自動化テストを勉強すべし(なんでも自動化とかありえない)身の丈にあった自動化(50%のコスト減とか夢をみない。exec()利用とかのチェック)はパートナーさんによる成果物のチェックに使えるなぁ。品質をコードレベルで積み上げていくことにも繋がるし。OSSで探すか、簡易なものを作るかしようソースコードの読みやすさの指標としてサイクロマティックメトリクスを利用とのことソースコードの読みやすさのメトリクスを自社用に何か定義できないだろうか?サイクロマティックメトリクスの勉強からやるかテスト網羅率(カバレッジ)はクリティカル部分(全体の20%)だけを意識すれば充分だと思う。どの部分がクリティカルか、その箇所の網羅率を計測してあげるための工夫は必要だね。自動化が検査フェーズにおいて果たす役割は品質向上ではなく劣化防止プロセス間通信ミドルのプロジェクトで検査用スタブを作成して自動化しようとしたが失敗。手作業の方がコスト的にメリットがあった。無理に全ての単体検査を自動にする必要はないテストファーストの定着は難しい。スケジュールが遅延してくると・・・意識改革が必要。品質意識の向上と導入したツールの効果測定のために、自動化したテストケース数やテストケース作成割合などを見積り、計測して公開している。品質意識向上のために、コードレビュー記録をとって集計プログラムを作成して、結果をフロアに張り出している。開発者全員が品質情報を把握する。したバグ数、設計バグ/実装バグの種別判定オフショア利用している。組み合わせ検査には自動化ツールは活用できると思う自動化は工数削減より、品質リスクの低減とチームメンバの負担軽減により重要な効果があるツールにはメンテコストが必ずかかるので、削減工数とメンテコストを比較して導入を検討するべきキャプチャー/リプレイ型ツールでは再生するマシンによって再生タイミングが異なり、エラーが生じてしまうことがある。画面があることを前提としているから通常の開発では、検査工程に遅延のしわ寄せがくることが多い・・・充分な検査時間が取れない場合が多い->検査工程で開発できるスクリプト数には少なめを覚悟する必要あり充分な検査時間が確保できない問題にはどう対処すべきだろうか?仕様化や設計工程に割り込むか?どうやって?仕様や設計が変化した場合に生じるロスとの兼ね合いは?バグの収束曲線を見せられたが、計画値をどうやって出せばいいか?過去の計測が必要だと思うが、現状できてない。データドリブンでも、機能ドリブンでもない、用途ドリブンのテストは考えられないか?検査工数とデバッグ工数をどうとらえるか?包括するか?検査によってバグが見つかればデバッグ工数は増え、デバッグすれば再検査の為に検査工数は増える。相互に増加関係にあり、かつ、明確なゴールラインはひけない。3.7.7をリリースしました。