JaSST Tokyo 2014のISO29119セッションまとめ
-
- いいね！4
Yasuharu NISHI
@YasuharuNishi
汎用的なテストプロセス、リスクベースドテストアプローチの採用、組織的・プロジェクト・テスト実行の3層モデルが29119の特徴です。
2014-03-07 17:06:09
it’s me yoshi
@YoshiWoods
#jasst d4 29119 の annex には「従来方法」と「アジャイル」との両方に関して具体的な言及があるとか。どれくらい具体的なのかしらん。CMMI だとそれこそ「言及」くらいなのだけれど。
2014-03-07 17:10:55
it’s me yoshi
@YoshiWoods
#jasst d4 29119 の説明。組織プロセスや管理プロセスが入っていることが特徴であるかのようにも聞こえたけれど、15504 や CMM/CMMI、BAPO などを見た後では至極当たり前に思える。殆どの場合は組織的な業務でテストが行なわれるのだから。
2014-03-07 17:17:42
it’s me yoshi
@YoshiWoods
この説明なら納得します。 #jasst RT @YasuharuNishi: 汎用的なテストプロセス、リスクベースドテストアプローチの採用、組織的・プロジェクト・テスト実行の3層モデルが29119の特徴です。
2014-03-07 17:18:47
it’s me yoshi
@YoshiWoods
#jasst d4 29119-6 static testing の draft が上がったらしい。Review と static analysis が含まれる。
2014-03-07 17:21:16
it’s me yoshi
@YoshiWoods
ISO33063 ソフトウェアプロセス改善の規格だが、対象がソフトウェアの開発ではなくてスティング。というのもある。策定メンバには重なりがあり、全く別個に策定しているのではない、ようだ。 #jasst d4
2014-03-07 17:22:50
鈴木三紀夫
@mkoszk
組織的・プロジェクト・テスト実行の3層モデルを採用した理由は？ ポリシーと戦略は組織できめられているから。 組織に蓄積されるベストプラクティスがあるから。
2014-03-07 17:24:52
鈴木三紀夫
@mkoszk
日本の経営者はテストに興味を持っていません。組織的なテストプロセスは難しい。 アメリカを含めても組織的なポリシーを持っているところは多くない。数人以上の組織であれば、何らかの組織的な文書をもっているはず。例えば、何らかの基準やチェックリスト、テンプレートは持っているのではないか
2014-03-07 17:31:29
鈴木三紀夫
@mkoszk
日本の企業にこの規格を導入しようとした時、大変でしょうか？ 組織的プロセスは大きいプロセスに感じますが、アネックスを見れば分かるように、シンプルなものでも良さそうです。
2014-03-07 17:33:04
鈴木三紀夫
@mkoszk
この規格はリスクベースドテストを前提にしています。リスクベースドテストは二つの解釈があります。一つはある時点でテストを打ち切るためのもの。一つはテストに重みをつける。決して何かを打ち切るわけではない。この規格はどっちの立場？ 全てを網羅してテストする立場です。
2014-03-07 17:35:39
鈴木三紀夫
@mkoszk
このプロセスモデルはどこかの本にあるものを書き写したものではないですよね？！ 答え難い質問です。 本から持ってきたわけではありません。だからといって机上のものではなく、実際に使われているものです。
2014-03-07 17:39:19
鈴木三紀夫
@mkoszk
リスクベースドテストのリスクの扱いについて。 テストケースの優先度だけを示すリスク。そのテストケースを実施しなかった時のバグの致命度と発生確率で扱う。 もう一つは一般的なプロジェクトリスク。例えばメンバーが休むとか。 この規格はどっちのリスクを扱っている？ 両方扱っている
2014-03-07 17:43:03
鈴木三紀夫
@mkoszk
この考えは、日本の組織で使われているリスクベースドテストよりも、広い概念と言えそうです。 日本の組織では、プロジェクトマネージメントで扱っているリスクと密接に関係するということです。 日本と言われましたが、日本だけ話ではなく、アメリカでも同様です。
2014-03-07 17:45:20
森野嘉津也
@LascasM
ISO 29119でのリスクベースドテストでは、プロジェクトもリスクもテストプロセスに入れなくちゃいけないのかぁ まあ、当たり前と言えば当たり前か #jasst
2014-03-07 17:46:08
鈴木三紀夫
@mkoszk
日本におけるテストマネージャーやリーダーは、テストチームのリスクについては扱っていますが、プロジェクトのリスクについてはプロマネ任せになっているところが多いのではないか？ 導入は難しいのでは。 プロセスはマニュアルではなく、プロセスの導入にも度合いがある。
2014-03-07 17:49:53
it’s me yoshi
@YoshiWoods
#jasst d4 さて我田引水しよう。にしさん：「プロセスの導入はそれ自身が改善活動である。マニュアルを作って現場に押し付ければ済む訳ではない。」ちょっとこれをやってみて、その先に進みたくて、あるいは今度はこっちもやってみて、漸進的に取り入れるものだ。PLE もそうよ。
2014-03-07 17:51:45
it’s me yoshi
@YoshiWoods
@YoshiWoods PLE の導入障壁が高すぎる、という声をよく聞いた。理由の一つは第一世代 PLE が喧伝されすぎたというものだけど、別の理由として、移行プロセス例が整理されていなかったというのもある。移行の各ステップで意味のある状態であることが、例示されていなかった。
2014-03-07 17:53:36
鈴木三紀夫
@mkoszk
この規格はヘビーウェイトなものと勘違いされるくらい文書量が多い。なぜこんなに書いたの？ WFを前提にすると軽量プロジェクトが適用できない。それを避けるため。 英国で規格を作った経験から、本文を読まずサンプルを使う人たちが大半だから。 文書の量が多いほど価値がある国もある
2014-03-07 17:55:50