ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

「ソフトウェアプロジェクトでのめんどくさい人の扱い方」 、品質保証(QA)の場合

 こちらのツイート*1を見て、さっそく見に行ってきました。
 美しい色使いで構成されたこのサイト、そこにあるスタイリッシュな動物アイコン群はそれぞれ、「めんどくさい人」の象徴でもあります。

 「めんどくさい人」はまず以下のロールに分けられています。

  • プロダクトマネジャー
  • デザイナー
  • プロジェクトマネジャー
  • 開発マネジャー
  • 開発者
  • 品質保証(部門)

 アイコンをクリックすると、「めんどくさい人」が以下の構成で説明されています。

  • 定義と特徴
  • 修正の見込み
  • プロジェクトへの弊害
  • 問題点
  • 対処法

 アンチパターン集と、ソフトウェアバグのアナロジーを混ぜたような感じですね。
 それぞれのロールにカテゴリーがあります。仕事柄、「品質保証」を読まざるを得ません。

 以下では、品質保証における「めんどくさい人」の定義を紹介します。
 カテゴリーごとに感想を書こうと思いましたが、概ねオリジナルページに包含されているので、この美しいサイトを読んでみてください。気が重くなりますよ。

The Firehose(消火ホース)

neilonsoftware.com 「大量のバグレポートを開発者を投げつけるQA。あまりに速すぎるので開発チームがバグのバックログに圧倒され、対応しきれなくなる」

The Blamer(非難屋)

neilonsoftware.com 「バグを見つけるたびに、『なぜちゃんとテストしていないんだ!?』と開発者を追求するQA」

The Alarmist(警告屋)

neilonsoftware.com 「第一印象だけに基づいて、プロダクト全体の品質が受け入れられるレベルじゃないと宣言してしまうQA」

The Scientist(科学者)

neilonsoftware.com 「バグを見つけることよりも、バグを文書化することに大半の時間を使ってしまうQA」

The Misleader(惑わせ屋)

neilonsoftware.com 「バグを不正確に報告し、事象の再現やバグを改修するための方向性を、開発者に見誤らせてしまうQA」

The Downtrodden(いじめられっ子)

neilonsoftware.com 「開発者に虐げられ、いじめられることを恐れてバグを報告できなくなっているQA」

The Random Clicker(ランダムクリッカー)

neilonsoftware.com 「バグを見つけるために、思うがままにただクリックしまくるQA」

The Flippant(不真面目)

neilonsoftware.com 「開発者が失礼だと感じるような、受動攻撃的な *2バグレポートを書くQA」

所感

 みなさんの職場では、心当たりがまったくないものばかりですよね!
 他にも、プロセスを守ることがすべてに優先する「プロセス屋」とか、テスト・品質の技法を振り回して権威を築こうとする「技法屋」がいると思いました。
 自分たちのチームがこのようなアンチパターンパーソンになっていないか、定期的に振り返りたいものです。

*1:タイトル訳もそのままお借りしました

*2:受動的攻撃行動(Passive-aggressive behavior)とは、Wikipediaで以下のように説明されています。初めて聞きました。

怒りを直接的には表現せず、緘黙や義務のサボタージュ、あるいは抑うつを呈して相手を困らせるなど、意識的無意識的にかかわらず後ろに引くことで他者に反抗する(攻撃する)行動である。

『テスト管理を語る夕べ』での発表内容についての補足(とか言い訳) ー 後編

 まーた間が空いてしまいましたが、後編では、当日の関連ツイート(togetter)に対し回答・補足していきたいと思います。

www.kzsuzuki.com togetter.com

 資料はコチラです。

www.slideshare.net

そもそもの目的について

 「目的」は、確かに根本的なことなのですが、「あまり考えていない」というのが本音です。「ぼくがかんがえた、さいきょうのちょうじん」みたいなもので、高邁な目的などなく、「こんなの考えたけどうどう!?」くらいの意味しかないです。それでも、何かのネタになるならいいかなーくらいです。

 まああとは、

 これですね。

