第8回SQuBOKユーザ会勉強会にトーカーとして参加します。

バグ票コミュニティ(「バグ票ワーストプラクティス検討プロジェクト」)として、
第8回SQuBOKユーザ会勉強会に参加します。
当日は、今までアンケートでいただいた事例紹介を中心に
コミュニティの紹介や今後の活動などについてお話したいと思います。
コミュニティのアウトプットとしては、まだまだかと思いますが、
みなさまのご意見を伺えればと思います。

広告

【読書メモ】 Androidアプリテスト技法

2013年2月に秀和システムから発売された本です。
主に、Androidテスト部の方々が執筆されています。


この本は3章構成になっています。

  1. Androidテスト基礎
  2. Androidテスト実践
  3. Androidテストtips

ちなみに、3章のAndroidアプリのテストの部分についてはまだ読んでいません(^^;
しかし、第1章および第2章は、Androidに限らず、ソフトウェアテストに関わるすべての読むべきだと思いました。

1章の「Androidテスト基礎」ではテストの重要性や必要性をJSTQBシラバスなどをもとにしてテストプロセスやテストレベルなどを説明しています。
2章ではテスト分析やテスト設計を説明しており、テスト分析では、どのような品質要素をテストに盛り込むのかという考え方や
テスト技法をどのように適用するか、非機能テスト、ユーザビリティテストやUXのテスト、セキュリティテストは
どのように考えるかといったことが説明されています。
Androidを事例にはしていますが、他のソフトウェアプロダクトにも十分同じ事がいえると思いました。

テスト分析のやり方は、いろいろあるかとは思いますが、本書を例は敷居が低く、たいていのプロダクトにも使えるやり方なので
テスト分析を意識したことない方などは真似してやってみるにやってみる価値があるかなぁ、と思いました。

【JaSST13Tokyoメモ】 「過失に着目した欠陥のモデリング~バグ分析はなぜうまく行かないのか?~」

だいぶ遅くなってしまい、かなり時期を外した感がありますが、
2013年1月30日~31日に行われたJaSST13Tokyoのセッションに参加した際のメモをまとめてみました。

当日の講演資料は以下のサイトで公開しているようです。
http://jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf

不具合分析

不具合分析は多くの組織で行なわれているが、効果が出ていないのではないか。 近年、ソフトウェア開発は大規模化、複雑化している。

  • 一人ですべてを把握できない
  • 全て範囲をテストできない
  • 複雑度の増加
  • 組み合わせ数の爆発

そういった中で、バグとどのように立ち向かう、または扱っていく必要があるか。

「ワナ」

「ワナ」にはまることを繰り返さないようにするために、モデル化が必要

  • 「開発者が埋め込んでしまう「ワナ」→開発プロセスで何があったのか?
  • 品質担当者が見逃してしまう「ワナ」→テスト工程で何があったのか?

なぜ不具合分析がうまくいかない理由

バグ分析の失敗要因

  • バグ分析の目的が明確でない
  • バグ票に必要な情報がない
  • 事実認識が甘すぎる
  • なぜなぜ分析で論理の飛躍がある
  • 失敗事例が共有されていない

なぜなぜ分析がなぜ失敗するのか?

  • 分析することにどんな意味があるか理解していない。 (なぜ、なぜなぜ分析はなぜ5回なのか?4回や6回でない理由は?)
  • なぜなぜ分析結果を受け取る人の喜びそうな分析結果にしてしまう

なぜなぜ分析ではなく、なになに分析を行なう。

  • 「なぜなぜ分析」と「なになに分析」の違い
    •  なぜなぜ分析:人の責任と現象を同時に追求
    •  なになに分析:人と現象を分離させている
  • 「なになに」は、現象そのものに好奇心があることの強調する

バグの話をしていると暗い雰囲気になる

  • 暗くなるように分析している限り良い方向にはならない
  • ニュアンスが大きい

バグは資産

バグは、組織にとって資産である。

  • 同じバグは、他のプロジェクトなどで再現できない
  • バグは、保存し、共有し、語りつぐべき資産である
  • ワクワクして獲得するものである

アンチパターン

分析におけるアンチパターン

  • 現象と原因がごっちゃになっている
  • 「うっかり」、「きちんとできない」 etc その時何があったか、を分析していない
  • 決め付け、犯人探しになっている 他人ごとだったり、根本解決にならない
  • 「設計の問題」 設計でどんな問題が起きているか踏み込んで考える必要がある
  • テスト漏れ 何がどう漏れたのか? テスト網羅はどんな状態であったのか?

対策におけるアンチパターン

  • チェックリストに項目追加
  • 全体会議で周知する 継続した周知は無理。異動してきた人や新人の対応はどうするのか?
  • 教育や研修 誰に対して、どのような教育をすべきなのかを考える必要がある。
  • 文化の醸成、属人性の排除、適した人をメンバに追加 そもそも、コントロールできるか?

QA部門について

QAが指摘できる内容は少ない。指摘のレベルも深刻なものは多くない。

  • 品質技術が高いとはどういうことか?
  • どのようなQAならリスペクトされるのか?

QA部門が上のことを考える必要がある。 技術のウデとしてどうるべきか

対策編

どのようなバグを減らしたいのか。 →バグ分析の目的の共有、合意、優先順位付け 事実をヒアリングでとらえる 原因追求は、なぜなぜ分析 対策は、なになに分析 自責と他責は分けて考え、多くの仮説を作る 視点を変えていく →バグによってかえる バグの水平展開(同僚や製品グループへ) →必ずしも全社単位でなくても良い なぜなぜ分析 →なぜの間の「線の意味」を考える 「なぜ」でないことがある 本来、「原因→結果」となるが、「なぜ」でないとループしてしまう うまくできていないところはループする →「結果→原因」になっていないから 「欠陥がどいう経緯で作られたか?」を考える。

  • 思考の過程に「過失」があった
  • ソフトの欠陥は、必ず人間の副産物
  • 「人間がどう思考をミスったか?」「バグが入り込む余地があったか?」
  • 欠陥とバグ(過失)をセットで。

ソフトウェアの故障モード

  • バグの入りやすさ、誤りの入りやすさ

「だれでも間違える」という認識が重要

  • 「優れたエンジニアでも吸い込まれるようにまちがえてしまうのはなぜか?」を考える
  • 「不具合はだれでも起きた」ということを合意する。 どんなに気をつけていてもミスしてしまうような ワナがある。
  • そのワナを明らかにする ために「なになに分析」を行なう。
  • 間違えた人を、「ワナのありかを提供してくれるありがたい人」として扱えるようにする必要がある。
  • 全員がワナに共感することが必要
  • だれでも間違えるところを一緒に探しに行こう、という姿勢が大事。
  • 個人による誤りではなく、人間一般のあやまりをさあす。
  • 欠陥は過失 →誰々の過失、ではない。 →そこにいる人全員が共感してあたかう必要がある
  • ワナを公開しないと対策にならない
  • バグを前提とした社会 →バグが有ることを受け入れない
  • 憎むべきは「誤った人」ではなく、「バグそのもの」
  • バグが生まれる経緯の過失を公開する →落とし穴にはまらないようにする
  • バグの種類と、どう誤るのかをセットで覚える パターンとして自分たちに蓄積していく バグそのものをシェアする。
  • どのように吸い込まれるかを覚える

欠陥モデル

欠陥モデルは、欠陥知識の移転と理解が早くなる。モデル(絵)でバグの状態を伝える →欠陥知識を伝えることが難しくなっているところをわかりやすく伝える。

  • 誘発因子(ワナ)
  • 過失因子(引っかかる人間の要素)
  • 増幅因子(拡大した理由)
  • 欠陥
  • 表出現象

誘発因子をレビューやテストで引っ掛ける努力をする

過失因子で共感しやすくする

抽象度をあげると多くの範囲で伝えられる
→自分たちで抽象度をきめて移転の範囲をきめる

ご参考

プロジェクトファーブル http://aster.or.jp/business.html#fabre

原さんの「なになに」はもう一度お聞きしたい・・・(ぼそ

第6回SQuBOKユーザ会勉強会に参加してきました。

2013年2月14日に、第6回SQuBOKユーザ会勉強会が開催されました。

http://kokucheese.com/event/index/55470/

ご参考:SQuBOKユーザ会については以下のサイトを参照すると良いと思います。
SQuBOKユーザ会ポータルページ  Facebookファンページ

今回は、小池さんと堀さんのお二人がトーカーとして発表なさいました。
参加のメモ書きを兼ねて内容を簡単に書いてみます。

小池さん:「品質保証活動(SQA)を形骸化させないコツ」

プロセスが形骸化する理由

  • 「ルールで決められているから」「規準に書かれているから」とルールを強いる。

プロセスはルールではなく、道具である。「決められているから実施する」のではない。
プロセスは、
プロジェクトの失敗の予防に役立つから使う。そして使う以上はうまく使えるようにする。

  • 「開発がxxxx(プロセスなど)をしてくれなくて困る」と言ってしまう。

「データを提出する」「資料を作成する」するという作業は、プロジェクトに恩恵をもたらさないと認識する。

  • 「手順書や帳票を使ってくれない」

手順や、帳票を、現場に使ってもらえる努力をどれくらいしているか。
スタッフはサービスは精神が命であり、悪い点使いにくい点があれば、どんどん直していくこと

  • 適切なマネジメントのうえで,はじめてSQAが生きる
    目標はQCD達成だけでなく、チャレンジも盛り込むようにする。チャレンジ項目に対する評価を行なう。
    改善に対する評価がなければ、改善に対するやる気があらず、目の前の仕事しかしなくなる。
  • 「プロセス」「スタッフ」「マネジメント」のあり方の問題
    ロジェクト成功のためのサポートになるようにする。プロジェクトの成功に寄与しないと判断したならやめる。
  • 形骸化になる理由
    「開発者が、その活動がプロジェクトの成功に寄与しない」、と考えているから。
    →スタッフは貢献できているか自問自答しながら活動する必要がある。
    中長期的な組織の成長があっても、まず目の前のプロジェクトの成功させることをしないとだめ。
    悪いところだけを指摘するのではなく、いろいろな相談に乗ったり、改善案を検討したりすることが重要。

まとめ

プロセス改善に魂込めるには以下の様なことが必要である。

  • プロセスやルール、帳票などを使ってもらう努力を行なうこと。
  • 淘汰されたものは潔く諦める
    必要と判断して、残したものはまめにメンテナンスを行なう。
  • パイロットプロジェクトで試行する。
  • 常にプロジェクトの成功を考える
  • 客観的な姿勢でのぞむ

議論内容

  • メトリクスで人を評価してはいけない。人を評価するようになると正直なデータが出てこなくなる。
    人ではなく、プロジェクトという単位でみるようにする。
    人ではばらつくことがおおいが、プロジェクトという単位なら相殺されてぶれが大きくなくなるときがある。
  • 「プロセスを守りなさい」だけで縛ってはいけない。
  • プロセスの目的を考え、目的と合致しているかどうかを考えること。
  • プロセスは状況に応じて変化させていくこと。
    プロセスの標準化は、改善のためのベースラインを決めることである。決めたところからどう変えるかを考える。
  • SQAは、上位マネージャなどが判断するための情報を情報を提供するようにする。

堀さん:「ソフトウェアメトリクスの単位」

なぜメトリクスか

何かを定量的にあらわそうとすると、そのモノの本質をよく考える必要に迫られる
「神棚計画」のように、一度作成された計画の見直しがされないのはダメ。
「見積もり」→「実施」→「分析」→「見直し」といったようなサイクルを回すのが重要。

書籍「<はかる>科学」

書籍の紹介:「<はかる>科学」

http://www.amazon.co.jp/gp/product/4121019180

いろいろな「はかる」について書かれた本。
現代ではかることが難しいものに、どう向き合っているのかがわかったりしておもしろい。

本からの紹介例:
18世紀フランスで使われているいろいろな単位は群毎に異なっていた
→いまのソフトウェア開発で用いられている様々な尺度も同じような状況ではないか。

ソフトウェア開発における「はかる」

  •  step/人月
    • そもそも、コード書かなくて作成できるアプリケーションには、SLOCが登場しない
    • 保守性や移植性などを考慮されたプログラムはどうか
      よく考えられたプログラムが生産性が悪くて、コピペだらけで作成されたソフトウェアのほうが生産性がよいという評価は適切か?
    • 短時間でたくさんコーディングすれば生産性が高いのか?
    • そもそも人月って意味があるのか?
    • なぜSLOCか。

再利用しやかった。またそれしか有用な指標がなかった。新たな指標が望まれる。
Capers Jones:「SLOCではかることはゴムのように伸び縮みするものさしではかるようなもの」

  •  テスト項目数/step
    • 1件はどうカウントする?
      • Excelで書かれたテスト手順の1行が1件か?
      • マトリクスのテスト手順書はどうカウント?
    • 1つのテスト項目に複数の確認項目がある場合はどうする?

ここでは、「step/人月」「テスト項目数/step」をあげたが、他にもいろいろ似たような曖昧な指標があるはず。

単位を厳密に定義するのではなく、首尾一貫していることが大切。
→厳密に定義しないと、定義できないのではないか?

ワーキンググループの提案

ソフトウェアの様々な規模尺度や生産性を活用方法、定義、表し方、収集方法について検討するWGを立ち上げようと思っている。
期間は1年。成果はSQuBOKユーザ会やSQiPシンポジウムで発表したい。
・定性的情報/定量的情報の両方が必要
・定性的情報を、定量的には把握し、確認、裏付けをする
・定量液な情報から、定性的な情報を引き出す

議論内容

  • 因果関係をみながら対処することが重要
    レビューでよばれたとき、つくってきたもののモデルのつじつまがあっているのか?をみた。
  • モデルの厳密性や妥当性を示す、メトリクスはないか?もとのモデルが正しいか知りたい。
  • プロジェクトのわるいところは、数値を見なくても、プロジェクトを直接みることでだいたいわかる
    数値は、追認するときにつかう。
  • メトリクスの妥当性の範囲はわかりにくい。
    なので、異常値に着目することが多い。
    特性(くせ)をさっぴいて、極端に変な値になっていないか?
    →そこで悪いような値はかなりわるいケース
  • メトリクスは、「なににつかうの?」からはじめる必要がある。
    先にメトリクスありきで活用方法を考える、はおそらくうまくいかない。

次回予定

2013年3月21日(木)ということですので、ご興味ある方は、参加検討されてはいかがでしょうか。
トーカー(発表者)は募集中のようです。

ご参考

第6回SQuBOKユーザー会勉強会つぃーとまとめ
http://togetter.com/li/456060

(2/3(日)) コミティア103に参加します。

2/3(日) に東京ビックサイトで開催されるコミティア103に参加します。(ただし、知り合いのサークルのお手伝い・・・)
このイベントでは、今までの活動内容のまとめ、森さまより寄稿頂きました「ODC分析(直交欠陥分類法)」についてまとめた冊子(「バグ票について考えよう!」)を頒布いたします。

バグ票本表紙表紙です^^;

※今回は印刷所に依頼しました。以前頒布しました内容とほぼ同様の内容となっております。ご注意ください。冊子の概要についてはこちらの 2012年8月の活動の辺りをご覧ください。

もしかしたら、先着20名分くらい特典グッズを付けられるかも・・・しれません。

イベント当日は、以下のスペースでご来場をお待ちしておりますm(__)m

2/3(日) 東京ビックサイト 11:00~16:00
東5ホール な21b サークル:品質公団

品質公団では、既刊の本を頒布するようです。内容詳細については品質公団公式ページをご参照ください。よろしくお願いいたします。

 

(1/30~31)JaSST’13 Tokyoに参加します。

1/30(水)~31(木)に目黒雅叙園にてJaSST’13 Tokyo が開催されます。 詳細は以下のサイトを参照してください。

開催概要 http://jasst.jp/symposium/jasst13tokyo.html

セッション概要 http://jasst.jp/symposium/jasst13tokyo/details.html

個人としては聴講だけですが、私が関わっているバグ票コミュニティ(バグ票ワーストプラクティス検討プロジェクト)がLT(Lightning Talks)で発表します。今までの活動内容や今後の方針などについて発表いたします。 LTの概要等はこちらを御覧ください。

興味ある方その他の多くの方々のご来場をお待ちしております。

※来年は発表者側で参加したいなぁ・・・(ボソッ

 

2013/1/29 08:30追記

1/31(2日め)は、当日券の発売があるようです。急に予定が変わり時間があいた方などは是非♪
http://jasst.jp/symposium/jasst13tokyo/query.html#charge

「(ソフトウェア品質技術者のための)データ分析勉強会第7回目」に参加してきました。

【2013/1/31 13:30 小池さまより内容についてのご指摘があり、一部の内容を修正いたしました。】

1/18に東洋大学で行われた「(ソフトウェア品質技術者のための)データ分析勉強会第7回目」に参加しました。

今回のテーマは「プロダクトメトリクス」でした。プロダクトメトリクスとは、勉強会概要のページにも書かれていますが、「レビューやテストといったプロセスではなく、製品の特性を測定するメトリクス」です。この「プロダクトメトリクス」をRなど統計解析ツールを利用して分析することを行なうのが今回の勉強会でした。( すずき註:Rについては以下を参照するとよいかもしれません→ 「実践!Rで学ぶ統計解析の基礎」)

この勉強会では「データ指向のソフトウェア品質マネジメント」(通称:「デート本」 以下「デート本」と表記)をベースにして行われました。

測定する対象

まずは講義パートです。

デート本「6.3 規模の測定」を参照しながら、「何を測るべきか?」についてお話しました。LOCの場合、コメント文は対象に入れるのか外すのか?C言語の場合、includeファイルのカウントはどこでカウントするのか?などといったお話がありました。

プロダクトメトリクス

デート本「4.3 欠陥修正が生じやすいモジュールの予測」を参照しながら、以下のようなメトリクスの意味などを確認していきました。

  • TMLOC(Total Method Libe of Code:総メソッド行数)
  • WMC(Weight Methods per Class:重み付きメソッド数)
  • CBO(Coupling Between Object Classes:結合度)
  • LCOM(Lack of Cohesion in Methods:凝集度の欠如)
  • RFC(Response For a Class:応答処理の多さ)
  • Modify(修正の有無)

また以下のサイトを参考にして、凝集度や結合度について確認しました。

凝集度と結合度
http://homepage3.nifty.com/koha_hp/KeyWords/KW.Coupling.html

複雑さのメトリクスという意味では、以下のサイトも参考になります。
http://se.naist.jp/lecture/se3/2006/handouts/productmetrics2.pdf

ツール

さて、実際にプロダクトメトリクスを視るときに、ソースコードを逐一手で計算することはありえなません。というわけで、測定ツールをつかうことになります。ここでいくつかのツールの説明をしました。

  • QAC
    ソースコードの静的解析ツールです。ライセンス料金が少し高いです。
  • Adqua
    ツールの出力結果のメトリクスだけ見せられても、良いかどうか判断出来ません。Adquaの場合、出力結果を送ると、無駄なコードの有無や警告数などから、コードの品質を、信頼性・効率性・保守性・移植性・再利用性 という観点で100点満点で評価をしてもらえます。メトリクスの範囲も、システム/モジュール/ファイル といろいろな範囲で取得可能なようです。無料で使用出来ますが、最低年1回のデータ提出することや、組込みプログラム限定といったいくつかの条件があります。

ちなみに、私は、以下の様なツールを使ったことがあります。

Sourceonitorは扱いやすいのでよいかもしれません。 CCFinderXは、コードクローンを調べるためのツールですが、メトリクスも出力してくれます。ただ、Phythonの設定とかに手間取り苦労したような気がします^^;

データ分析時の留意点

午後になり、演習パートになりました。

データを受け取った時どのようにアプローチするかを決めなかればなりません。

たとえば、特定のメトリクスに着目し、1つまたは2つ以上の変数に着目して、あるいはある値を基準にグループ分けを行なうようなアプローチや、このようなサイト( http://aoki2.si.gunma-u.ac.jp/FlowChart/Tutorial.html ) に従いアプローチを決める方法などがあります。

とりあえず、以下の様なことをするとよさそうです。

  1. 散布図行列を出力する。
  2. 外れ値やおかしなデータがないか確認する。
    工数やバグ件数など、手で入力するようなデータはおかしなデータがはいりやすい
  3. 各変数自体の分布を調べる
    偏ったりする場合には、対数変換などのデータ処理を必要があるかどうかを考え
  4. 相関があるかどうかを視る
    目的変数と相関が強いものが説明変数の候補となる説明変数候補同士で相関があるかどうかを確認する。
    相関がある場合は、両方は不要なのでどちらかに絞るかを考える。

他にも以下の様なお話がありました。

  • レンジの幅が大きくしまうようなソフトウェアメトリクス時に、等分散性を確保するための補正手段として対数変換を行なうことがある。そのとき、値が0だと定義できないので、インパクトの与えない程度の補正(下駄をはかせる)は手段としてはあり。
  • 寄与率(重相関係数)、自由度調整寄与率(重回帰分析)をみて50%程度では一般的にあまり良いとはいえない。
  • 一般的にデータが多ければ、検定結果のp値は小さくなる。従って検定結果だけでは、モデルの精度を判断することが出来ないので、寄与率などの指標も見る必要がある。
  • 検定はデータが少ない時につかう。データが多い時にはあまり使わない。

外れ値の精査を行なうことは、データ解析結果をきれいにするためには必要なようです。どれくらいやればいいかは、また外れ値の扱いも、ケースバイケースになり難しいようです。うーん、難しい・・・。

 データやデータ間の相関などは、経験の差が出るようで、繰り返し・継続してやってみてセンスを磨くしかないようです。

次回予定

次回は、2013年2月16日(土)に実施予定。内容は、いろいろな分析手法を手を動かしながら試してみよう、ということになるようです。是非ご興味ある方がいらしゃいましたら参加してみてはいかがでしょうか。

(2013/1/21 21:12追記)

「(ソフトウェア品質技術者のための)データ分析勉強会第8回目」の参加申し込みが可能になっています

http://kokucheese.com/event/index/71408/

告知

講師の小池さんより以下の様なアナウンスがありました。ご参考までにお知らせします。

  • ソフトウェア品質のホンネ
    SQiPポータルサイトから参照できます。ソフトウェア品質の世界で著名な方々が執筆されてます。
  • 2/25 SQiP特別講演「データ指向のソフトウェア品質マネジメント」
    次年度はセミナーを予定しているのでその説明をします。参加費5000円(本付き8000円)ですので、ご興味あればぜひご参加くださいとのこと。
  • 2/14 第6回SQuBOKユーザ会勉強会
    小池さんと堀さんが講演なさいます。会場は、日科技連 千駄ヶ谷の講堂ですが、Ustreamで配信も行います。小池さんのテーマは、SQA活動についてで、以前実施されたIPASECの講義を元にするそうです。
  • 来年度のSQiP研究会で「メトリクス演習コース」を開設します。
    小池さん、小室さん、野中先生で演習コースを行なうとのこと。カリキュラムとしては3フェーズとし、メトリクス収集活動の明確化、ツールを利用した統計解析の習得、事例適用を想定しているようです。興味ある方はぜひ参加してくださいとのこと。