おばんです！！
中岫です。
『データ指向のソフトウェア品質マネジメント』ワークショップ
の運営＆参加してきたのでレポートしま～す。
まず、タイトル長いですね。
とりあえず、『デートWS(ワークショップ)』とでも略しておきますかぁw
----------------------------------------------------------------------
日 時：5/18(土) 13:00～17:40
会 場：札幌市北区民センター『児童室』
参加者：15名
アジェンダ
1.ガイダンス＆G内で自己紹介
～前座～
2.「意外とすぐ使えるメトリクスの紹介」
～本番～
3.「不具合の可視化による開発終盤の品質管理」の解説＆演習（2章2節）
4.「工数見積りの妥当性確認」の解説＆演習（4章1節）
5.メトリクス活用目的、測定方法の明確化（1章、6章）
----------------------------------------------------------------------
【ガイダンス】
今回のワークショップの趣旨説明とグループ分けした参加者同士の自己紹介。
いつもと色が違うワークのせいか、見知らぬ人が多し。
最近は、外の勉強会に行くと顔見知りが多かったので、新鮮。
マネージャ層が多いのか、自分よりも上の方が多かったです。
まずはメトリクスを取る上で肝のところを説明。
“「経営における上位の目的」に対して、「品質データ分析における直接的な目的」を関連づける”
これ意識しないと、なんでこんなの収集している？必要なの？となるので、すごく大事だなと思いました。
次に「３大基本メトリクス」の紹介。
「欠陥」、「工数」、「規模」
内容に差があれども、どんな組織において、収集されているデータ。
この３つで“プロセス系”のメトリクスはほぼ網羅可能とのこと。
複雑度等の“プロダクト系”のメトリクスは、言語依存な面が高いから基本的なメトリクスを定めるのが難しいとのこと。
なるほど、確かに“プロダクト系”と考えてみると汎用的なモノって難しいかも。
【意外と使えるメトリクス】
ということで、自分から次の3つを紹介させていただきました。
・ニコカレ
・バーンダウンチャート
・EVM
※それぞれの詳細はWebで
これらの3つを選んだ理由は、なんとなくマネージャ層が多そうなのでプロダクト管理系をチョイスしたつもり。
まずは「ニコカレ」から。
「ニコカレ」がメトリクス？
と思う方もいると思いますが、数値化することでメトリクスになっちゃいます。
各ニコマークをポイント化して折れ線グラフに表示。
個人の積み上げ、チームの平均、チームとしての積み上げを表示。
用途はというと、
・週単位でグラフを確認すると進捗に現れない部分が見えます
チーム全体で下がっているなど。
全体ポイントが低いときってだいたい品質がアレな感じです。
・節目の振り返りでタイムラインとして活用できます。
グラフにイベントを記録しておくとさらにOK。
あとシールよりもホワイトボードに顔を書いてもらうと喜怒哀楽が見えて良いですよ～。
バーンダウンとEVMについて。
この二つは元データは異なるのですが、用途は大きく変わらないかと。
ただ、開発者視点だと残作業がなくなって見えるバーンダウンが、
管理者視点だと完成物が積み上がるEVMが好まれる傾向。
EVMは最終コストと成果物の進捗の乖離が見えるのでコスト意識も芽生えるけど、
開発中に開発者に見せるとプレッシャになるのでご注意を。
バーンダウンとEVM、特にEVMの方は収集しづらいと思っているかもしれませんが、足を使うと簡単に取れます。
最初からシステムありきで、担当者にお任せすると失敗します。
なので、まずは足を使いましょう。
足を使うとは、
朝会をやっているなら朝会で、朝会などやってなかったら直接、担当者に確認。
気軽に毎日聞くだけで、データが取れます。
一日30分もかかりません。
手間はかけても時間をかけない
あと、ただ取れるだけだと意味がなく、アクションを起こしたり、効果を実感できるようにしないと定着しません。
そうすると、開発者も協力的になるので楽になります。
ということを話させていただきました。
【不具合の可視化による開発終盤の品質管理】
オープン-クローズチャートと不具合検出率を使ったワーク。
最初は、一見問題なさそうなグラフを出して、グラフの問題点、改善点を探すワーク。
その後、正したグラフを序盤、中盤、終盤という形で段階的に見ながら、初見と対応アクションを考えるワークへ。
オープン-クローズチャートなど不具合の状況を可視化するのは、
収集が用意で基本的なメトリクスだと思うのですが、なかなかアクションを起こせない…。
でも、実際にはいろいろできるということがわかるワークでした。
あと数値だけではなく内容も見極めた上でのアクションが必要。
“定量的に問題の兆候を検知し、定性的に問題の本質を見極めることが大事”
ということを話されていました。
【工数見積りの妥当性確認】
主に回帰分析の説明だったのですが、半分Excel教室化。
まあ、出し方を知ることも大事ですから、分析方法を身につけて、現場でやってみてください。
これ、使えるようになると分析の幅が広がりますので、大事な道具。
【メトリクスの活用目的】
今回はGQMをブレークダウンした感じのフレームワークを使ったワーク。
たしかに純粋にGQMやるよりとっつきやすい、と思いました。
それでも、周りを見ると実際にメトリクスを考えたことがない方は手が止まる様子。
でも、ここが大事なところ、現場でもやってみてくださいね～（と上から目線な自分）。
#このワークは時間が押していたため、駆け足に。
#これだけでも、時間をかけてワークをやりたい。
【感想】
参加者によって求めている内容に差はあれど、概ね楽しんでいらしたと思います。
また、メトリクスを使った事例に対して飢えている感じでしたが、
まあ、今回のワークを通して得た知識を実践して、今後事例発表してください！！と思います。
あと、「デート本」ですが、ワークを通して改めて良い本だと思いました。
#それにしても「デート本」って、資料に思いっきり明記して、自分で言ってたなぁw
では～
ちわ！！
またまたやりました。
書籍
『ソフトウェアテスト技法ドリル』
著：秋山 浩一
を使った勉強会。
開催日：5/14
内容：
本の要約解説しながら、参加者同士でディスカッション。
最後にアル課題を使ってワーク。
範囲：第２章
～線を意識する～
連続して変化するモノを意識する
「同値分割」と「境界値分析」についてさらりと説明。
ある果物の個数と単価を算出するシステムについて、ディスカッション。
①1個～4個：単価200円
②5個～9個：単価170円
③10個以上：単価160円
まずは、これに対して「同値分割」と「境界値分析」をやってみると、
こんな回答が出てきました。
有効値の境界の確認:1,4,5,9,10
無効値の確認：0
まあ、この値を選択するのがベターな気がします。
ここで参加者にこの問題をプログラミングした場合のロジックを考えてもらい、
それに対して先に出したケースでテストするとどうなるか？
をやってみる。
出てきたロジックはこんな感じ
------------------------------------------------
If( ( 1 <= n ) && ( 4 >= n ) )
{
price = 200;
}
else if ( ( 5 <= n ) && ( 9 >= n ) )
{
price = 190;
}
else if ( 10 <= n )
{
price = 160;
}
else
{
price = 0;
}
------------------------------------------------
とりあえず、問題なさそう。
仕様通りの振る舞いを確認できる様子。
みんな完璧だね！！
めでたし、めでたし～。
では、終わらせない。
これって、本当にバグが見つかりますか？
というツッコミをしみてる。
（参加者「？？？」）
もし、
“else if ( 10 <= n )”
が
“else if ( 10 == n )”
となっていたとします。
このコーディングミスをレビューで取り除けなかった場合、
先のテストケースで間違いを見つけれますか？
はい、見つかりません。
ここで、
Beizer（バイザー）の方法
と
Jorgensen（ジョーゲンセン）の方法
を紹介。
（詳しくは参考情報②を参照）
“10”の境界について、Jorgensenの方法で境界値を求めると
9,10,11の3通りが出てきます。
そうすると先の間違いを見つけることができますね。
めでたし、めでたし～。
でも終わらせない。
なんか、テストケースが増えちゃった気がしますね。
そして、いったいこのテストはいつやるの？
いまでしょ！！（違っ
システムテストのときにやる？
遅い気がしませんか？
誰がこのテストやるの？第三者でしょうか？
ロジックわからないですよね？
という感じで深ぼる。
すると単体テストで開発者が妥当かも？
という意見に落ち着く。
では、その逆に
システムテストで第三者がやるとしたら、どんなテストケース？
というのも確認。
単体テスト時に上記のようなテストケースを実行してたとすると、
システムが動くことを確認できれば良さそうなので、
無効値の0、有効値のいずれかぐらいで良いかも。
また、単体テストの実施状況が不明な場合などは、
システムテストでも境界値を細かく攻める必要がありそう。
※ただしこの場合はテスターが泣きます。
と結論になりました。
最後は第２章の内容を踏まえて、
今回もSESSAMEの組込みシステム教育教材
『話題沸騰ポット GOMA-1015型』
要求仕様書の温度表示に関する仕様を抜き出したものを課題として、
「同値分割」、「境界値分析」を実施。
出てきたテストケースを抜粋
サーミスタの範囲
-11、-10、-9、149、150、151
水の温度を考え
-1、0、1、99、100、101
表示の範囲を考え
マイナス表示含めて4桁まで確認出来ると良い
-1000、-999
四捨五入と有効桁
*.3、*.4、*.5、*.6 *は任意値
まとめ
・何のため
・どのタイミング
・誰が
・何を
を意識するのが大切。
あと、
最後にまとめてテストするのではなく、
段階的にテストすることが大事。
品質は積み上げですね～。
【参考情報】
①組込みシステム教育教材話題沸騰ポット
(http://www.sessame.jp/workinggroup/WorkingGroup2/POT_Specification.htm)
②JaSST’11四国「実践！同値分割と境界値分析とドメイン分析
(http://www.jasst.jp/archives/jasst11t/pdf/s2-1.pdf)
③仙台ソフトウェアテスト勉強会のブログ
同値分割・境界値分析の2値の選択と3値の選択
(http://ameblo.jp/sendai-test/entry-11417704966.html)
したっけ！！
またまたやりました。
書籍
『ソフトウェアテスト技法ドリル』
著：秋山 浩一
を使った勉強会。
開催日：5/14
内容：
本の要約解説しながら、参加者同士でディスカッション。
最後にアル課題を使ってワーク。
範囲：第２章
～線を意識する～
連続して変化するモノを意識する
「同値分割」と「境界値分析」についてさらりと説明。
ある果物の個数と単価を算出するシステムについて、ディスカッション。
①1個～4個：単価200円
②5個～9個：単価170円
③10個以上：単価160円
まずは、これに対して「同値分割」と「境界値分析」をやってみると、
こんな回答が出てきました。
有効値の境界の確認:1,4,5,9,10
無効値の確認：0
まあ、この値を選択するのがベターな気がします。
ここで参加者にこの問題をプログラミングした場合のロジックを考えてもらい、
それに対して先に出したケースでテストするとどうなるか？
をやってみる。
出てきたロジックはこんな感じ
------------------------------------------------
If( ( 1 <= n ) && ( 4 >= n ) )
{
price = 200;
}
else if ( ( 5 <= n ) && ( 9 >= n ) )
{
price = 190;
}
else if ( 10 <= n )
{
price = 160;
}
else
{
price = 0;
}
------------------------------------------------
とりあえず、問題なさそう。
仕様通りの振る舞いを確認できる様子。
みんな完璧だね！！
めでたし、めでたし～。
では、終わらせない。
これって、本当にバグが見つかりますか？
というツッコミをしみてる。
（参加者「？？？」）
もし、
“else if ( 10 <= n )”
が
“else if ( 10 == n )”
となっていたとします。
このコーディングミスをレビューで取り除けなかった場合、
先のテストケースで間違いを見つけれますか？
はい、見つかりません。
ここで、
Beizer（バイザー）の方法
と
Jorgensen（ジョーゲンセン）の方法
を紹介。
（詳しくは参考情報②を参照）
“10”の境界について、Jorgensenの方法で境界値を求めると
9,10,11の3通りが出てきます。
そうすると先の間違いを見つけることができますね。
めでたし、めでたし～。
でも終わらせない。
なんか、テストケースが増えちゃった気がしますね。
そして、いったいこのテストはいつやるの？
いまでしょ！！（違っ
システムテストのときにやる？
遅い気がしませんか？
誰がこのテストやるの？第三者でしょうか？
ロジックわからないですよね？
という感じで深ぼる。
すると単体テストで開発者が妥当かも？
という意見に落ち着く。
では、その逆に
システムテストで第三者がやるとしたら、どんなテストケース？
というのも確認。
単体テスト時に上記のようなテストケースを実行してたとすると、
システムが動くことを確認できれば良さそうなので、
無効値の0、有効値のいずれかぐらいで良いかも。
また、単体テストの実施状況が不明な場合などは、
システムテストでも境界値を細かく攻める必要がありそう。
※ただしこの場合はテスターが泣きます。
と結論になりました。
最後は第２章の内容を踏まえて、
今回もSESSAMEの組込みシステム教育教材
『話題沸騰ポット GOMA-1015型』
要求仕様書の温度表示に関する仕様を抜き出したものを課題として、
「同値分割」、「境界値分析」を実施。
出てきたテストケースを抜粋
サーミスタの範囲
-11、-10、-9、149、150、151
水の温度を考え
-1、0、1、99、100、101
表示の範囲を考え
マイナス表示含めて4桁まで確認出来ると良い
-1000、-999
四捨五入と有効桁
*.3、*.4、*.5、*.6 *は任意値
まとめ
・何のため
・どのタイミング
・誰が
・何を
を意識するのが大切。
あと、
最後にまとめてテストするのではなく、
段階的にテストすることが大事。
品質は積み上げですね～。
【参考情報】
①組込みシステム教育教材話題沸騰ポット
(http://www.sessame.jp/workinggroup/WorkingGroup2/POT_Specification.htm)
②JaSST’11四国「実践！同値分割と境界値分析とドメイン分析
(http://www.jasst.jp/archives/jasst11t/pdf/s2-1.pdf)
③仙台ソフトウェアテスト勉強会のブログ
同値分割・境界値分析の2値の選択と3値の選択
(http://ameblo.jp/sendai-test/entry-11417704966.html)
したっけ！！ちわ！！
勢いに任せて、
書籍
『ソフトウェアテスト技法ドリル』
著：秋山 浩一
を使った勉強会を始めました！！
開催日：4/24
内容：
各自で予習し、ディスカッションベースで読み進める。
とある課題を使ってみんなで実践。
範囲：第１章、第２章
～点に注意を向ける～
テストの基本な概念「網羅性」と「ピンポイント」があるよ、
というところから。
さらっと書いてますが、これ需要です。
網羅性
→何かを元に網羅する
ピンポイント
→狙い定めて（バグ）を撃つ
網羅性の、この「何か」がはっきりしないと「網羅した」と言えないため、
「網羅した」と言うことの難しさを（某テスト設計コンテストで）痛感しています(-｡-;
＃『網羅する』…そんな言葉は使う必要がねーんだ。『網羅した』なら使ってもいいッ！
『ピンポイントテスト』
三色ボールペン法を使ったピンポイントテストが書かれています。
そこで、この章の例題をホワイトボードに映しながら、例題の解説通り進めてみました。
<三色ボールペン法>
ボールペンの色に下記のような意味を割り当て、仕様書をチェックする方法
赤色：客観的に見て、最も重要な箇所
青色：客観的に見て、まぁ重要な箇所
緑色：主観的に見て、自分が怪しいと感じた箇所
ここで参加者から質問
＞「重要な箇所」とありますが、仕様書に書かれてることは全て重要なことでは？
＃確かにそうだ…
どんなことに対して「重要な箇所」ということを考える、
例えば、テストするために重要なのか、実装するために重要なのか、など。
見る視点によって、重要な箇所というのが変わってくるはず。
今回はテストの勉強会なので、「テストするために重要な箇所」は？
という視点で実施しました。
一通り、例題通りに三色ボールペンを実演したところ、こんな質問が。
＞「間、対称、類推、外側」の順番で考えることが重要とあるのは、どうして？
＃う～ん、いきなり外側から考えても問題なさそうな気もする。
具体的なデータを考えることで間が考えられる。
間を考えることで対称を考えることができ、
間や対称で考えた内容からさらに類推することができる。
＃ここまでは、書籍にも説明がある通り。
これらは内側を考えるような行為で、
先にに内側をしっかり考えた上で外側を考えることで抜け漏れがなくなる。
ピンポイントなんだけど、狙ったところをまんべんなく撃つ感じですよね。
というご意見があり。
＃納得。
『過去の経験を活かす』
「バグパターンの蓄積トレーニング」をメインでディスカッション。
バグ票をみると良い勉強になる。
とくに痛いバグほど教訓になるという話。
自動車免許証の取得の際に凄惨な事故映像を使って、
こんなことがあんなことにつながる、と印象付けていると思います。
そんな効果もあるかと。
＃いちおう補足しますが、
＃痛いバグ＝このバグのおかげで会社を辞めることになりました
＃とういう話ではないです(^_^;)
ここで
＞バグ票をみる行為は、対象の規模によって効果が違うのでは？
＞1年程度のプロジェクトでは厳しい。
＞全てのバグ報告を読んでいたらそれだけで時間がなくなる。
というご意見が。
効率を考えてバグ表を読むことが大事で、
例えば、重大バグだけに集中するとか、工夫が必要。
＃重大バグを選別するのが難しいなら、
＃痛いバグ自慢みたいなことやると効率良く勉強、シェアできる場合もあり
最後は
SESSAMEの組込みシステム教育教材
『話題沸騰ポット GOMA-1015型』要求仕様書の
沸騰機能の仕様を抜き出したものを課題として、三色ボールペンを実施。
全員でどんなものがあるかを出し合い共有。
この共有はホワイトボードでライブ感覚で三色ボールペンを実施。
＃思いの外いろいろ気づきを得れたので、よかったなぁ。
＃これ、ペアプロに近い感覚なのかなぁ。
※汚文字でスミマセン
出てきた指摘を一部抜粋
[pot-230-11]沸騰ボタンが100msec以上押されると
→(間)100msec未満の場合はどうなる？→連打
→(対称)押しっぱなしだとどうなる？
→(間)100msecの判断タイミングは？→ボタンを離したとき？
[pot-310]100℃まで加熱
→(間)100℃まで何分かかる？いつなるの→いまでしょ？
→(外側)100℃の水を沸騰させたらどうなる？
[pot-310-12]四捨五入して整数で表示
→(間)整数とは行っているが四捨五入される桁は？
意見など
・実際にやてみるとどの色を使うかが迷う
→色で悩むなら、色を気にせずチェックして、後から色分けでも良いのでは？
分類することが大事なのではなく、バグを見つけることが大事。
・「間、対称、類推、外側」がなかなか意識できない
→慣れが必要。まずは一通りチェックしてから、見直しながら考えても良いかも。
まとめ
・バグ票はすべて見ることが大事じゃない、絞ることも大事。（痛いバグ）
・「間、対称、類推、外側」の順番が大切。
・「この仕様書には仕様のバグがあるに違いない」と思って三色ボールペンを使って仕様書を読み込む。
→あの天才物理学者・湯○学の言葉を借りると
「信じることから始まるのが実装なら、
疑うことから始まるのがテスト」
したっけ！！
勢いに任せて、
書籍
『ソフトウェアテスト技法ドリル』
著：秋山 浩一
を使った勉強会を始めました！！
開催日：4/24
内容：
各自で予習し、ディスカッションベースで読み進める。
とある課題を使ってみんなで実践。
範囲：第１章
～点に注意を向ける～
テストの基本な概念「網羅性」と「ピンポイント」があるよ、
というところから。
さらっと書いてますが、これ需要です。
網羅性
→何かを元に網羅する
ピンポイント
→狙い定めて（バグ）を撃つ
網羅性の、この「何か」がはっきりしないと「網羅した」と言えないため、
「網羅した」と言うことの難しさを（某テスト設計コンテストで）痛感しています(-｡-;
＃『網羅する』…そんな言葉は使う必要がねーんだ。『網羅した』なら使ってもいいッ！
『ピンポイントテスト』
三色ボールペン法を使ったピンポイントテストが書かれています。
そこで、この章の例題をホワイトボードに映しながら、例題の解説通り進めてみました。
<三色ボールペン法>
ボールペンの色に下記のような意味を割り当て、仕様書をチェックする方法
赤色：客観的に見て、最も重要な箇所
青色：客観的に見て、まぁ重要な箇所
緑色：主観的に見て、自分が怪しいと感じた箇所
ここで参加者から質問
＞「重要な箇所」とありますが、仕様書に書かれてることは全て重要なことでは？
＃確かにそうだ…
どんなことに対して「重要な箇所」ということを考える、
例えば、テストするために重要なのか、実装するために重要なのか、など。
見る視点によって、重要な箇所というのが変わってくるはず。
今回はテストの勉強会なので、「テストするために重要な箇所」は？
という視点で実施しました。
一通り、例題通りに三色ボールペンを実演したところ、こんな質問が。
＞「間、対称、類推、外側」の順番で考えることが重要とあるのは、どうして？
＃う～ん、いきなり外側から考えても問題なさそうな気もする。
具体的なデータを考えることで間が考えられる。
間を考えることで対称を考えることができ、
間や対称で考えた内容からさらに類推することができる。
＃ここまでは、書籍にも説明がある通り。
これらは内側を考えるような行為で、
先にに内側をしっかり考えた上で外側を考えることで抜け漏れがなくなる。
ピンポイントなんだけど、狙ったところをまんべんなく撃つ感じですよね。
というご意見があり。
＃納得。
『過去の経験を活かす』
「バグパターンの蓄積トレーニング」をメインでディスカッション。
バグ票をみると良い勉強になる。
とくに痛いバグほど教訓になるという話。
自動車免許証の取得の際に凄惨な事故映像を使って、
こんなことがあんなことにつながる、と印象付けていると思います。
そんな効果もあるかと。
＃いちおう補足しますが、
＃痛いバグ＝このバグのおかげで会社を辞めることになりました
＃とういう話ではないです(^_^;)
ここで
＞バグ票をみる行為は、対象の規模によって効果が違うのでは？
＞1年程度のプロジェクトでは厳しい。
＞全てのバグ報告を読んでいたらそれだけで時間がなくなる。
というご意見が。
効率を考えてバグ表を読むことが大事で、
例えば、重大バグだけに集中するとか、工夫が必要。
＃重大バグを選別するのが難しいなら、
＃痛いバグ自慢みたいなことやると効率良く勉強、シェアできる場合もあり
最後は
SESSAMEの組込みシステム教育教材
『話題沸騰ポット GOMA-1015型』要求仕様書の
沸騰機能の仕様を抜き出したものを課題として、三色ボールペンを実施。
全員でどんなものがあるかを出し合い共有。
この共有はホワイトボードでライブ感覚で三色ボールペンを実施。
＃思いの外いろいろ気づきを得れたので、よかったなぁ。
＃これ、ペアプロに近い感覚なのかなぁ。
※汚文字でスミマセン
出てきた指摘を一部抜粋
[pot-230-11]沸騰ボタンが100msec以上押されると
→(間)100msec未満の場合はどうなる？→連打
→(対称)押しっぱなしだとどうなる？
→(間)100msecの判断タイミングは？→ボタンを離したとき？
[pot-310]100℃まで加熱
→(間)100℃まで何分かかる？いつなるの→いまでしょ？
→(外側)100℃の水を沸騰させたらどうなる？
[pot-310-12]四捨五入して整数で表示
→(間)整数とは行っているが四捨五入される桁は？
意見など
・実際にやてみるとどの色を使うかが迷う
→色で悩むなら、色を気にせずチェックして、後から色分けでも良いのでは？
分類することが大事なのではなく、バグを見つけることが大事。
・「間、対称、類推、外側」がなかなか意識できない
→慣れが必要。まずは一通りチェックしてから、見直しながら考えても良いかも。
まとめ
・バグ票はすべて見ることが大事じゃない、絞ることも大事。（痛いバグ）
・「間、対称、類推、外側」の順番が大切。
・「この仕様書には仕様のバグがあるに違いない」と思って三色ボールペンを使って仕様書を読み込む。
→あの天才物理学者・湯○学の言葉を借りると
「信じることから始まるのが実装なら、
疑うことから始まるのがテスト」
したっけ！！