なかくきです。
今回はまずは前回の復習から開始。
前回は、
「牛＝テストマネジメント」
と修正したのですが、
どうやらマネジメントの領域が少し違っていた様子。
シラバスが示すテストプロセスは一つのプロダクトに適応しているのに対して
前回の考えたマネジメントの内容はそれよりももっと大きな概念。
例えば、企業が複数のプロダクトを持っている場合、
企業の持っている対するポリシーや戦略がこれにあたる。
そうではなく、シラバスのテストマネジメントドキュメントが示す範囲は
プロダクト内でのテストに対するマネジメントの考えで、少し異なっている。
これを踏まえて前回の図を生かしつつ修正。
という訳でテスト牛も修正する。
「牛＝テストマネジメント」→「牛＝テストプロセス」
＃元に戻った…
なんということでしょう！！
テストマネジメントプロセス（青枠）とテスト開発プロセス（赤枠）に
分離されてるではありませんか！！（上下が逆だけど）
＃こっちの方が“なじむ”かも。
あと、前回はマネジメントドキュメントにどんなことが書かれるだろうか？
を中心に考えたが、
それよりもドキュメントに書かれていることから、
・どのような活動を行うか？
・何をしたら良いか？
・なんでそれが必要なのか？
を考えることが大事と言う話になりました。
＃たしかにドキュメントばかり作成しても意味がない。
ここからが本日のメインの『インシデント管理』
「欠陥ライフサイクル」の4段階のステップが話の焦点に。
4段階のステップ
ステップ1：認知
ステップ2：調査
ステップ3：対処
ステップ4：処理
それぞれのステップに対して情報収集活動が伴う。
・記録
・分類
・影響の識別
一見同じ収集活動に見えるが、各ステップで対象が異なると考えられる。
特に影響の識別がわかりづらかったので、以下のように整理してみた。
「認知」の影響の識別
・どんな機能が使えないか？
・どんな不都合が生じるか？
「調査」の影響の識別
・どのような機能に修正が必要か？（あたりを付ける、予測）
・どんなバージョンに修正が必要か？（バグが混入しているバージョンの特定）
「対処」の影響の識別
・実際にどんな修正が必要か？
→バグの修正
「処理」の影響の識別
・実際に修正が必要なバージョンはどれか？
→同バグの収束
最後にここの章で、もし自分が問題を作るとしたら？
をちょっと考えてみた。
こんなのDo？
・インシデント情報を元にプロセスの改善を行う場合、
原因となるインシデントと対処の組み合わせとして適切なものを選べ。
・影響の識別について、いずれのStepの識別か？
【次回】
予定日：1/23（水）
アジェンダ：
・メイン
9.テストツールおよび自動化
10.スタッフのスキル-チーム構成
・サブ
1.ソフトウェアの基本的側面
8.標準およびテスト改善プロセス
したっけ！！
＃このペースで終わるのか？
～テストマネージャのための学習目的～
＿1.ソフトウェアの基本的側面：150分
済2.テストプロセス：120分
済3.テストのマネジメント：1120分
＿4.テスト技法：0分
＿5.ソフトウェア特性のテスト：0分
＿6.レビュー：120分
済7.インシデント管理：80分
＿8.標準およびテスト改善プロセス：120分
＿9.テストツールおよび自動化：90分
＿10.スタッフのスキル・チーム構成：240分
◆日程
済12/ 5(水)
済12/19(水)
済 1/ 9(水)
1/23(水)
2/ 6(水)
【おまけ】
本日のお菓子
菓子名：さっぽろ とうきびガレット
内容：
とうもろこしがたんまりはいって、
とうもろこしを生かしつつ、甘すぎず、うまし！！
食感もサクサク！！
評価：▼▼▼▼▼ ※独断と偏見の評価です！！
