😸
ソフトウェア評価 step2 テストにあたる前の心構え
どういった記事なのか
テストエンジニアとしてテスト設計・テスト実施管理等を行ってきた経験から、
ソフトウェア評価について記事をまとめていく予定
step2として、実際にテスト設計等を行う前の心構えをまとめている
どんな人間が書いているか
プログラマー歴10年ちょいの初心者
ITに関わった当初はテストエンジニア、その後プログラマー・SEに転身
C# -> php -> ruby とプログラム未経験から職場とともにメイン言語を渡り歩いてきた
テストにあたる前の心構え
ソフトウェア開発におけるバグの発生
- ソフトウェア開発において、バグは避けられない現象
-
「x行のコードを書くと1件のバグが含まれる」 という法則が存在する
- 具体的には、平均的に 10から100行のコードに1件のバグが含まれる とされる
- この統計はコードの品質や開発者の経験に依存するが、バグは小さなものから重大なものまで幅広く存在する
-
特に発生しやすいタイミング
- 要件定義の不備や曖昧さが原因となるバグ
- 新規機能の実装や大幅なコード改修時
- 外部システムとの連携や環境依存部分でのバグ
テスト設計の重要性
- テスト設計は、ソフトウェア開発の成功に不可欠なプロセス
- テスト設計の目的は、バグの早期発見と修正コストの削減にある
- バグが発見されるタイミングが早ければ早いほど、修正にかかるコストとリスクは低減する
-
バグ修正のコストの例
- 要件定義時に発見: 修正コスト1倍
- 開発中に発見: 修正コスト5倍
- 運用後に発見: 修正コスト10倍以上
- テスト設計は、これらのリスクを低減するための投資と考えるべき
心構え
-
バグを前提とした設計
- バグが発生することを前提に設計することで、テストの効果を最大限に引き出せる
- 実践例: ユーザーが想定外の操作を行う可能性を考慮し、異常値やエラー処理を含めたテストケースを設計
-
テスト実施者のスキルを問わない設計
- テスト手順を明確に簡潔に記載することで、誰がテストしたとしても同じ結果を確認できるようにする
-
ポイント
- テストシナリオには期待結果を明記
- 手順は箇条書きで簡潔に記載し、迷いをなくす
- 可能であれば、画面キャプチャや図を活用して視覚的に分かりやすくする
-
網羅的なテストケースの作成
- すべてのシナリオをカバーするテストケースを設計することが重要であり、特に境界値や異常値のテストは不可欠
- 補足: 完全な網羅はリソースの制約で難しい場合があるため、リスクの高い箇所を優先する
-
テスト自動化の検討
- 手動テストだけでは限界があるため、テスト自動化の導入で効率とカバレッジを向上させる
-
自動化するべきテスト例
- 繰り返し実施する回帰テスト
- 入力パターンが膨大な場合のテスト
- 負荷テストや性能テスト
-
品質を最優先に
- ソフトウェアの品質はユーザーの信頼と満足度に直結するため、品質を第一に考え、テストを軽視しない姿勢が求められる
-
継続的な改善を意識する
- 一度設計したテストケースも、プロジェクトの進行や要求の変更に合わせて見直す必要がある
-
実践例
- 開発中に発見されたバグをもとに、既存のテストケースを強化する
- 新規実装された機能に合わせて追加のテストケースを設計する
-
コミュニケーションを大切に
- 開発者、テスター、プロジェクトマネージャーとの間で密に連携をとることで、テストの抜け漏れや理解不足を防ぐ
-
ポイント
- バグ報告の際は再現手順と期待結果を具体的に記載
- チームでのレビューやフィードバックを積極的に取り入れる
具体的な取り組み事例
-
要件定義時にテストケースを検討
- 要件書作成の段階でテストの観点を含める
- ユースケース図を用いて網羅的なシナリオを作成
-
テスト駆動開発（TDD）の採用
- コードを書く前にテストケースを作成し、それを基準に開発を進める
- バグの入り込みを防ぎ、開発の方向性を明確にする効果がある
-
バグトラッキングシステムの導入
- JIRAやRedmineなどのツールを利用してバグを一元管理する
- バグの発生状況や進捗を可視化し、チーム全体で共有する
まとめ
- コードの量が増えるほどバグの可能性は高くなるため、初期の設計から品質管理を意識する必要がある
- バグはプロジェクトの進行を妨げる大きな要因だが、適切なテスト設計と実施でリスクを最小限に抑えられる
- バグの発生は避けられないが、テスト設計と実施を通じてユーザーに高品質な製品を提供することが可能となる
- 開発者としての責任を意識し、テストを通じてプロジェクトの成功に貢献する姿勢が求められる
Discussion