ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

ソフトウェアの品質コミュのテスト本情報

  • mixiチェック
  • このエントリーをはてなブックマークに追加
テストの書籍や記事(Web含む)の情報を集めようとしても,どうしても取りこぼしてしまいがちです.

何か情報があったら皆さんでシェアできたらと思います.(^-^

コメント(27)

ソフトウェアテストHAYST法入門を読んだので感想を。

これは、単なる直交表の本ではありません。

HAYST法とは単に直交表を使うための手法なのではなく、日本発のテスト方法論です。組み合わせで発生する不具合を減らすという目的の元、全体戦略ありきで、テストレベル毎の戦略を立てた上で、テスト分析や設計のツールを活用しています。同値クラスの考え方や状態遷移テストへの応用や不具合の分析やテスト実施網羅率を含むメトリクスの採り方まで入っています。

個人的には状態遷移テストの行列計算が、「なるほど」という感じです。バイザーを読み直すきっかけになりました。(そこから自分にとっての新しい発見もあったりして)

HAYST法という方法論を組織へ展開するために、組織的にゴールを共有する方法(BSCを使う)や、定着の仕組み(基礎教育、コンサル、ツール)についても触れられていて、理論だけでない、定着のための現実的な話もたっぷりあって。

誰もが自分たちの参考にできるのではないでしょうか。

あと、用語もJSTQBをちゃんと意識してあわせているので読みやすいです。

ほめすぎのようですが、本当にそう思います。

難点はほとんどないのですが、しいて言えば、直交表自身の説明はきっとテストプレスの秋山さんの記事ほうが分かりやすいです。テストプレスの知識が前提で呼んだほうがいいかも。(逆に禁則など込み入ったことはこの本のほうが書いてあるので、両方読んだほうがいいかもしれません。)

あと、HAYST法って結局どこまでを指しているのか明確に書いてもらったほうがすっきりするかも。(この本に書かれていること全てがそうなのかもしれませんが。。)
ゆもつよさん。
お忙しいなか、読んでくださってありがとうございます。
また、とても褒めていただいて恐縮です。

> 直交表自身の説明はきっとテストプレスの秋山さんの
> 記事ほうが分かりやすいです。

そうですね。あちらは、前提知識が全く無い人を想定して書いたので丁寧ですね。

> 両方読んだほうがいいかもしれません。

確かにその方が入りやすいかもしれません。
# でも、Vol.2って絶版のようで、Amazonみたらユーズド3,800円だって。うーん。テストPRESSは本と同じく全巻普通に買えるように手配して欲しいなぁ。>技術評論社

> HAYST法って結局どこまでを指しているのか明確に

実は、以前日記に書いたのですが、私の目標はそこにありました。
で、それが結局実現できなかったことも反省点です。

HAYSTという名前ができたのは、禁則処理が完成した時なので当初は、「L128直交表+抽象化+3つの禁則回避手法+網羅率で品質を測る」がHAYST法でした。
言葉で言うと、「2因子間網羅率100%を目指さない直交表によるテスト」がHAYST法です。「目指さない」というのは「効率を考えよう」ということで、
 ・2因子間は概ね80%を目指す(ただし現れなかった組み合わせについては必ずテストしなくて良いかレビューする)
 ・3因子間については、重点的にテストを行う
が始めの頃のHAYST法でした。

それで、それを現場に展開していったところ、それだけでは、単機能に関する確認にモレが生じてしまったり、因子・水準の抽出が上手くできなかったりする問題が生じたので、FV表とFL表ができました。

その後、FV表、FL表で見つかった問題を開発に伝えたところ、「そういうのは早く言ってくれよ」ということになり、仕様書などのレビュー時に使うようになりダブルVモデルなんて話が出てきました。

私は、最初の「2因子間網羅率100%を目指さない直交表によるテスト(抽象化と禁則割付技法)」のところをHAYST法だと思っているのですが、、、。
そうですよね。
理想論で書かれたものは、結局どの現場でも実践されず
終わってしまうのが現実です。
まだこの業界が未熟だからなんでしょう。

どの業界だって、現場で実践して学んで失敗して
本当の理論を作り出していくものです。
急がず焦らず、ひたすら実践で使ってみて本当の理論が
出来上がっていくのでしょう。
う〜ん、特に「ソフトウェアテスト293の鉄則」を“理想論”と片付けてしまう人は、
そもそものスキル及び向上心が、最低限の水準に達していない人だと思いますよ。

状況判断の基になる様々な考え方やノウハウが、こうした書籍には載っています。
もちろん理想論だけの書籍もありますが、
十把一絡げでくくるには余りにも勿体ない本だって沢山あります。

本を読んで「役に立たない」と嘆く前に、自分の理解力・応用力・実践力を嘆こう、
と、昔ある先輩に言われたことを思い出しました。
#半分は自戒ですね。 (^^;
Keyさん:

昔々学生の頃、まだ鼻っ柱が強いけど何も知らない若造だった頃に、
有名コンサル会社に勤めていた先輩にこう言ったんです。
「先輩、○○って本、大したこと言ってませんよね〜。」

その瞬間、先輩はこう言いました。
「それは、お前が○○を読めてないんだ。」

いや、顔中から火が出ました。今でも思い出すと汗が出ます。 (^^;

一般論として書けるほど、多くの本は理想論ではないと思いますよ。
現場を知れば知るほど、著者の血のにじむような知的努力によって、
個別の事例の集積を抽象化していることが行間から読めてくることがあります。
#本を読みながら「こいつ(著者)、すげぇ」とつぶやくこともあるくらいです。

僕はその先輩に言われた後、次のようなことを心がけてます。
  ・一般論として、理想論だけの本はあまり存在しない
  ・理想論だけだと思うときは、自分の知識や経験が足りないときだ
  ・その本からいかに多くの情報を読み取れるか、が自分の能力だ
   (何も読み取れないのは能力が低い証拠だ)
  ・もし理想論だと思うなら、具体的に理想論だと思う部分を挙げて批判してみよう

例えば僕の場合、ミューテーションテストを扱っている書籍は理想論だなぁ、と思っています。
それは、ミューテーションをしてテスト設計の評価をするくらいなら、
シーディングされるバグからテスト観点をリバースしてテスト設計をレビューした方が
何百倍も速いですし、フィードバックも容易ですし、何より構成管理のミスで
シーディングされたバグが出荷されることも無くなります。

でも、人によっては僕の意見に反論があるかもしれません。
こういう風に具体的に書いておけば、その反論を読んで
僕が思い直して主張を変える、すなわち僕が成長できるかもしれません。
そうすれば、ラッキーですよね。 (^_^)

とはいえ確かに、書籍を読むだけでは自分の現場の問題が解決できない
(と思われる)場合も多々ありますよね。
まずKeyさんが挙げたような本を隅から隅まで読んでみて(良い本ですよ、両方とも)、
分からない部分や、それでも解決できない自分の現場の問題を、
mixiのコミュやネットのコミュニティで相談してみればよいかな、と思います。
結構、みんな親身になって答えてくれます。本当に意外なくらい。 (^_^)

せっかく出会った本ですから、骨までしゃぶってあげましょうよ。
決して安くない本ですから、理想論なんて切り捨てちゃ、もったいないですよ〜♪
そういえば、情報処理学会誌の 2008年 2月号で「ソフトウェアテストの最新動向」って特集をやりますね。長らく見てきましたが、この手の特集は始めてではないかな。ようやくと言った感じでもありますが。ここの常連さんも記事を出しているのかな。
Webで、「テストリーダへの足がかり,最初の一歩」の連載が始まりました。
http://gihyo.jp/dev/serial/01/vital_point/0000

著者は、鈴木三紀夫さんと、池田暁さんです。
どんな内容になるのかなぁ。楽しみです!
 ちなみに、翔泳社さンの「JSTQB教科書」は、4月以降改版になるそうです。
 また、大西先生(豆蔵さン)監修によるDVDが発売になるとか。
Software Tesing "ManiaX" - vol.1 -
購入できました。

いやぁ、スゴイ人人人.....でした。
>panchoさン
 我輩なんざ、午前中はがっつりバカ本の売り子やってましたからー!
 加文字さンに我輩が売っていた本をお見せしたら、「はぁ…そぅですか」
状態でしたので。
はじめまして、あきぴーと申します。
ご存じの方は多いと思いますが、最近僕がいいと思っている本を紹介します。

http://www.amazon.co.jp/dp/4817193603
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際: 秋山 浩一: 本

恥ずかしながら、この本を読んで原因結果グラフの書き方が何となく分かってきました。
マイヤーの三角形を原因結果グラフで書いた図がありますが、結構複雑で、この技法を身に付けるにはかなりの練習が必要だなと感じています。

TEF関西でも輪読を始めました。

ログインすると、残り16件のコメントが見れるよ

mixiユーザー
ログインしてコメントしよう!

ソフトウェアの品質 更新情報

ソフトウェアの品質のメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。