テストプロセス・用語について

 発表資料P.10~22あたりです。

 「テスト観点」という用語は、JSTQBの用語集に載らないほど深遠なものなので、あえて立ち入りませんでした。。

 にしさんからのご質問と、それに対する回答だったかと思いますが、ちゃんと回答できていませんね。
 わたしとしては、フローグラフや状態遷移図に、カバレッジ基準やフィルタ基準を追加したものが、テスト設計仕様だと考えています。
 たとえば状態遷移図を書いて、「2スイッチカバレッジ=100%を満たすためのテストケースのうち、優先度・高の状態を経由するもののみ」みたいな基準を与えるということです。

 これについても当日、やまさきさんのご指摘を理解できなかったので、後日確認した結果が以下です。

 わたしとしてはできるだけI/JSTQB用語に準拠したいと思っていて、あえて独自路線を走るつもりはなかったのですが、不勉強と誤認のため「ズレ」が出ていたようです。
 そうか、テストケースってテスト設計のアウトプットなのか・・・。この辺は勉強しなおしです。。。

テストケース周りのER図について

 発表資料P.24あたりです。

 これは鈴木三紀夫さんによる、「テストケース周りをモデリングする際の2つのアプローチ」についての説明です。
 1つ目は、現在すでにある帳票(たとえばExcelベースの書式)からのモデリング。たとえばExcelシートに「機能ID」「機能名」を書く欄があって、その下にテストケースを書く行がずらーっと並んでいるとしたら、これは「機能IDに対してテストケースは0個以上存在する」ということを意味していることになり、ER図でいうと1:nの関係になります。
 もう1つのアプローチは、すでに実装されているテスト管理ツールの外部仕様から、「おそらくこうであろう」という内部モデルを推定するモデリング。

 今回のわたしのモデリングは、基本はまず後者。バージョン管理、プラットフォーム管理という部分はTestLinkから、データ駆動テストの部分はSquash TMから。またキーワード駆動テストの部分は、使用している自動テストフレームワークから学んだことをベースにしています。

 現場のExcelテスト仕様書も、テスト管理ツールも、As-Isであることには変わらないと思っていて、両方をごっちゃにした印象になりましたね。

 おそらく、ER図を見てのご指摘かと思います。「テスト設計仕様」を導出するものとして「テスト開発の上流成果物」をおいているのですが、テストベースもこの位置にあるべきですね。「テスト設計仕様」より上流の工程はある意味ブラックボックスで語っちゃっています。

 初めはテストケースと「観点」をn:1で関連付けていたのですが、にしさんに「1つのテストケースに複数の観点が入ることはないのか」と問われ、n:mにしました。その後もう一度考え直し、「観点とテストケースの間に、テスト設計仕様があるのでは」と考えて、今の形になっています。この辺は、全然煮詰まっていないですね。

テストケースが持つべき情報について

 発表資料P.27あたりです。

 あまり厳密にルール化しない方がいいかなと思います。発表資料P.27にあるように、機能・品質特性・テスト設計仕様名*1からある程度類推できるので、さらに補足があれば補う、程度で。

 これはどんな議論だったか忘れてしまった。
 たしか、「テスト手順」に入る前の、「事前条件」を整えること自体の pass / fail を確認したいという話だったかと思います。
 リプライにぶら下がっているように、それを確認したいなら「事前条件」を「手順」に移すのが自然じゃないかなと思います。

テストケースのバージョン管理について

 発表資料P.31~32あたりです。

 当日の議論は、「共通部」には変更が発生せず、「個別部」はバージョン管理を行う、という前提でお話ししていました。
 言われて気づきましたが、確かにバージョンに依存しない「共通部」も変化はしますよね・・・。ってことはバージョン管理が必要なのか・・・。
 現時点では、「誤字レベルはバージョン管理しない。それより重い変更は、テストケース自体が別物と考える」かなあ。

 確かにそのとおりで、インシデント管理システム側にプロダクトバージョンを記録することはあると思います。
 ですが、その場合、「インシデントを検出したテスト実行」にしか記録されない可能性があるので、「テスト実行」自体に、対象プロダクトバージョンと対象テストケースバージョンを記録しておくべきかなと思います。

 これは資料P.32の表現が悪かったです。
 ある1つのプロダクトに対しバージョンがあり、それに対応してテストもバージョンが上がっていきます。
 一方そのプロダクトに兄弟製品(たとえば機能制限版)があると、その別プロダクトに対してもテストが定義され、別プロダクトのバージョンが上がると、それに対応してテストもバージョンが上がっていきます。
 議論の中で、この2つのプロダクトのことまで「プロダクトバージョン」と呼んでいたため、おかしくなっていました。

 この辺は議事録なのか個人ツイートなのか思い出せないのですが、今回の議論の中で特に生煮えな部分だと思います。
 データ駆動化されたテストケースにおいて、「バージョン個別部」のテストパラメタまで変わる場合、パラメタライズされた手順に影響があるのは必至です。となると、「バージョン個別部」に対応して「テスト手順」も変わっていくので、バージョン管理が必要ですね。ただ、「バージョン個別部」と「テスト手順」は1:1対応でいい(ような気がしている)ので、いっしょくたに管理することになるのかもしれません。

