→脆弱性関連
→CI/CD
→テストツール
サブトピック†
技術的負債／リファクタリング†
テスト手法†
- 結合テストと総合テスト
- ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます
- ファズ・テスト
- 入力データの一部をランダムに書き換え、どのようなエラーが起きるかチェックする技法
E2E(End to End)テスト†
→スクレイピング
→テストツール
カオスエンジニアリング†
カバレッジ†
- テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について 2018.3
- 『カバレッジが高ければ、品質が高い』は誤った論理であり、正しくは 『「カバレッジが高い」かつ「テストケースの品質が高い」ならば、「コードの品質が高い」』 である。
- いくらカバレッジが高くても、 テストケースの品質が悪ければ、バグが潜在している可能性を低くすることはできない。
- カバレッジを100%に近づければ近づけるほど、バグ検出の費用対効果は低下する。
- クリティカルなコードではない限り、カバレッジ（C0 / C1）の目標値は 85%程度 に設定すべきである。
- NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ 2008
- カバレッジは、参考程度に見るのはいいけど、数値目標を立てて管理に使い始めると弊害が増える。
- 問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。
- ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。
品質管理一般†
- エンジニアなら知っておきたい障害報告&再発防止策の考え方 2018
- 障害報告は始末書や反省文ではない
- 「起きた現象」の内容ではなくて、「原因やバグが発生しているモジュール名」などを書いてしまいがち
- 3段階くらいに再発防止策を検討
- 直接原因 ： その不具合が発生した直接的原因
- 間接原因 ： その不具合に至るまでの間接的な原因
- 本当の理由： なぜ、このようなパターンの障害が発生したか
コードレビュー／リーダブルコード†
→コーディング規約については言語・開発環境へ
→コード解析についてはソース解析／オープンソースへ
- ソフトウェアレビューが成功する進行役の6条件 2010.4.14
- レビューアがエラー発見に集中できているか
- レビューアがエラー発見の手掛かりを得られているか
- 遠慮して発言していないレビューアがいないか
- 適切なエラー指摘がなされているか
- 進行のペース（時間配分）は適切か
- 作成者は指摘を受け入れているか
静的解析/コードメトリック/コードメトリクス†
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
