鈴木三紀夫 @mkoszk @kyon_mm TEFへの返信の前にツイートで。要求工学の基礎では要求のスコープというのが定義されています。ビジネス要求、システム要求、ソフトウェア要求がそれに当たります。これを僕は社内研修でずっと「要求のレベル」と読んでいたんです。テストレベルとの対比で言っていたんですね。 2012-01-03 02:31:09 鈴木三紀夫 @mkoszk @kyon_mm 対比すると、受け入れテスト、システムテスト、単体／統合テストになるからです。でもね。それは要求のレベルじゃなくて、要求のスコープだと指摘されて、最初は何を言っているのか分からなかったんだな。だけど時間が経つにつれて分かる部分が増えてきたんだ。 2012-01-03 02:33:33

テストコンサルタントで有名な湯本剛さんのテスト分析・設計方法論、通称「ゆもつよメソッド」を湯本さん抜きで勉強会を開く方法を書きます。 事前準備 ソフトウェアテストPRESS Vol.10 ソフトウェアテストPRESS Vol.10を購入し、湯本さんの記事�「今こそ聞きたいテストの上流設計」を事前に読んできてください。勉強会ではたくさんの作業を行いますので、じっくり読み込む時間はありません。予め読んできてください。また、当日の作業でも使いますので持ってきてください。 PFD 余裕があれば「PFD(Process Flow Diagram)の書き方」第３版 [PDF] を読んでおいてください。当日、PFDを使います。ただし、必須ではありません。 文房具、用紙類 一人あたり次のものが必要です。 Ａ３用紙　最低２枚 ポストイット 653Y(38mm×50mm）ぐらい　２ブロック あまり大きすぎると

「Software Test ＆ Quality Advent Calendar 2011」の8日目。アドベントカレンダーということで、普段と少しトーンを変えてソフトウェアテストにあまり造詣のない方へ向けて何か役に立つ記事を考えてみました。先の記事でも述べたとおり、ソフトウェアテストの関連技術を表す用語はそれが何に使えて、何に役立つのか、門外漢にはとってもわかり難いので、そちらを軸にした紹介があると便利かもしれないということで、関連技術を目的別に整理し、参考になる記事や資料にリンクする形でお届けします。 テストの戦略を定めたい ソフトウェアテストプロジェクトの最上流工程と考えられているテスト分析の方法論です。プロダクト、プロジェクトに対してそれぞれ独自の方式で戦略を検討します。テスト計画と一部被る部分もありますが、プロジェクトの予算やスケジュールをひとまずおいて技術的な視点から本当に必要な

I love your description of the different roles...right now I work for a small group of a large company...I am a fiarly new employee and up until now the test process has been almost exclusively QC and manual...I am starting to work with developers to implement some automated tests to free test personnel to do more exploratory testing...it's quite the adventure! ReplyDelete Test Engineering method

組み込み機器向けソフトウエアの規模が指数関数的に増えている。ハードウエアの開発工数を上回るケースも少なくない。特に携帯電話機では，ハードウエア開発の10倍近くをソフトウエア開発に要する。これまでは，家内手工業的な手法によって自転車操業的にソフトウエアを開発することがほとんどだったが，最近はソフトウエア開発に対する意識改革が進み始めた。ソフトウエア規模の増大に対応すべく，先進的なソフトウエア開発方法論を取り入れる先進企業が現れている。「ケータイ」「デジタル家電」「クルマ」などの先進事例を取り上げながら，上流設計から下流のテスト・検証工程に至るまで，組み込みソフトウエア開発の現状を浮き彫りにする。「プラットフォーム型開発」「オープンソース」，「オフショア開発」「モデル・ベース開発」「テスト」そして「理工系離れ」などをキーワードに，パネリストが各現場の工夫点を紹介すると同時に，今後のソフトウエア

-ちょっと修正：2011/10/18 風使いになりたい。 暑いときには扇風機がわりにできるし 寒いときは温かい空気を送ったりできるし、 刃物もカマイタチがあればいいし、走るときはいつも追い風だ。 そして何より「神風の術」が使える。スンバラシイ。 ども。コヤマンです。 なんだかドタバタしていたけれど、少し落ち着いてきたので考えていることなどを簡単に書き出してみる。 テストの視点の話。 大雑把な書き方なので何を言いたいのかよくわからないと思いますが、 僕がテストを考えるときに何を考えているのか、という"視点"を大雑把に出してみた。 モノ コト ドメイン(背景など、対象を取り巻く世界) こんだけ。んで、これって何かモノを作るときと全く同じだよなーと思った。 モノを作るとき、同じことを考える。 ※もちろんこれは僕の個人的意見に過ぎないので、異論はあるかと思う。 なるほど、テストを開発する、と考える

ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善

「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに何らかの問題を抱えているからであり、その根本原因を突き止めて直す必要がある。 「ソフトウェアの欠陥予防」はそんな欠陥予防にフォーカスした書籍だ。著者は、ソフトウェア品質に対する取り組みとして「検出、分析、予防」の3つがあるものの、この中では検出に重点が置かれすぎている現状を指摘している。 多くの開発チームは、結果を防ぐことの必要性を認識し、欠陥を防ぐためのさまざまなテクニックを試みています。しかしこのようなテクニックのほとんどは、欠陥検出（テスト）の改善に焦点を合わせたもので、欠陥の予測や予防に焦点を合わせてものではありません。 既存の様々な方

若い頃にはよく陥る過ちだと思う。 最近やってしまったので自戒エントリ。 1.テストでバグ発見。 2.共通で使っている様々な計算をするクラスのメソッドから期待した値が戻ってこない。 3.どう考えてもこの（自分以外が作った）メソッドが業務上の例外を考慮してないだろ（履歴を見ると何度も問題があったモンスターメソッドだ）。 4.読み辛いながらも、そのメソッドのバグを探す。 5.どうもバグってないように見えるので、そのメソッドが使っている定数まで疑いだす（どんだけだよ。） 6.よく見たら私が書いたメソッドの呼び出し方が悪かった（結論） この歳になってこれはないよ。。。 でも「今更やってしまった」と実感できたのは良かった。 今後、バグを見つけたら、自分のコードを徹底的に疑う。 以下余談。 テストのコストが高いのがネックだと感じる。 数秒で終わるUTのコードがあればぐるぐるまわすんだけど、テストコードを

QA(Quality Assurance)関連の仕事がこれまで一番長く、得意分野は主にテスト方面です。開発エンジニアとしてはまだまだ新米なのですが、プロダクトを「外から」テストしてきたQA経験を活かして、今はユニットテストなどプロダクトの品質を「内から」高めていこう、としているところです。(ちなみに、テストツールとしては Selenium をそれなりに使ってきたりもしたので、そのあたりのネタもいずれこの場で書くことがあるかもしれません。もしリクエストあらばぜひ。。)

グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ グーグルでTest Engineering Directorを務めるJames A Whittaker氏が、ブログ「Google Testing Blog」に書いているグーグル社内のソフトウェア品質に関するノウハウ。最近の記事「How Google Tests Software - Part Four」「How Google Tests Software - Part Five」では、ビルドの種類とテストの種類について紹介しています。 One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to sh

リーンソフトウェア開発と組織改革 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳出版社/メーカー: アスキー・メディアワークス発売日: 2010/10/09メディア: 単行本（ソフトカバー） 技術的負債 成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・ 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、

単体テストをするとき、「スタブ」と「ドライバ」が必要になってくる。 スタブとは、テストのために用意されるテスト対象が呼び出す予定のメソッドや関数、サブルーチンのこと。ドライバは、テストのために用意されるテスト対象を読み出すメソッドや関数、サブルーチン。ひとつのテスト対象にはひとつずつスタブとドライバが必要になってくる。ただし、一般的には単体テストをトップダウンあるいはボトムアップで行うことが多いため、スタブとドライバの片方はすでにテスト実施済みのメソッドや関数、サブルーチンがあてられる。 そこでだ。世の中で結合テストといわれているのはどこを指すのか。 あくまで僕の認識だが、上図でいうと呼び出しa、呼び出しb、呼び出しcを「単体テストの通し」と考えている。この最上位の単体テストにたどり着くとそれはほとんどモジュールＡの機能テスト＝結合テストの一部とみなせるんじゃないか。 なんでこんなことを書