データ駆動・キーワード駆動について

 疑問の内容がうまく理解できていないのですが、「パラメタと値をどういうテーブル構造で管理するのか」ということでしょうか。
 SquashTMというテスト管理ツールは、データ駆動用のパラメタをテスト手順と個別に保持することができ、そのパラメタ数は可変です。
 おそらく、パラメタ1・値1、パラメタ2・値2、・・・というカラムを持つテーブル構造なのではと思います。

 このネタ1本でけっこうもちそうなテーマですね。実行時まで抽象的テストケースのままということはありうると思います。

その他

 だいぶ、事前に参照しておくべきことを怠っていました。勉強します。

 次回の議論があれば、絶対そうした方がいいですね・・・。

 バージョンの話と、データ駆動・キーワード駆動の話はかなり色合いの違う話で、また上述のように、エンティティの関係性はかなり生煮えでしたね。
 一人で考えていると、なんとなくきれいに整理できた気になるのですが、実際に運用回そうとするといきなり行き詰まりそうだとよくわかったので、あらためて整理していきたいと思います。

 E-R図をしっかり見直してからこの「後編」を書こうと思っていたのですが、いつまで経っても完成しないので先に投稿します。
 修正版E-R図は、またどこかで・・・。

*1:P.27にはテスト設計仕様IDしか書かれていないけれど、テストケースのビューとしては設計仕様まで表示するとベター

進捗管理のメトリクスに関するメモ

 作業の進捗における、計画値と実績値の乖離の表現について、考えたことの整理&実験です。
 ここでは例として、テストケースの件数ベースの進捗管理を考えます。

遅延率と「相対的進捗率」

 「どれだけ遅延しているか」を表現する場合によく使われるのは、「遅延率」です。
 たとえば、ある時点で50件が消化済みである予定だったが、実際には45件しか消化できていない。この場合、分母が50、分子が5(=50-45)なので、遅延率は10%ということになります*1。直感的でわかりやすいですね。

 一方、Squash TMというテスト管理ツールでは、「Real vs. prev. progress」というメトリクスが使われています。

sites.google.com

 計算式が不明なのでいろいろ試してみると、以下のようなものだと判明しました。名前がないので、ここでは仮に「相対的進捗率」と呼ぶことにします。

相対的進捗率 = 進捗率 / 期間経過率

 自然言語でいうと、「経過した時間に相当するだけの進捗が出ているか」ということです。
 たとえば、全10日のテスト期間に対し3日間がすでに終わったとして、全100のテストケースのうち20件が消化済みだとしましょう。進捗率 = 20%、期間経過率 = 30%なので、相対的進捗率は66.7%ということになります。

 遅延率を使う場合、「妥当な消化計画があること」という暗黙の前提がありますが、相対的進捗率の計算には「消化計画」は出てこないので、計画を立てない場合でも利用できます。逆に言うと、たとえば「最初の立ち上がりは遅いが、途中からテストケース消化のスピードが上がり・・・」といったニュアンスは加味してくれません。

 ちなみにSquash TMでは、テストケースごとの消化計画という概念がありません。理由はわかりませんが、短期間のイテレーションごとにテストを行うという文脈でのツールなので、わざわざ綿密な消化計画は立てず、期間で簡易に進捗状況を把握しようということなのかもしれません。

遅延率と相対的進捗率の比較

 ざくっと整理すると、以下の表のようになります。

