見る読んで大事だと思った箇所を、業務SE視点で解釈する。テスト計画テストでも何でもそうだが、先ず始めに計画ありき。テスト計画書はIEEE829のテストテンプレートをカスタマイズする。計画に盛り込むリスクは下記の式で算出。リスク=問題の発生確率×発生した場合のダメージ典型的なリスク要因として、複雑度/新規性/大きな変更/上位依存性(未出荷の製品やコンポーネントに対する依存関係)がある。テスト実施やるべきテストは下記3つ。状態遷移(ただし、アーキテクチャ設計、デザインパターンの適用でバグを抑えられる)レビューテスト仕様書や結果のレビューが追いつかない場合、バグがありそうな箇所を重点的に攻める。「バグ曲線が寝た」→「出荷して問題ない」という論理は弱い。テストの終盤になってバグが増加するケースもあるので、その場合は下記の指標を取り入れる。画面系の自動化は止めた方がいい。メンテのコストが高すぎる。逆に、共通機能とかAPI的なものは自動化した方がいい。・探索的テストソフトウェアの理解+テスト設計+テスト実施を同時に行う手法。一個人の責任として、きちんと仕様を理解して、テスト設計し、テストし、バグ報告するスタイル。→当たり前のことすぎるが、実際のところ、これができない人が多すぎて困る。テスト仕様書は必ずしも必要ではない。下記のようなテストも取り入れる。重要機能に対してシンプルなテストを実施し、デグレしてないことを確認する→うまいこと計画に明記し、うまいことテスト内容とエビデンスを残さないと、実際のプロジェクトに取り入れるのは難しいと思う。常に読み込むバックグラウンドで実行した処理が全て完了するまで待つ月別アーカイブはてなブログをはじめよう!mokimokisanさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。