[本]マインドマップから始めるソフトウェアテスト、届きました

ソフトウェア・テストPRESSからのスピンオフ、「マインドマップから始める～」が技術評論社から出ました。

第1部では、ソフトウェアテストって？マインドマップって？といった基本的な紹介。品質と健康とを対比した説明はテストPRESSにも見られましたね。

第2部では、多くのページ数をさいて、実際のソフトウェア開発のケースを例にしてマインドマップを使ったソフトウェアテスト（仕様分析～テスト報告）の段取りがわかりやすく解説されています。テストPRESSでは、テスト設計からテストケース作成までの解説のみでしたが、書籍化されたことによってそれ以外の応用についても言及されています。本書は新人クン向けでもあるが、「テストカテゴリ」やIEEE829「テスト計画書テンプレート」などは、僕も勉強になるし、ナゼその項目が必要なのか、必要でないのか、などを再学習できた。負荷テストについての創発がメインで取り上げられていたが、負荷テストにマインドマップのようなブレーンストーミングを取り入れたことがなかったので、再度じっくり読んで、活用できないか検討してみようっと。

第3部はデジタルツールについての紹介。僕も最近はFreeMindを使ってみるようにしたけど、イマイチスピーディーに使いこなせていない気がする。やはり手書きが一番か？？

第4部は本書のまとめ。「気づき」を得ることが第一。フランクリンコビーの研修でもこのマインドマップをツールとして紹介していたし、「気づき」を大切にするという共通点があると思う。

==

まあ、当たり前のことだけど、テスト設計でマインドマップをすると、たいていブラックボックス的なブランチが多くなりがち。ホワイトボックステストの設計って直感的・経験的なブラックボックステストよりも難しいって話を聞いたことがあるけど、この方面でもマインドマップって活用できないかなあ。例えばモジュール設計で、カバレッジしやすい設計をするために、マインドマップでカバレッジしにくい箇所を特定して、対策を考えるとか。うーむ。

より良いテストを実現する企業文化

ゼロテストって一般的な言葉なんだろうか？

==

バグに効く習慣～より良いテストを実現する企業文化 by ウノウラボ

新人にまずやってもらうことは？

新人テスターをいきなりテストに参加させるのは良くありません。製品への理解が深くないと有効なテストは出来ないからです。 まずは製品の仕様を覚えてもらったり、バグレポートの書き方を覚えてもらったりしなくてはいけないのですが、仕様書をポンと渡して、「これを見ながら製品を全部動かしてみて」といった指示を出しても現実味がなくモチベーションは揚がらないでしょう。

最初にやってもらうことは、先輩テスターの書いた障害報告の再テストか、
画面遷移図の更新など手探りで学習しながら行えることが良いと思います。

テスターではないけれど、新しくチームに加入したメンバーに先入観のない状態でユーザテストをしてもらうことはよくある気がします。テストをお願いした人としては「ここの機能って使いづらくないですか？」「これはどうやって設定するんですか？」とか指摘してほしいんだけど、意外にそんな指摘は出てこなかったり。萎縮しちゃって。

テストにかかる工数を忘れない

何故かコードを書くとなると、人はコーディングの終了イコール完成だと考える傾向にあるようです。（このことに関しては自分も人のことは言えませんが。。） 名著「人月の神話」では工数配分の例として　設計1/6 コーディング1/3 テスト1/2という比率を示しています。 趣味のプログラムではないので、検証にかかる工数を忘れないように現場の意識を保つようにしましょう。

テスト工程をきちんと覚えておく、とは少し違うかもしれないが、「すべてがテストツールで実現できる、と思わない」とかも重要かな。テストツールでできないこともあるし、事前準備や教育、テストケースの老朽化などなど、予想以上にコストがかかる場合がある。

ふと思ったので、トラックバック。

どんな単体テストをしますか？ - for文のホワイトボックステスト その２

ずいぶん、亀自己レス。

==

for文を含むプログラムでは具体的にどうやってホワイトボックス的アプローチをするのか。ループする回数を同値分解するのはどうだろうか。0回、1回、無限回（実際に無限回はありえないので一般的な大数か）とか。んで、今回のソースはmonthという入力条件があるので、

month=0のとき（for文を経由しない、monthパラメータの無効クラス）

month=1のとき（for文を1度経由する、monthパラメータの有効クラス）

month=13のとき（for文を複数回経由するが、monthパラメータの無効クラス）

の3条件は少なくともチェックしたい。まあ、こうもいかないループもありそうだけど。。。

==
2007/06/17追記。
よく考えたら、month=12のがいいな。そうすればループ内のswitch文でcase 1～case 12までを経由できるし。

[本]マインドマップから始めるソフトウェアテスト

もうすぐでますね、マインドマップ＋ソフトウェアテスト本。発売日は6/22です。

ソフトウェアテスト専門誌「ソフトウェア・テストPRESS」の特集「マインドマップからはじめる～」が書籍化。マインドマップ（マインドマッピング）とはトニー・ブザンが提唱するブレーンストーミングの一種で、中央から枝を伸ばしていく形で発想を図式化していく記法。フィッシュボーンチャートに形は似ている。

「テストする」とは単に与えられたプロダクト・サービスを試しに使ってみて問題ないかどうかを検証するだけに思われがち。でも、このブログでいろいろ小難しいことを記録しているように、「いかに効果的に」「以下に効率的に」「いかにムラなく」テストするか、と考えるとなかなか奥が深い。（ムラというのはテスト網羅性と実施者のスキルによらない、という意味も含めて）

そこで巷では結構有名なマインドマップという手法をソフトウェアテストに適応させたのが、この本。どちらかというとソフトウェアテストの初心者向け・ABC的な切り口なので、これから勉強しようと考えている方々にも、これからテスト技術者を育てようとしている方々にも、また再勉強を考えている方々にもすすめられそうな気がします。（僕もまだまだ未熟なれどもマインドマップをテスト設計に適応してみたりしてる口です！）

んで、マインドマップとソフトウェアテストの親和性についての私見。トニー・ブザンのルールには含まれていないが、マインドマップではMECEであることが重要（特にメインブランチ）。このMECEさがソフトウェアテストの網羅性や効率性に大きく貢献できる要因ではないか、と。

この本のために有志によるマインドマップ＋ソフトウェアテスト勉強会があったのだが、都合がつかず不参加だったのが、ザンネン！！

発売したら早速買って読んでやる！

==

そういえばPRESS3巻とかにもあったにしさんのNGTもブレーンストーミングのロジックツリーに形が似てたなあ。

↑マインドマップを使ってテスト設計まで

↑続編。テスト設計からテストケース・テストプロシージャに落とし込むところ

↑同時期に発売のマインドマップ本。JUDE。

実施不足と考慮漏れと自動化と

少し落ち着いてきたので、ブログ更新。今日は結婚式の打ち合わせ×2回分。明日はディズニーランド、でも天気は荒れ模様らしい。でも。晴れ男だからチャラ・ヘッチャラ。

==

タイトルにそんなに深い意味がないけど、ここ数週間で思ったキーワード。超基本的だけど、勉強と実行には大きなギャップがありますねぇ。まだまだ経験が足りないな。経験しなくては。

モブログテスト

モブログテスト。nifmail.jpから送信できるかな。

-------------------------
アナタに快適なメール生活
http://nifmail.jp