遅延率 相対的進捗率
意味 計画した消化済み件数に対する、計画と実績の差分 すでに経過した期間の割合に対する、すでに消化した件数の割合
計算式 (消化済み件数(計画)-消化済み件数(実績)) / 消化済み件数(計画) 進捗率 / 期間経過率
値域 -∞~0~100% 0%~∞
0%の意味 計画に対して遅延がない状態 進捗がない状態
100%の意味 進捗がない状態 経過した時間に対して遅延がない状態
-100%の意味 計画に対して実際の進捗が倍の状態
長所 計画が適切であれば、遅延の程度がわかりやすい。 計画がなくても、日数の経過だけで算出できる。
短所 計画が不適切だと、重大な遅延を見逃すことがある。 件数の重みがある場合などが考慮できない。

2つのメトリクスの挙動

 まずは一番単純なケースとして、「毎日同じ件数だけ消化していく」計画を考えてみましょう。マーカーがある方が第1軸、ない方が第2軸です。

01

 最初は計画を上回る進捗速度でしたが、次第に鈍化していき、7日目には計画を下回っています(赤の実線)。
 遅延率(青の実線)は0%が基準、相対的進捗率(緑の実線)は100%が基準であり、正負は逆転しているものの、本質的に同じ動きをしています。

 次に、「始めはなだらかに、中間は急に、終盤はまたなだらかに」という計画を考えてみます。テストの場合、最初の立ち上がりに時間がかかったりするケースはよくありますね。
 この計画に対し、1日目だけ1件遅延するケースはどうなるか。

02a

 遅延率はいきなり100%と最悪値ですが、それ以降は計画どおりなので急速に0に戻っていきます。一方相対的進捗率は、計画とは無関係に、「経過した時間の分だけ進捗しているか」なので、進捗スピードの速くなる中盤になるまでは正常値に戻りません。

 こうして比べてみると、妥当性のある計画がある場合には遅延率で、そうでない場合は相対的進捗率で様子を見るとよさそうですね。

遅延率と相対的進捗率の問題点

 さて、2つのメトリクスの今ひとつの欠点について。

 たとえば毎日、計画の8割ずつしか進められなかったとしましょう。遅延率は、ずっと20%です。それ自体は正しいのですが、期間の序盤の遅延20%と、終盤のそれとでは、「ヤバさ」が異なるはずです。が、それを読み取ることは難しい。

03a

  そして奇妙なことに、相対的進捗率の方も、なだらかながら「改善」しています。進捗スピードこそ計画の半分ながら、中盤の急な計画に対する半分なので、期間比率からみると改善しているように見えてしまうのです。
 となると、この2つを合わせて見ても、「遅延は一定だが、全体的には回復傾向にある」とミスリードされかねません。

遅延率に残期間を織り込んでみる

 ということで、遅延率の考え方と、相対的進捗率の2つの要素を合わせて、次のような式を作ってみましょう。仮に名前を「進捗リスク」と置きます。

進捗リスク = 遅延率 / 期間残余率

 期間残余率 = 1- 期間経過率 で、要は10日の期間のうち8日経過したのであれば、残余率は20%です。
 これを先ほどのグラフに追加すると、こう。

03b

 「リスク」(赤い実践)があからさまに増大していることがわかります。8日では分母が0.2、9日目では0.1になるので、全体として倍になるためです。

 「1件だけ遅れ続けている」ケースにおいても、

02b

 序盤では「あー、遅れてると言っても1件だけね、特に問題ないかな」って感じで0に近づいてきますが、中盤から「は? いつまで遅延残してるの?」って雰囲気を出し始めて、終盤で「おーい! 早く回復しろよ!」と訴え始めるふるまいになっています。なんかかわいいですね。

 いや、進捗管理の定石メトリクスってこれだろ普通!っていうのがあれば教えてください。特に何も調べず、Excelとにらめっこしながら考えただけなので・・・。

*1:前倒しの場合、遅延率はマイナスになります。

