JSTQB AL 牛研 インシデント管理～

おばんです！！
なかくきです。

今回はまずは前回の復習から開始。

前回は、
「牛＝テストマネジメント」
と修正したのですが、
どうやらマネジメントの領域が少し違っていた様子。

シラバスが示すテストプロセスは一つのプロダクトに適応しているのに対して
前回の考えたマネジメントの内容はそれよりももっと大きな概念。

例えば、企業が複数のプロダクトを持っている場合、
企業の持っている対するポリシーや戦略がこれにあたる。

そうではなく、シラバスのテストマネジメントドキュメントが示す範囲は
プロダクト内でのテストに対するマネジメントの考えで、少し異なっている。

これを踏まえて前回の図を生かしつつ修正。


という訳でテスト牛も修正する。
「牛＝テストマネジメント」→「牛＝テストプロセス」
＃元に戻った…



なんということでしょう！！
テストマネジメントプロセス（青枠）とテスト開発プロセス（赤枠）に
分離されてるではありませんか！！（上下が逆だけど）
＃こっちの方が“なじむ”かも。

あと、前回はマネジメントドキュメントにどんなことが書かれるだろうか？
を中心に考えたが、
それよりもドキュメントに書かれていることから、

・どのような活動を行うか？
・何をしたら良いか？
・なんでそれが必要なのか？

を考えることが大事と言う話になりました。
＃たしかにドキュメントばかり作成しても意味がない。


ここからが本日のメインの『インシデント管理』

「欠陥ライフサイクル」の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(水)


【おまけ】
本日のお菓子
菓子名：さっぽろ　とうきびガレット
内容：
　とうもろこしがたんまりはいって、
　とうもろこしを生かしつつ、甘すぎず、うまし！！
　食感もサクサク！！
評価：▼▼▼▼▼　※独断と偏見の評価です！！

JSTQB AL 研究会『牛研』～マネジメントとプロセス～

おばんです。
なかくきです。

まずは、Advanced Level（以下、AL）って？
というところからおさらい。

シラバスでは以下の3つのタスクを定義している。

・テストマネージャ
・テストアナリスト
・テクニカルテストアナリスト

AL試験のターゲットはテストマネージャのため、
牛研ではテストマネージャに焦点を当てる。

シラバスではテストマネージャの債務は以下のように定義している。
・対象システムに対する包括的なテストのゴールおよびテスト戦略を定義する。
・計画、スケジュールの立案とその追跡を行う。
・必要となる活動を体系化し説明する。
・タスクに適したリソースを選択、調達し、割り当てる。
・テストチームの選択、編成、指導を行う。
・テストチームのメンバー間、テストチームと他のチームのステークスホルダ（利害関係者）とのコミュニケーションを体系化する。
・妥当な状況判断をすると共に、適切な情報提供を行う。

今回の牛研は、メインとなりそうな2章のテストプロセスと3章のテストマネジメントを深堀。
進め方はシラバスの2章と3章のキーワードを拾いつつ、読み合わせ。
この読み合せで引っかかったのが「マネジメントドキュメント」

レベルテスト計画には何が書かれるんだ？
テスト計画ドキュメントテンプレートって？
テンプレートってレベルテスト計画用？
と、イメージができない点が多々。
とりあえず、これらを図示しながら、
意識わせしてみたところ次のようなイメージになった。

マネジメントドキュメントの概略イメージ



概要を図示が終わったところで、前回書いた肉マップに疑問。
テストプロセスの一環としてマネジメントがある、
という話で、

牛＝テストプロセス

としていたけど、

ポリシーや戦略はマネジメントで考える。
ポリシー、戦略があっての計画であり、プロセスが決まる。
こういうことになるのでは？

牛＝テストマネジメント

肉マップ自体も見直す。
計画がプロセス支えてない？という感じで計画は「前スネ」
プロセスはというと走り出す感じで「友スネ」
「ソフトウェアテストの基本的側面」はというと
見えないけど、噛めば噛むほど的な感じで「内蔵」

描き直すとこんな感じになった。



次回は、マネジメントドキュメントの概略イメージで出てきた、
インシデント管理あたりを深堀りしたいと思います。

したっけ！！

「USDM勉強会」に行ってきました

こんにちは　小楠です。

先日、AFFORDD主催の「USDM勉強会」に参加してきましたので、どんな感じだったのか簡単にレポートします！

12/8（金）。外は気温マイナス５度。前日から爆弾低気圧が暴れ、風と雪がひどくてとても寒い１日でした。講師は「要求を仕様化する技術・表現する技術（以下USDM本）」著者の清水吉男氏。

