エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
「ソフトウェアテスト」と「振り込め詐欺」の関係
「自分が想像できないバグは摘出できない」――バグの“想像力”とバグの“知識・経験”は、高品質なソフトウ... 「自分が想像できないバグは摘出できない」――バグの“想像力”とバグの“知識・経験”は、高品質なソフトウェア作りに欠かせない 前回のコラム「開発するのに30分、テストするのに10万年」では、7つの「基本的な出荷基準」を挙げ、「3.未実行コードがない」について解説しました。今回は、その続き、「4.エラー・ゲシング(Error Guessing)を実施した」を紹介します。 まずは、7つの基本的な出荷基準について再掲します。 全機能をテストした ブラックボックス/ホワイトボックス・テストで同値分割を実施した。 境界条件をテストした ブラックボックス/ホワイトボックス・テストの境界値分析を実施した。 未実行コードがない ホワイトボックス・テストのC0パス網羅を満足した。 エラー・ゲシング(Error Guessing)を実施した バグを想定し、それを摘出するためのテスト項目を設計・実施した。 長時間