『テスト管理を語る夕べ』での発表内容についての補足(とか言い訳) ー 前編

 『テスト管理を語る夕べ』というイベントで、お話をさせていただきました。
 主催のみっきーさん、インフラ整えてくださってしんすくさんとなそさん、twitter実況してくれた書記のぱいんさんとブロッコリーさん、←どんなメンツなんだ?
 そしてこんなマニアック目なテーマの勉強会に金曜夜を使ってくれた奇特な参加者のみなさんに感謝します。

kataruyube.connpass.com togetter.com

 「テスト管理」というと対象範囲が広く、たとえば「テストの進捗に遅延が発生した際に、どのように解決していくのか!」といった、かっこいい感じの「テスト管理」もあるのですが、今回の発表は地味な「テストケースの持つべき情報・構造」に関するものです。

 Excelによる2次元表でのテストケース&テスト実行管理というのがもっとも「わかりやすい」ものですが、その扱いづらさ、限界、破綻を感じるは少なくないでしょう。
 たとえば2回同じテストを行い、その結果がExcelの1行に「pass/fail」と記載されているのを見たことがありませんか。こんな些細なことでも以下のような問題があります。

  • 1つの行に複数の結果が書かれており、集計が困難になる。
  • 2回のテストが、どのプロダクトバージョンで行われたか追跡できない。
  • 同じプロダクトバージョンで2回目で合格したとしたら、テストケースの方を修正した可能性があるが、それも追跡できない。

 場合によってはそこから、いわゆる「テスト管理ツール」の検討に進む組織もあるでしょう。しかしそれもうまくいくとは限りません。
 テスト管理ツールが提案するテスト管理・表現方法と、自組織の考え方が合わない。手動テストと自動テストをうまくシームレスに扱えない。導入のためのイニシャルコスト(検討、ツール比較、パイロット導入、ルール作成、トレーニング、・・・)が払えないなど。
 幸いわたしは、仕事の一部にテスト管理ツールを導入できていますが、それもどうも、ニーズを完全に満たすものではない。

 そんな中で、そもそもテストケースというものはどのような「カタチ」をしているべきなのだろう。また他の成果物とどのような関係を持つべきなのだろう。ということをあらためて考え始めました。ざくっとまとめてTwitterに投げたのが、以下です。

 これに対し有益なコメントをたくさんいただけたので、一人で盛り上がって2次検討した結果が、以下の表とER図です。ER図は記法がいい加減なので「エセ」ですが。

er contents

 今回はこの2つを中心に、

  • テストケースのバージョンとは
  • テストケースのパラメタライズとは
  • キーワード駆動テストとは

などについて自分の考えを説明しました。

 後半はパトスがほとばしり過ぎて謎の早口おじさんになっていた気がしますが、少なくとも一部の方には興味を持っていただけたようで、ほっとしました。

 さて、以下に資料を公開していますが、当日多くのツッコミを受けたことからもわかるとおり、ドラフトに過ぎない資料です。
 今回いただいたご質問・ご指摘を踏まえてもう少しブラッシュアップしようと思っています。また、これもう少し進めたいねというご意見があれば、第2回目もやりたいなー(わたしはあまりしゃべらない立場で)とも思います。

www.slideshare.net

 この記事は「前編」です。「後編」では、いただいたコメントに対し、現時点での回答を試みます。

モデルベースドテストについて学んでみよう ー その1

 この記事は、「モデルベースドテストについて学んでみよう」2018年アドベントカレンダー、1日目の記事です。
 こんな構成で、クリスマスまでに8夜分くらい書く予定です。

  1. 例によって、ISTQBシラバスを読みながら、自分の理解をまとめる。
  2. MBTを実現するためのツールを使って、具体的なイメージを掴む。

テスト自動化アーキテクチャにおける位置づけ

 第1回では、テスト自動化においてMBTがどう位置づけられているかについて確認していきます。
 ISQTBのAdvance Level - Test Automation Engineer(以下「ALTAE」)のシラバス3.1.1では、「包括的テスト自動化アーキテクチャ」(generic test automation architecture、gTAA)というものを定義しています。その全体図を引用します。

gtaa
※ALTAEシラバスより引用

 内側に「テスト生成」「テスト定義」「テスト実行」「テスト適合」の4つの層があります。テストプロセスでいうと、生成はテスト設計、定義はテスト実装に、実行はそのままテスト実行に、ほぼ相当します。
 わかりづらいのが適合(adaptation)です。