14時～20時まで講義と演習、間の休憩２回と結構ハードなタイムテーブルでしたが、USDM以外にも清水さんご自身の実体験や勉強の方法など、色々なジャンルのお話が入り交じり、とっても面白くて最後までニヤニヤ楽しく勉強できました。
＃1/3はUSDM以外の話だったんじゃなかろうか(^^; ・・・

私は4・5年ほど前に、どうやって仕様をまとめていけばいいのかわからず困っているところで、USDM本に出会いました。また、今年はTEF道のUSDM分科会にも参加して、少しはUSDMをかじっていたつもりだったんです。
でも、全然だめ。要求と仕様をちゃんと理解していなかったり、USDMがカバーする範囲を勘違いをしていたことを思い知らされました。最後の演習でも、うまく要求が表現できず。悔しい～（＞＜！

清水さん曰く、「要求は最初はうまく書けないものなので、ちゃんと表現できるようになるまでには訓練が必要。まずは書いてみて、１週間後に見るとよい。そこで何か気がつけば、成長している。」
もう一度FreecelのUSDMを書き直してみようかな。実はJaSST'12 北海道のWSで使ったUSDMは私が書いたのですが、今書けばもうちょっとうまく書ける・・・はず。

さて今回、いくつかの疑問を抱えて勉強会に望んだのですが、終わってみるとほとんどが解消されていました。スッキリ～。せっかくなので、以下で少し紹介しますね。
＃私の理解による解釈が入っているので間違っていれば指摘ください。

１.USDMで定義・表現する領域はどこか。

• 書籍ではUSDMがカバーする領域はシステム要求から下層と書いてある。


• これは、システム要求のなかのソフトウェア要求（ソフトウェアへの要求）を指す。

２.要件定義書とUSDMの関係は？

• 本来は、要件定義＝USDM（要求仕様書）。


• ただ、実際には要件定義で仕様まで落とせていない（仕様が書いてない）ことが多いので、USDMに要件定義が包含されるような状態がほとんど。

３：理由には何を書く？目的とは違うのか？

• 理由欄には、その振る舞いがソフトウェアに求められる理由を書く。Reason・背景。


• 目的は含めない方がいい。目的にはソフトウェアへの要求以外の、ユーザーの要望やビジネスの背景といったものが入ってくるので、範囲がぼやけてしまう。


• 理由＋要求で文章になることが多い。○○なので（理由）、△△したい（要求）。目的＋要求ではうまく文章が結べない（と思う）。

４.画面仕様。例えば入力桁の記述が画面で分散し、一覧性がなくて困るが？

• 必要であれば別表で補足すればいい。どんどん自分で工夫しろ。

５.ロジックなど、仕様欄に文章で表しづらいものがある。

• 図で書いてセルに張ればいい。自分で工夫しろ。


• 仕様は操作の流れを見せることが大事なので、細かいロジックは別参照にした方がいい。

６.ユーザーの要望を分析した要求と、USDMの要求は同じ？

• ちょっと違うようだ。


• 設計者やPGは、細かくしてから（一段下げてから）、要求を出そうとするからうまくいかない。何がしたいんだい？と（一段上げてから）、出てきたものがUSDMの要求になる。


• ただし、上がりすぎてユーザーの要望レベルになってもだめ。あくまでソフトウェア要求の範囲内で考えること。

少し、分かってきた気がします。試しにUSDMのセルフチェックリストを作ってみました～。
まだ粗々なので今後推敲していきたいと思います。

■USDMセルフチェックリスト
＜要求＞
□ソフトウェアへの要求になっているか。
□「振る舞い」を表しているか。
□「イベント」が特定されているか（どのタイミングで、何がどうなる）。
□「目的語」、「動詞」が入っているか。
□どこまでを作ればいいか、範囲を示しているか。
□例外処理、エラー処理が入っていないか。例外は無理に入れずに省略してもよい。
□動詞は多くて５個ぐらい。多ければそれらをまとめるような表現にして、その分、仕様グループを作って分ける。
□仕様になっていないか。具体的な数値が入っていればそれを別の言い方にする。2秒ー＞長押し
□動詞が一つなら細かすぎる。ある一連の操作の一つの処理しか表していなかったり、イベントが入ってないなら、細かすぎる。○○のときに○○して、○○する。ぐらいが最小。
□本当にその階層化は必要か。最初は階層なしで書いてみた方がいい。最初は細かくせず、まとめてみた方がいい。大きくなりすぎたら、細かくするぐらい。最初から階層を意識しようとすると難しい。
□保守性の要求は書いたか。
□実現可能性が見えるか。
□検証可能性が見えるか。
＜仕様＞
□グルーピングされているか。
□シナリオ・操作の流れになっているか。
□要求のなかに収まっているか。迷子なら、別の要求に入れるか、新しい要求を作る。
□誰が見ても同じ振る舞いをするソフトウェアが作れるところまで、書いてあるか。

最後に、わざわざ北海道までお越しいただいたAFFORDDの清水さん、梶本さん、そして勉強会をセッティングいただいた安達さん、本当にありがとうございました。とっても楽しかったです。多謝！

（小楠）