Udemy演習問題
雑多
50問くらいまではメモをとっていない
- チーム全体アプローチは常に有効というわけではない
- アジャイルでの作業成果物の文書化は、ウォーターフォールと比べると少なめ
- リグレッションテストとかの自動化の充実度を高める方向で補う
- イテレーティブ開発モデルがテストに与える影響：静的テストと動的テストの両方が全てのテストレベルで実行される
- テストごとの目的を意識した結果、テストフェーズ間で冗長なテストケースは減る。
- よくあるのは結合試験で単体試験みたいなテストが冗長だったりする
- 機能テストと非機能テスト
- 機能テストは要求された機能を正確に実行するか。フェーズ的にはどこでも実施する
- ホワイトボックステストの微妙によくわからん説明
- テストによって基本的な構造を受け入れ可能なレベルまでカバーする
- 欠陥の修正を確認するテストは確認テスト。
- メンテナンステスト
- 変更部分のテストと、変更してない部分のテスト
- 変更してない部分のテストがリグレッションテストのこと
- 変更のインパクト分析で持ってテスト範囲を決める
- 運用環境の更新とか意向でもやる。開発時のテストを一通りやる？
- ソフト廃棄時のデータ保管要件（普通ある）を満たすためにも実施が必要なケースがある
- 早期かつ頻繁なステークホルダーからのフィードバックの利点
- 【⭕️】開発チームの理解を深める
- 【❌】PJのコスト削減
-
欠陥やその修正当のコスト削減につながるはずだが、因果関係として少し遠いみたい
## 静的テスト・動的テスト
- 静的テストにはレビューも含まれる！
- コードリンターだけに着目しがち
- なので仕様書レビューも静的テストの一種
- 静的テストで確認しがち：
- 動的テストで確認しがち：
- パフォーマンス関係
- セキュリティ関係
- ユーザビリティ関係
- 静的テストの価値
- 【⭕️】SDLCの初期段階で欠陥を検出できる
- 【❌】PJ全体のコストは増加するが、早期に欠陥を検出できる
- 一般に、早期に欠陥を検出できる方がコストを抑えらえる
- 【⭕️】実行不可能な作業成果物にも適用できる
- 設計書とか
- 動的テストは逆に実行可能じゃないと適用できない
-
【⭕️】動的テストだと到達しにくいコードの欠陥を検出しやすい？
レビュープロセス
- レビュアー個々が意識すること
- 【⭕️】作業成果物の品質を精査する
- 【❌】レビュー工数と時間枠の定義
- レビュー（対面？）の時の役割
- レビュアー
- モデレータ
- 書記
- レビューリーダ
- 作成者
- マネージャ
- レビュー対象範囲を決める
- レビューには参加しなそう
- 形式的レビュー
- 非形式的レビュー
- 形式的なドキュメント（定義したプロセス）不要
- 文書化不要
- インスペクション
- 最も形式的
- メトリクスを収集して、プロセス改善に使う
- ウォークスルー
- 目的としてレビュアーの教育もある
-
作成者が主導する