The Test Adaptation Layer which provides the necessary code to adapt the automated tests for the various components or interfaces of the SUT. It provides different adaptors for connecting to the SUT via APIs, protocols, services, and others.

 ざっくりいうと、テスト対象プロダクトの実装に依存しないテストケースと、プロダクトを結びつけるための層です。
 たとえば状態遷移表から1スイッチカバレッジ100%を満たすテストケースを導出したとしましょう。人間であれば、プロダクトの仕様から、どのような操作をすればこのテストケースを実行できるかを推測することができそうです。一方、機械は(今のところ、たぶん・・・)そうはいきません。ですので、実装に合わせて「このように操作する」ということを翻訳してやる必要があります。これを担うのが「適合」の層です。

 さて話が逸れましたが、モデルは「テスト生成」層にありますね。
 テスト生成の中にあるもう1つの層が「手動設計」であることを考えると、「テストモデル」とは「自動」的にテストを生成するものと想像できます。

Automatically generating test cases from models that define the SUT and/or its environment (i.e., automated model - based testing)

 テスト自動化のアーキテクチャの一部に、テストケースの自動生成というブロックがあるのですね。

長所と短所の概要

 3.2.2では、「テストケース自動化のアプローチ」として、7つのアプローチの概要とメリット/デメリットを解説しています。
 たとえば一番初歩的な、キャプチャ・プレイバックアプローチ。テスターがプロダクトを操作する過程を記録し、それを同じように再生することで、実行の自動化を実現しています。
 また、抽象化やモジュール化を進めて可読性・保守性・再利用性を向上させた「キーワード駆動テスト」も、テストの「実行の」自動化の話であり、スクリプトの形態に違いがあるだけです。詳しくは以下のような記事で言及していますが、これらは「テスト実行」の自動化に伴うスクリプトの書き方に関するものです。

www.kzsuzuki.com www.kzsuzuki.com

 一方、モデルベースドテストは、テストの「実装の」自動化の話。ソフトウェアの一側面を規定のルールに従ってモデル化し、これに対し何らかの基準(カバレッジ基準やフィルタ)を与えることで、条件を満たすテストケースが導出されるという仕組みです。
 「テストケースの自動化」という不思議なタイトルになっているのは、「実行」と「実装」が混じっているからかもしれません。

シラバスの説明の要約

基本的なコンセプト

  • MBTは、テストケースの自動実行ではなく、自動生成に関するものである。
  • (準)形式的なモデルを利用する。
  • テスト生成のメソッドは一つではない。
  • スクリプティングフレームワークのためのテストを導出することができる。

 最後の部分が少しわかりづらいのですが、ここは何気なく大事なことを言っています。
 それは、テスト自動実行の形に合わせて、テストケースの自動生成をすることができるということ。つまり、MBTのためのモデルを適切に設計することで、テストケースの生成から実行まで一気通貫で自動化できる、ということを暗示しているのですね。

長所

  • 抽象化によって、テストの本質部分(ビジネスロジック、データ、シナリオ、構成、・・・)に集中することができる。
  • (システムの内部で利用される)技術が変化していっても、モデルは再利用・保守することができる。
  • 要件に変更があった場合でも、モデルだけをそれに合わせればよい。テストケースはそこから自動的に生成される。

短所

  • SUTを、インタフェース、データ、ふるまいといった観点で抽象化するのは高度な技術であり、モデリングの専門家が必要。
  • MBTのためのツールがまだまだ主流ではなく、成長段階にある。
  • テストプロセスと統合していかなくてはならない。
  • 品質のよいテスト生成のために、モデル自体の品質保証が必要になる。

 長所としては特に3つ目が重要だと思います。テスト対象を分析・抽象化した結果がモデルだであり、これとテスト設計を組み合わせることでテストケースが生成される。最終生成物がどのように導出されたかの「根拠」が、モデルと設計に残っていることが重要です。

 短所として、ツールがまだいまいちというものがあります。ただ実用で通用するのではと思えるものもありますので、このシリーズの後半でそのイメージをお伝えできればと思います。

 では、第2回以降は Foundation Level - Model-Based Tester(FL-MBT)を読んでいきましょう。