単体テストを中心としたテストレベルの話
鈴木三紀夫 @mkoszk @kyon_mm TEFへの返信の前にツイートで。要求工学の基礎では要求のスコープというのが定義されています。ビジネス要求、システム要求、ソフトウェア要求がそれに当たります。これを僕は社内研修でずっと「要求のレベル」と読んでいたんです。テストレベルとの対比で言っていたんですね。 鈴木三紀夫 @mkoszk @kyon_mm 対比すると、受け入れテスト、システムテスト、単体／統合テストになるからです。でもね。それは要求のレベルじゃなくて、要求のスコープだと指摘されて、最初は何を言っているのか分からなかったんだな。だけど時間が経つにつれて分かる部分が増えてきたんだ。
「勝手にゆもつよメソッド勉強会」実施要領 - mkoszk’s blog
テストコンサルタントで有名な湯本剛さんのテスト分析・設計方法論、通称「ゆもつよメソッド」を湯本さん抜きで勉強会を開く方法を書きます。 事前準備 ソフトウェアテストPRESS Vol.10 ソフトウェアテストPRESS Vol.10を購入し、湯本さんの記事�「今こそ聞きたいテストの上流設計」を事前に読んできてください。勉強会ではたくさんの作業を行いますので、じっくり読み込む時間はありません。予め読んできてください。また、当日の作業でも使いますので持ってきてください。 PFD 余裕があれば「PFD(Process Flow Diagram)の書き方」第３版 [PDF] を読んでおいてください。当日、PFDを使います。ただし、必須ではありません。 文房具、用紙類 一人あたり次のものが必要です。 Ａ３用紙 最低２枚 ポストイット 653Y(38mm×50mm）ぐらい ２ブロック あまり大きすぎると
第三世代に突入したソフトウェアテスト
© NISHI, Yasuharu 第三世代に突入したソフトウェアテスト ソフトウェアテストシンポジウム四国 2010 2010/7/2（金） 電気通信大学 大学院 情報理工学研究科 総合情報学専攻 経営情報学コース 西 康晴 © NISHI, Yasuharu 2 自己紹介 • 身分 – ソフトウェア工学の研究者 » 電気通信大学 大学院 情報理工学研究科 総合情報学専攻 経営情報学コース » ちょっと「生臭い」研究／ソフトウェアテストやプロセス改善など – 先日までソフトウェアのよろず品質コンサルタント • 専門分野 – ソフトウェアテスト／プロジェクトマネジメント ／ＱＡ／ソフトウェア品質／ＴＱＭ全般／教育 • 共訳書 – 実践ソフトウェア・エンジニアリング／日科技連出版 – 基本から学ぶソフトウェアテスト／日経ＢＰ – ソフトウェアテスト293の鉄則／日経ＢＰ • もろもろ – T
逆引きソフトウェアテスト関連技術まとめ - >& STDOUT
「Software Test ＆ Quality Advent Calendar 2011」の8日目。アドベントカレンダーということで、普段と少しトーンを変えてソフトウェアテストにあまり造詣のない方へ向けて何か役に立つ記事を考えてみました。先の記事でも述べたとおり、ソフトウェアテストの関連技術を表す用語はそれが何に使えて、何に役立つのか、門外漢にはとってもわかり難いので、そちらを軸にした紹介があると便利かもしれないということで、関連技術を目的別に整理し、参考になる記事や資料にリンクする形でお届けします。 テストの戦略を定めたい ソフトウェアテストプロジェクトの最上流工程と考えられているテスト分析の方法論です。プロダクト、プロジェクトに対してそれぞれ独自の方式で戦略を検討します。テスト計画と一部被る部分もありますが、プロジェクトの予算やスケジュールをひとまずおいて技術的な視点から本当に必要な
The difference between QA, QC, and Test Engineering
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 風使いになりたい。 暑いときには扇風機がわりにできるし 寒いときは温かい空気を送ったりできるし、 刃物もカマイタチがあればいいし、走るときはいつも追い風だ。 そして何より「神風の術」が使える。スンバラシイ。 ども。コヤマンです。 なんだかドタバタしていたけれど、少し落ち着いてきたので考えていることなどを簡単に書き出してみる。 テストの視点の話。 大雑把な書き方なので何を言いたいのかよくわからないと思いますが、 僕がテストを考えるときに何を考えているのか、という"視点"を大雑把に出してみた。 モノ コト ドメイン(背景など、対象を取り巻く世界) こんだけ。んで、これって何かモノを作るときと全く同じだよなーと思った。 モノを作るとき、同じことを考える。 ※もちろんこれは僕の個人的意見に過ぎないので、異論はあるかと思う。 なるほど、テストを開発する、と考える
品質は作り込むもの - rabbit2goのブログ
ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善
欠陥を作らないための読書「ソフトウェアの欠陥予防」 - rabbit2goのブログ
「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに何らかの問題を抱えているからであり、その根本原因を突き止めて直す必要がある。 「ソフトウェアの欠陥予防」はそんな欠陥予防にフォーカスした書籍だ。著者は、ソフトウェア品質に対する取り組みとして「検出、分析、予防」の3つがあるものの、この中では検出に重点が置かれすぎている現状を指摘している。 多くの開発チームは、結果を防ぐことの必要性を認識し、欠陥を防ぐためのさまざまなテクニックを試みています。しかしこのようなテクニックのほとんどは、欠陥検出（テスト）の改善に焦点を合わせたもので、欠陥の予測や予防に焦点を合わせてものではありません。 既存の様々な方
プログラマーは自分のコードを疑え - 南極の図書館
若い頃にはよく陥る過ちだと思う。 最近やってしまったので自戒エントリ。 1.テストでバグ発見。 2.共通で使っている様々な計算をするクラスのメソッドから期待した値が戻ってこない。 3.どう考えてもこの（自分以外が作った）メソッドが業務上の例外を考慮してないだろ（履歴を見ると何度も問題があったモンスターメソッドだ）。 4.読み辛いながらも、そのメソッドのバグを探す。 5.どうもバグってないように見えるので、そのメソッドが使っている定数まで疑いだす（どんだけだよ。） 6.よく見たら私が書いたメソッドの呼び出し方が悪かった（結論） この歳になってこれはないよ。。。 でも「今更やってしまった」と実感できたのは良かった。 今後、バグを見つけたら、自分のコードを徹底的に疑う。 以下余談。 テストのコストが高いのがネックだと感じる。 数秒で終わるUTのコードがあればぐるぐるまわすんだけど、テストコードを
グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey
グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ グーグルで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
TestCocoon
TestCocoon is no more maintained and every user are invited to use now Squish Coco. Squish Coco is available for commercial and non-commercial projects. For commercial user froglogic GmbH provides also a professional support. Many enhancements come with this new product: Better support of C++0x by handling constant and lambda expressions. CoverageBrowser has now a more intuitive analysis of the te
技術的負債: 柴田 芳樹 (Yoshiki Shibata)
リーンソフトウェア開発と組織改革 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳出版社/メーカー: アスキー・メディアワークス発売日: 2010/10/09メディア: 単行本（ソフトカバー） 技術的負債 成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・ 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、
単体テスト～結合テスト - ソフトウェアテストの勉強室
単体テストをするとき、「スタブ」と「ドライバ」が必要になってくる。 スタブとは、テストのために用意されるテスト対象が呼び出す予定のメソッドや関数、サブルーチンのこと。ドライバは、テストのために用意されるテスト対象を読み出すメソッドや関数、サブルーチン。ひとつのテスト対象にはひとつずつスタブとドライバが必要になってくる。ただし、一般的には単体テストをトップダウンあるいはボトムアップで行うことが多いため、スタブとドライバの片方はすでにテスト実施済みのメソッドや関数、サブルーチンがあてられる。 そこでだ。世の中で結合テストといわれているのはどこを指すのか。 あくまで僕の認識だが、上図でいうと呼び出しa、呼び出しb、呼び出しcを「単体テストの通し」と考えている。この最上位の単体テストにたどり着くとそれはほとんどモジュールＡの機能テスト＝結合テストの一部とみなせるんじゃないか。 なんでこんなことを書
link集/開発補助ツール系 - NomisoBraaan Wiki
開発補助ツールに関するリンク集 link集/開発環境系 ※各種開発言語については link集/開発言語系 を参照方 ※一応、大雑把に開発工程(設計〜実装〜試験〜出荷)順に並んでます 各種ライセンスについては、下記ページも参照方。 link集/その他#license 関連ドキュメント Document/SourceForge.jp - SourceForge.jpの利用方法 Document/SourceForge.net - SourceForge.netの利用方法 プロジェクト管理 † ↑ 非商用 † Javaベース XPlanner / http://sf.net/projects/xplanner <LGPL> XPlanner is a web-based project planning and tracking tool for agile development teams
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
swtest.jp/wiki - PukiWiki
http://jstqb.web.fc2.com/
「レガシーコード」との付き合い方
はにわ３ ホームページ
CESL -CATS Embedded Software Laboratory- キャッツ組込みソフトウェア研究所