*テスト関連の記事に関するページ [#u72d3d7d]

#contents

//-----------------------------------------------------------------------------
**記事(Wiki化以前) [#jd56a7fa]
-[[記事(Wiki化以前)>swtest.jp/wiki/readings/articles/old]]のページに記載されています。


//-----------------------------------------------------------------------------
**blog / Web サイト [#hf951305]


-Software Quality.com
--http://sw-quality.com/

-HAYST法
--http://hayst.com/

-知識ゼロから学ぶ ソフトウェアテスト
--http://juichi.blog.so-net.ne.jp/

-たまゆら雑記
--http://blog.goo.ne.jp/mickey_suzuki

-ソフトウェアテストの勉強室
--http://softest.cocolog-nifty.com/blog/

-ソフトウェアテスト技術者を元気にしたい!ブログ
--http://softwaretest.blog87.fc2.com/

-つれづれなる技術屋日記
--http://blog-honda.cocolog-nifty.com/gijyutuya_nikki/

-クライングドーベルマン / ソフトウェアテスト
--http://www.snowballdesign.com/sugi/cat_e382bde38395e38388e382a6e382a7e382a2e38386e382b9e38388.html

-KGussan Webpage / ソフトウェアテスト
--http://kgussan.ojaru.jp/software-test.html

-吉田誠一のホームページ / ソフトウェア工学 / 技術コラム
--http://www.aerith.net/design/development-j.html

-IT 技術情報 整理サイト / ソフトウェアテスト
--http://ittechinf.wiki.zoho.com/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88.html

-気の向くままにプログラミング
--http://homepage3.nifty.com/kaku-chan/
--論考:品質と生産性
---http://homepage3.nifty.com/kaku-chan/q_and_p/
--識者の視点に学ぶ
---http://homepage3.nifty.com/kaku-chan/viewpoint/


//-----------------------------------------------------------------------------
**記事(Wiki化以後) [#te593f04]

-私たちの活動はこうして始まった
--TestLink日本語化部会
--2007/7/14
--gihyo.jp / DEVELOPER STAGE / テストエンジニアのコミュニティ活動のススメ
--http://gihyo.jp/dev/serial/01/te_community/0001
--(引用)本連載では,このTestLink日本語化部会のメンバーが分担して,ソフトウェアテストエンジニアのコミュニティ活動についてご紹介します。初回である今回は,そもそもTestLinkとは何かということや,部会発足の経緯などについてご紹介していきたいと思います。


-継続的テスト
--松野 徳大
--2008/7/14
--gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
--http://gihyo.jp/dev/feature/01/test-perl/0005
--(引用)今回は継続的なテストという話題についてお話したいと思います。本稿では,少人数のチームによるWebサイト開発というケースにフォーカスして論じていきます。本稿で取り上げる継続的テストとは,端的にいえば「自動でテストを定時実行させる」ということです。 make testするのをうっかり忘れたりしていませんか? テストを動かすのを面倒がってテスト動かさずにコミットしていませんか? そして,そのままデプロイしたりしていませんか?


-キャプチャ/リプレイツールによる機能テストの自動化
--町田 欣史
--2008/7/14
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0007
--(引用)Webブラウザを操作する機能テストは,何度も繰り返し行うのは大変な作業になりますので,回帰テストをする際にはツールによる自動化が効果的です。そこで今回は機能テストを自動化するツールについて紹介します。


-コピー&ペーストでテスト仕様書を作っていませんか?
--鈴木 三紀夫, 池田 暁
--2008/7/14
--gihyo.jp / DEVELOPER STAGE / 新人注目! テストを極める最初の一歩
--http://gihyo.jp/dev/serial/01/test_newface/0003
--(引用)過去の成果物を活用して仕事を早く終わらせることは大切です。しかし,新人の皆さんにとって,今は基礎を固めるという大事な時期でもあります。基礎固めをおろそかにしてしまうと後々つらい目に遭ってしまいます。テストにおける基礎固めとはテスト設計です。テストにも「設計」があります。新人の皆さんが第一に覚えて,身に付けなければならないことは,テスト設計なのです。第3回は,仕様書の読み解き方と,テスト設計の初歩について説明します。


-「懐石料理」でインドの「スパイス」をうまく使う方法
--山浦 恒央
--2008/7/11
--@IT / MONOist / 組み込み開発/ 山浦恒央の“くみこみ”な話
--http://monoist.atmarkit.co.jp/fembedded/articles/kumikomi/01/kumikomi01.html
--(引用)インドと日本には、「ソフトウェア開発での優先順位」「ソフトウェアの開発方式」「国民気質」という3つの点で大きな相違があります。これを考慮しないで、インド発注をすると、極上のヒラメの刺身にカレー粉をまぶして食べるような悲劇が起きます。連載第1回となる今回は、上記の「3つの違い」をベースに、“日本方式の品質管理プロセスを、なぜインドで実行してくれないのか?”を分析します。


-PMP──Project Management Professional
--正木 威寛
--2008/7/4
--gihyo.jp / DEVELOPER STAGE / これだけはとっておきたい「テスト技術者」の資格
--http://gihyo.jp/dev/serial/01/se_skilup/0003
--(引用)第3回は,プロジェクトマネジメントの資格試験である「PMP」をご紹介します。


-Webアプリケーションのテスト
--町田 欣史
--2008/7/4
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0006
--(引用)今回は,皆さんがユーザとして活用しているWebアプリケーションを対象に,統合テストやシステムテストで実施するテスト内容について紹介し,中でもアプリケーションの「機能」に着目したテストの観点について掘り下げて紹介します。


-やみくもにテストをしていませんか?
--鈴木 三紀夫, 池田 暁
--2008/7/4
--gihyo.jp / DEVELOPER STAGE / 新人注目! テストを極める最初の一歩
--http://gihyo.jp/dev/serial/01/test_newface/0002
--(引用)頭を使わずやみくもに手を動かすテストが必要な局面というのはあります。しかし,新人でその局面に遭遇するケースというのはあまり無いでしょう。やみくもなテストではなく,やらなくてはいけないテストを任されることが多いはずです。第2回は,この「やみくもなテスト」の問題点と「やるべきテスト」との違いを説明します。


-アジャイルとシステムテストの新たな関係(後編)
--Mary Ellen Kerr, Curt J. Rousse, Donna P. Dynes, Dave Booz
--2008/7/1
--@IT / 情報マネジメント / アーキテクチャ / The Rational Edge
--http://www.atmarkit.co.jp/im/carc/serial/redge/74/01.html
--(引用)前回は、アジャイル開発プロセスにシステムテストのサブセットを含めた経緯、作業の経過、および結果としてうまくいった点について解説した。今回は、逆に今後の課題として残った点と、開発以外のプロセスに与えたメリットについて説明する。


-テスト環境の構築に使用できる仮想ツールにはどのようなものがあるのか?
--Scott Lowe
--2008/6/25
--ZDNet Japan / builder
--http://builder.japan.zdnet.com/news/story/0,3800079086,20375948,00.htm
--(引用)本番環境のレプリケーションなしにテストを行うことも可能ではあるものの、レプリケートした環境でテストを行う方がはるかに正確かつ的を射た結果を得ることができるはずである。前回の記事ではVMware ESXとPlateSpinのPowerConvertを主に採り上げたが、テスト(デスクトップレベルのみでのテストであったとしても)に役立つツールは他にも数多く存在している。本記事では、テスト目標を達成するために使用できる無償あるいは安価なツールを紹介している。


-Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介
--小林 篤
--2008/6/25
--gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
--http://gihyo.jp/dev/feature/01/test-perl/0004
--(引用)今回は今までに紹介しきれなかったPerlのTestingモジュールで良く利用されるものをいくつか紹介したいと思います。


-アジャイルとシステムテストの新たな関係(前編)
--Mary Ellen Kerr, Curt J. Rousse, Donna P. Dynes, Dave Booz
--2008/6/24
--@IT / 情報マネジメント / アーキテクチャ / The Rational Edge
--http://www.atmarkit.co.jp/im/carc/serial/redge/73/01.html
--(引用)自社製品の品質改善とタイムリーなリリースを行う手段の1つとして、多くの企業がアジャイル開発手法の採用を進めている。どの会社やチームも、アジャイル開発環境においてシステムテスト戦略を最良の形で実行に移す方法を見つけたいと考えている。(略)本稿は、あるチームがわれわれのアジャイル開発環境の一環として、コード開発と並行してシステムテストの一部を含める際に取ったアプローチを解説する。


-ITIL version3ファウンデーション
--正木 威寛
--2008/6/24
--gihyo.jp / DEVELOPER STAGE / これだけはとっておきたい「テスト技術者」の資格
--http://gihyo.jp/dev/serial/01/se_skilup/0002
--(引用)第2回は,日本でも資格試験が先日始まったばかりの「ITIL version3 ファウンデーション」をご紹介します。


-単体テスト
--加藤 智巳, 町田 欣史
--2008/6/24
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0005
--(引用)今回は,テスト工程の1つである単体テストにフォーカスを当てます。前回,前々回ではテストケースを作成する技法を見てきましたが,そこで作ったテストケースをどのように実行するかという観点で,単体テストの基本的な進め方と,ツールを用いた単体テストの実行方法について解説していきます。


-最初の仕事にとまどっていませんか?
--鈴木 三紀夫, 池田 暁
--2008/6/24
--gihyo.jp / DEVELOPER STAGE / 新人注目! テストを極める最初の一歩
--http://gihyo.jp/dev/serial/01/test_newface/0001
--(引用)国内の開発現場においては,新人の現場配属時の最初の仕事として,テストのお手伝いを指示されることが多いようです。プログラムが書けると思って期待していたらテストの手伝いだったため,勝手が違ってしまい仕事のミスをしてしまう人もいます。この最初の仕事で大きなミスをしてしまうと職場からの印象が悪くなってしまい,将来やりたかった仕事にまで影響してしまうかもしれません。そんなことにならないように,第1回は,新人がおろそかにしがちな準備・確認事項・心構えについて,最低限押さえなければならないポイントを解説していきます。


-会社のシステムインフラをテスト環境にレプリケートする方法
--Scott Lowe
--2008/6/23
--ZDNet Japan / builder
--http://builder.japan.zdnet.com/news/story/0,3800079086,20375780,00.htm
--(引用)本番環境をテスト環境にレプリケートする方法について考察するとともに、筆者お勧めのツールを紹介する。


-Test::Declareの紹介
--小林 篤
--2008/6/18
--gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
--http://gihyo.jp/dev/feature/01/test-perl/0003
--(引用)今回は私が開発したPerlモジュールのTest::Declareについて紹介します。Test::Declareには,以下の特徴があります。・テストコードをDSL風に(宣言的に)書く事を重点に置いている。・それによりテストコード自体の見やすさを向上させることができる。・宣言的にテストを書く事により,一体なにを目的としたテストなのかがわかりやすくなる。


-JSTQBテスト技術者資格認定
--正木 威寛
--2008/6/13
--gihyo.jp / DEVELOPER STAGE / これだけはとっておきたい「テスト技術者」の資格
--http://gihyo.jp/dev/serial/01/se_skilup/0001
--(引用)本連載では,テスト技術者やテストに関係するSEのスキルアップに役立つ資格を紹介していきます。まず第1回目にご紹介するのは,ズバリ“テスト技術者”のための資格「JSTQB認定テスト技術者資格 Foundation」です。


-ブラックボックステスト
--田代 裕和, 町田 欣史
--2008/6/13
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0004
--(引用)今回は,前回(第3回)のホワイトボックステストに続き,もう1つの代表的なテストケース作成技法「ブラックボックステスト」について紹介します。


-Test::Baseの紹介
--伏原 幹
--2008/6/11
--gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
--http://gihyo.jp/dev/feature/01/test-perl/0002
--(引用)今回Test::Baseというモジュールを紹介させてもらいます。Test::Baseは,Kwikiなどの作者として知られるIngy döt Net氏が作成した“Data Driven Testing Framework(データ駆動型テストフレームワーク)”です。


-「バッファ込み」の工数がスケジュール遅延の原因
--新楽 清高
--2008/6/4
--@IT / 自分戦略研究所 / スキル創造研究室 / システム開発プロジェクトの現場から
--http://jibun.atmarkit.co.jp/lskill01/rensai/pgenba15/pgenba01.html
--(引用)最初に立てたスケジュールどおりにプロジェクトが進行せず、だんだんと遅れていく……。そんな経験はありませんか?今回は、すでに稼働しているシステムへの機能(サブシステム)追加開発プロジェクトでの経験を基に、プロジェクトのスケジュール管理の難しさについてお話しします。(略)プロジェクトは開発・単体テストくらいまではさほど問題なく進んでいきました。しかし、最初の分類の結合テストを開始したころから、徐々に遅れが出始めました。遅延理由の代表的なものは、「イレギュラーケースに対応できていなかった」「想定する必要がないケースのテストを実施していた」などです。


-Perlにおけるテストの概要/TAPとは?
--松野 徳大
--2008/6/4
--gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
--http://gihyo.jp/dev/feature/01/test-perl/0001
--(引用)今回から数回にわたって,Perl におけるテスト手法についてリレー形式で詳細に解説していきたいとおもいます。今回は初回ですので,ざっくりと概論になります。


-ホワイトボックステスト
--木村 聡宏
--2008/6/4
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0003
--(引用)連載の第3回目となる今回は,テストケース作成技法の1つ,ホワイトボックステストについて取り上げます。


-WindowsアプリのUIテストを自動化しよう
--亀野 弘嗣
--2008/6/3
--@IT / Insider.NET / UIオートメーションによる自動UIテストの実践
--http://www.atmarkit.co.jp/fdotnet/special/uiautomation/uiautomation_01.html
--(引用)読者の方々は、UI(ユーザー・インターフェイス)にかかわるテスト(以下UIテスト)を自動化できているだろうか? UIテストを自動化しようとしても、UIテストのコードは記述しにくく、記述方法に一貫性がない、などの理由から、自動化をあきらめる場合が多いのではないだろうか。.NETの開発においても単体テストの自動化は一般的に行われるようになってきているものの、UIテストの自動化はそういった理由で実現が難しく、あまり行われていないのが現状だ。そこで本稿では、標準的で一貫性のある記述ができるMicrosoft UIオートメーション(以下UIオートメーション。詳細後述)と、テスト・ツールであるNUnitを使用して、UIテストを自動化する方法を紹介する


-開発者のためのスケーラビリティテストとゴールテスト
--Michael Ault
--2008/5/23
--CodeZine / ツール / テスト
--http://codezine.jp/a/article/aid/2494.aspx
--(引用)多くの場合、開発者はコードを記述するだけでなく、コードがアプリケーション環境で適切なスケーラビリティを持ち、適切に動作することを保証しなければなりません。本稿では、スケーラビリティテストとゴールテストの違いを取り上げ、手動テスト向けの擬似コードテストハーネスの例を紹介し、実際にQuest SoftwareのToadという自動テストインターフェイスを使用してOracleプロシージャのテストを行う例を示します。


-静的テスト
--池田 俊, 町田 欣史
--2008/5/23
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0002
--(引用)ソフトウェアテストのテクニックについて紹介する本連載です(略)今回は静的テストについて紹介します。


-ソフトウェアテストを分類する
--町田 欣史
--2008/5/13
--gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
--http://gihyo.jp/dev/serial/01/tech_station/0001
--(引用)今回からソフトウェアテストに関するテクニックについて連載していきます。ただ,一口にソフトウェアテストといっても,非常に幅広いものです。そこで,ソフトウェアテストを分類,整理した上で,そのうちの主なテストの種類について取り上げていきたいと思います。そこで今回は,まずソフトウェアテストの分類について解説していきます。


-Spring Frameworkによるソフトウェアテスト
--Srini & Kavitha Penchikala
--2008/4/8
--InfoQ
--http://www.infoq.com/jp/articles/testing-in-spring
--(引用)ソフトウェアテストを開発プロセスに統合する強力なサポートを提供するよう、徹底的に構築されたJ2EEフレームワークがいくつかある。Springは、そのようなjavaエンタープライズアプリケーション開発フレームワークの1つである。(略)この記事では、単体/統合テストの分野でSpringフレームワークが提供するサポートの概要について説明する。一般的なJava EEアプリケーションでのアジャイルテスティングフレームワークの実装と、Springテストクラスを使用したアプリケーション機能のテスト方法について、読者の方の参考となるように、ローン処理のWebアプリケーションの例を取りあげる。


-人手を介さない自動負荷テスト
--Paul Duvall
--2008/4/8
--developerWorks Japan / Java technology / 万人のためのオートメーション
--http://www.ibm.com/developerworks/jp/java/library/j-ap04088/?ca=dnj-0530
--(引用)大抵の場合、負荷テストはサイクルの後のほうに追いやられてしまいますが、この作業を後回しにする必要はありません。(略)オートメーションのエキスパートである Paul Duvall が開発サイクル全体を通して問題を見つけ、修正する方法を説明します。その方法とは、JMeter テストを実行する定期インテグレーション・ビルドを作成することです。


-2007年のお勧めソフトウェアテスト本リスト 
--やまもと@テスト番長
--2007/12/27
--ウノウラボ
--http://labs.unoh.net/2007/12/2007_1.html
--(引用)今年発売のテスト関連書籍の中から、お勧めを独断と偏見でピックアップしてみました。ご参考になれば幸いです。


-第6回 PICTをより使いやすくする
--鶴巻 敏郎
--2007/12/19
--gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに!
--http://gihyo.jp/dev/feature/01/sp-test/0006
--(前回からの引用)PICTの柔軟性をさらに高めるテストケースの作成支援機能も備えた,Excel上で動作するテストケース作成支援ツールを詳しく紹介します。 


-ソフトウェアテストと開発のこれから
--古川 善吾
--2007/12/21
--developerWorks Japan / developerにもテストを
--http://www.ibm.com/developerworks/jp/offers/jasst/library/softwaretest05/
--(引用)今回は、ソフトウェアテストおよび開発の今後について述べてみたいと思います。


-第5回 PICTの機能説明と使用例 (後編)
--鶴巻 敏郎
--2007/12/12
--gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに!
--http://gihyo.jp/dev/feature/01/sp-test/0005
--(引用)PICTの使いやすさがおわかりいただけたでしょうか。同様なことを直交表ベースで行おうとすると,専用のソフトウェアを自力で開発しなければ不可能だと思われる機能がほとんどです。人手でもやれる機能もありますが,その場合でもPICTに比べてはるかに時間がかかってしまいます。 


-オープンソースツール
--加藤 大受
--2007/12/7
--developerWorks Japan / developerにもテストを
--http://www.ibm.com/developerworks/jp/offers/jasst/library/softwaretest03/
--(引用)非常に数多くのテストツールがオープンソースで開発されています。(略)この記事はこれらのオープンソースのテストツールを利用し、テストを効率よく実施することについて考えてみましょう。


-第4回 PICTの機能説明と使用例 (中編)
--鶴巻 敏郎
--2007/12/5
--gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに!
--http://gihyo.jp/dev/feature/01/sp-test/0004
--(引用)PICTでは,モデルオプションとしてさまざまな機能を提供しています。今回と次回に分けて詳しく解説していきます。 


-第10回 テスト方法−−品質とコストに大きく影響するテスト方法を決める
--布川 薫
--2007/12/3
--IT Pro / ビジネスSkillUP / プロジェクトマネジメントの理論と実践
--http://itpro.nikkeibp.co.jp/article/COLUMN/20071026/285596/?ST=bizskill
--(引用)テストを実施するに当たっては,各モジュールを結合してコンポーネントに集積していく方法やテストケースの設定方法,テストの網羅性の基準といったテスト方法を事前に決定しておかなければならない。品質とコストのバランスを取りながら最も効率的なテスト方法を決定するべきだ。


-テスト技術者の資格試験(JSTQB)
--大西 建児
--2007/11/30
--developerWorks Japan / developerにもテストを
--http://www.ibm.com/developerworks/jp/offers/jasst/library/softwaretest04/
--(引用)第4回は「テスト技術者の資格試験(JSTQB)」というタイトルで、ソフトウェアテスト(以下テストと記します)を冠した国際的な資格であるISTQBの概要説明を通してテストに必要なスキルについて解説していきます。


-第3回 PICTの機能説明と使用例 (前編)
--鶴巻 敏郎
--2007/11/28
--gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに!
--http://gihyo.jp/dev/feature/01/sp-test/0003
--(前回からの引用)具体例を用いてPICTの詳しい機能説明を行います。 


-第9回 テスト範囲を最適に決める:本番リリースは開発者以外が行う 
--森山 徹
--2007/11/22
--IT Pro / 情報システム / ソフトウェア改造力
--http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286261/?ST=system
--(引用)改造作業の締めくくりは,本番環境にプログラムをリリースすること。リリースする際は,テスト結果などから“リリース判定”を事前に行うことが一般的だ。(略)本番へのリリース作業で大切なことは,テスト環境と本番環境にアクセスできる権限をきちんと分けておくこと。開発者が本番環境に勝手にアクセスできるような環境では,第2回で紹介したトラブルが発生しかねない。


-第2回 PICTの基本的な使い方
--鶴巻 敏郎
--2007/11/21
--gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに!
--http://gihyo.jp/dev/feature/01/sp-test/0002
--(引用)PICT(Pairwise Independent Combinatorial Testing tool)はMicrosoft社が開発したソフトウェアテストツールです。Microsoftでは2000年からこのツールをテスト業務に使用しています。ツール開発者はPICTが備えている柔軟性のおかげでテスト担当者がテスト対象を抽象化し,モデル化するレベルを向上させ,組み合わせテストが実施しやすくなったと述べています。PICTは,複数のパラメータの組み合わせテストケースを,オールペア法(ペアワイズ法ともいう)を用いて自動生成します。(略)PICTはフリーソフトウェアです。(略)今回はPICTの基本的な使い方を説明するとともに,日本語を扱えるようにする方法についても説明します。


-第8回 テスト範囲を最適に決める:シナリオや環境整備でテストを効率化する
--森山 徹
--2007/11/21
--IT Pro / 情報システム / ソフトウェア改造力
--http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286281/?ST=system
--(引用)テスト漏れを防ごうとすれば,おのずからテスト範囲は広がり,それに引きずられてテスト時間も長くなる。(略)テストを効率化する方法の一つに,自動機能テスト・ツールの利用が挙げられる。(略)改造時のテストでは,サーバーやテスト・データといった「環境」がきちんと整備されているかも,テストの品質や効率を左右するポイントだ。開発のための「開発環境」に加えて,「検証環境」が用意できれば,本番さながらのテストを実行しやすい。


-第1回 組み合わせテストの技法
--鶴巻 敏郎
--2007/11/14
--gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに!
--http://gihyo.jp/dev/feature/01/sp-test/0001
--(引用)この特集では,ソフトウェアの組み合わせテストについての技法である「オールペア法」と,オールペア法を採用したテストケース作成ツール「PICT」の機能,およびその効果的な使い方を,多くの例を用いて解説していきます。(略)ソフトウェアはさまざまな因子(パラメータ)の組み合わせにより,その挙動が違ってきます。これらパラメータの組み合わせを総当りで行うことはテスト件数の爆発を招き,実際に行うのは多くの場合,不可能です。(略)こうした課題を解決するために考え出された効率的な組み合わせテスト技法は,大規模,複雑化するソフトウェアの組み合わせテスト件数を大幅に削減することが可能な技法です。この技法には,直交表と,オールペア法の2つがあります。


-第7回 テスト範囲を最適に決める:過去のテスト項目集めて漏れを減らす  
--森山 徹
--2007/11/13
--IT Pro / 情報システム / ソフトウェア改造力
--http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286280/?ST=system
--(引用)難しいのは,改造の影響をどこまで見越してテスト範囲に織り込むかだ。その範囲が狭すぎればバグを取り逃がしてしまう。反対に広すぎると,手間がかさんでしまう。(略)以下では,(1)適切なテスト範囲を押さえる,(2)テストを効率化する,(3)安全に本番リリース(移行)する――の三つの作業を通じてテストから本番リリースまでのポイントを解説する。


-第2回 ソフトウエア改造力が足りない:工数膨らませる影響調査と確認テスト 
--森山 徹
--2007/11/13
--IT Pro / 情報システム / ソフトウェア改造力
--http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286259/?ST=system
--(引用)改造ならではの難しさとは,「既存システムへの影響調査」と「“他に影響がない”ことを確認するテスト」の二つに集約できる。(略)「テストにより現行機能を保証する必要があることが新規開発との違い。新規に比べてテスト時間は長くなる」(略)「新機能がきちんと動くことを確かめる“オモテ”のテストと,これまで動いてきた機能に影響が無いことを証明する“ウラ”のテストが必要。ウラのテストをやっていないときに限って,後からトラブルになる。テスト・パターンが膨大なので,これをいかに効率化するかが課題だ」。


-ツールを駆使したテスト
--湯本 剛
--2007/11/9
--developerWorks Japan / developerにもテストを
--http://www.ibm.com/developerworks/jp/offers/jasst/library/softwaretest02/
--(引用)第2回は「ツールを駆使したテスト」というタイトルで、ソフトウェアテストを支援するツールと、使い方のコツについて触れていきたいと思います。


-ソフトウェアテストのスタンダード
--増田 聡
--2007/11/2
--developerWorks Japan / developerにもテストを
--http://www.ibm.com/developerworks/jp/offers/jasst/library/softwaretest01/
--(引用)テストの基本的な知識体系や技法、規格や標準について簡単に説明します。


-第9回 テスト計画−−品質管理方針を基にプロジェクト全体のテスト計画を作成する 
--布川 薫
--2007/11/1
--IT Pro / ビジネスSkillUP / プロジェクトマネジメントの理論と実践
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070920/282591/?ST=bizskill
--(引用)品質のトラッキング/コントロールで大きな役割を果たすのはテスト・フェーズである。このフェーズを効率的に実施するためには,しっかりとした「テスト計画」を立案しておく必要がある。特に,テストの開始・完了基準をきちんと計画しておくことは,テストの進ちょくやコスト管理の観点からもきわめて重要だ。


-第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む 
--布川 薫
--2007/10/1
--IT Pro / ビジネスSkillUP / プロジェクトマネジメントの理論と実践
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070910/281567/?ST=bizskill
--(引用)「ウォークスルー」と「インスペクション」は,システム開発の早い段階で欠陥を発見・除去するための方法である。開発者自身やチーム内の「モデレータ」と呼ばれる調整役が自主的に運営することが特徴だ。今回は,品質向上に欠かせないウォークスルーとインスペクションの具体的な実施手順を解説する。


-[テスト編]テストを開発者任せにしてはいけない
--作者不詳
--2007/9/25
--IT Pro / 情報システム / ITエンジニアの「やってはいけない」
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070820/279837/?ST=system
--(引用)開発した本人にテストを任せると,「動くはず」という過信から,どうしてもチェックが甘くなる。このため,テストは決して開発者任せにしてはいけない。特にオフショア開発の場合には,「正常系はテストしても,異常系は全くテストしていないなど,とんでもないプログラムが納品されることがある」。


-[テスト編]すべての結合テストを自動化してはいけない
--池上 俊也
--2007/9/21
--IT Pro / 情報システム / ITエンジニアの「やってはいけない」
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070820/279936/?ST=system
--(引用)システムの複雑化や頻発する仕様変更に伴う回帰テストなどによって,その工数は膨らむ一方だ。そのためシステム開発の現場では,結合テスト・ツールを使って,テスト作業を効率化する動きが広がっている。ところが,ツールを導入したにもかかわらず「ツールの投資コストが回収できない」「逆にテスト工数が増加した」という声が相次いでいる。


-[テスト編]本番環境でいきなりテストしてはいけない
--作者不詳
--2007/9/20
--IT Pro / 情報システム / ITエンジニアの「やってはいけない」
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070820/279935/?ST=system
--(引用)開発したばかりのプログラムは,誤作動する危険がある。ほかのプログラムに悪影響を及ぼしたり,データやファイルを破壊したりすることもある。OSやミドルウエアのベンダーが提供するセキュリティ・パッチのように,ベンダーがテストしてリリースしている場合でも,個別の環境では動作しなかったり,思わぬ悪影響が出たりする。事故を防ぐためにも,稼働中の本番環境でいきなり未検証のプログラムをテストしてはいけない。


-第7回 問題管理と変更管理--プロジェクトで生じた問題と仕様変更をコントロールする
--布川 薫
--2007/9/3
--IT Pro / ビジネスSkillUP / プロジェクトマネジメントの理論と実践
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070622/275607/?ST=bizskill
--(引用)プロジェクトが,「品質」,「スケジュール」,「コスト」,「リスク」の観点から計画通り順調に進行しているかどうか。この状況を継続的に把握するのが「トラッキング」だ。計画から外れていれば,対策を立てて計画に沿うよう「コントロール」しなければならない。いずれも,プロジェクトの遂行上きわめて重要な作業だ。


-ソフトウェアテスト技術
--大塚 俊章, 荻野 富二夫
--2007/8
--ユニシス技法 / 93号「ソフトウェアエンジニアリング」
--(PDF)http://www.unisys.co.jp/tec_info/tr93/9306.pdf
--(引用)テスト技術に関する誤解や認識の違いが、ソフトウェア品質の低下を引き起こしたり、場合によってはプロジェクトの成否すら左右する場合があることが、日本ユニシス品質保証部が実施している第三者レビュ等の品質保証活動を通して明らかになってきた。オフショア企業に開発委託しているプロジェクトで特にその傾向があるが、昨今のシステム構築プロジェクトが抱えている共通の問題とも思われる。本稿では、特に誤解が生じやすく、よって委託先と共通理解を確立しておくべきテストの考え方と技術について述べる。


-Ajaxアプリケーションのユニット・テスト
--Andrew Glover
--2007/7/24
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq07247/
--(引用)Ajax アプリケーションを作るのはワクワクすることですが、そのアプリケーションのユニット・テストには実に四苦八苦します。今回の記事で Andrew Glover が取り上げるのは、そんな Ajax のマイナス面 (マイナス面のひとつである)、非同期 Web アプリケーション特有のユニット・テストの問題です。彼が発見したように、Google Web Toolkit の助けを借りれば、この非同期 Web アプリケーションのコード品質の問題を思ったより簡単に解決することができます。


-第3回 品質管理計画−−プロジェクト全体を通じた品質基準や方針を策定する  
--布川 薫
--2007/5/7
--IT Pro / ビジネスSkillUP / プロジェクトマネジメントの理論と実践
--http://itpro.nikkeibp.co.jp/article/COLUMN/20070404/267404/?ST=bizskill
--(引用)納期を守りながら高品質を実現するためにはどうすればいいのか。近道は存在しない。結局,要件定義フェーズや設計フェーズなどの上流工程から,綿密な品質点検と欠陥除去を行うことが欠かせない。そこでプロジェクト計画において,詳細な品質管理計画を立案する必要がある。


-SeleniumとTestNGを使ったプログラムによるテスト
--Andrew Glover
--2007/4/3
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq04037/
--(引用)Selenium は、Web アプリケーションでのユーザー受け入れテストを簡単に実行できるテスト用フレームワークです。Andrew Glover が今月紹介するのは、この Selenium のテストを、TestNG をテスト・ドライバーとして使い、プログラムによって実行する方法です。TestNG の柔軟なテスト機能 (パラメーターを使ったフィクスチャーを含め) を Selenium 固有のツールキットに加えれば、後は DbUnit と Cargo の助けをほんの少し借りるだけで、完全に自動化した、しかも論理的に反復可能な受け入れテストを作成できます。


-TestNG-Abbot による GUI テストの自動化
--Andrew Glover
--2007/2/27
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq02277/
--(引用)TestNG-Abbot は、GUI コンポーネントのテスト方法に新風を吹き込むテスト用フレームワークです。今月は Andrew Glover が、TestNG-Abbot による GUI テストで最も難解な部分、つまりユーザー・シナリオがどのように展開するかを把握すること、について説明します。これさえ理解してしまえば、このフレームワークの便利なフィクスチャー・オブジェクトを使って GUI コンポーネントを分離して検証するのが、どれほど簡単であるかがわかるはずです。


-Part 5: テスト・ツールの種類
--湯本 剛
--2007/2/9
--ITpro / SkillUP / 日経ソフトウェア:テストの実践手法を理解する
--http://itpro.nikkeibp.co.jp/article/lecture/20070209/261607/?ST=lecture
--(引用)テスト・ツールには,マネジメント,動的/静的テストの支援,テスト・ドキュメント作成支援などさまざまな種類があります。使い方を間違えると,逆に効率が下がってしまうので,利用には十分な調査が必要です。


-Part 4: テスト実行の実践方法
--湯本 剛
--2007/2/9
--ITpro / SkillUP / 日経ソフトウェア:テストの実践手法を理解する
--http://itpro.nikkeibp.co.jp/article/lecture/20070209/261607/?ST=lecture
--(引用)テストを実行するときは,ブラックボックス・テストを行ってから,ホワイトボックス・テストを行うようにすると効率的です。単体テスト・ツールとカバレッジ計測ツールは特に活用すべきでしょう。


-Part 3: ブラックボックス技法 
--湯本 剛
--2007/2/9
--ITpro / SkillUP / 日経ソフトウェア:テストの実践手法を理解する
--http://itpro.nikkeibp.co.jp/article/lecture/20070209/261628/?ST=lecture
--(引用)要件や仕様通りにソフトウエアが動作するかを確認するブラックボックス・テストでは,境界値テストのための手法である同値分割や境界値分析のノウハウが必要になります。


-Part 2: ホワイトボックス技法 
--湯本 剛
--2007/2/9
--ITpro / SkillUP / 日経ソフトウェア:テストの実践手法を理解する
--http://itpro.nikkeibp.co.jp/article/lecture/20070209/261626/?ST=lecture
--(引用)ソフトウエアやシステムの内部構造に着目するホワイトボックス・テストでは,処理の複雑さや機能の重要度などを考慮して,適切なカバレッジ基準を選択してテストを実行することがポイントになります。 


-Part 1: テスト設計技法の全体を理解する
--湯本 剛
--2007/2/9
--ITpro / SkillUP / 日経ソフトウェア:テストの実践手法を理解する
--http://itpro.nikkeibp.co.jp/article/lecture/20070209/261600/?ST=lecture
--(引用)テスト設計の三つのポイント「より少ないテスト・ケース」「より多くのバグが見つかるテスト」「漏れがないようにテスト対象を網羅」について,テスト設計技法を紹介します。


--Mercury QuickTest Professionalを使ったテスト
--加藤 大受
--2007/1/22
--ITmedia / エンタープライズ / DevIT / 理論的、計画的なWebアプリケーションのテストの実現
--http://www.itmedia.co.jp/enterprise/articles/0701/22/news005.html
--(引用)前回はオープンソースの機能テストツールであるJameleonを使ってWebアプリケーションのテストを作成した。今回は、商用製品である「QuickTest Professional 9.0」を用いて同様の内容を行ってみる。


--Jameleonを使ったテスト
--加藤 大受
--2006/12/26
--ITmedia / エンタープライズ / DevIT / 理論的、計画的なWebアプリケーションのテストの実現
--http://www.itmedia.co.jp/enterprise/articles/0612/26/news018.html
--(引用)今回から、Jameleon 3.3-M4を使ってJameleonの機能を説明していく。まずはサンプルスクリプトで行われている内容を解説した後、実際にテストスクリプトを作成してみよう。


-JUnitPerfによるパフォーマンス・テスト
--Andrew Glover
--2006/11/29
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq11296.html
--(引用)パフォーマンス・テストは通常、アプリケーション開発サイクルの最後まで棚上げにされます。パフォーマンス・テストが重要でないというわけではなく、不明な変数がありすぎるため効率的にテストするのが困難だからです。今月の「コード品質を追求する」シリーズでは、Andrew Glover が開発サイクルの一環としてのパフォーマンス・テストを提案し、2 つの簡単なテスト方法を紹介します。


-Part 3: テストの管理と分析の仕方
--湯本 剛
--2006/11/9
--ITpro / SkillUP / 日経ソフトウェア:ソフトウェア・テストの基本を学ぼう
--http://itpro.nikkeibp.co.jp/article/lecture/20061109/253131/?ST=lecture
--(引用)米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を元に,ソフトウエア・テストの作業を細かいプロセスに分けて見ていきます。開発プロジェクトにおけるテストの位置付けとして,まず最初にテスト戦略を考え,目指すべき品質に対するテストの方向性を決めます。


-Part 2: テスト固有の技術を学ぶ
--湯本 剛
--2006/11/9
--ITpro / SkillUP / 日経ソフトウェア:ソフトウェア・テストの基本を学ぼう
--http://itpro.nikkeibp.co.jp/article/lecture/20061109/253148/?ST=lecture
--(引用)テスト固有の技術について,(1)テスト設計技術,(2)テストの実施を効率化する技術,(3)テスト・ベースをレビューする技術,(4)バグ報告の技術の順に解説します。テスト設計技術においては,「より少ないテスト・ケース」「より多くのバグが見つかるテスト」「漏れがないようにテスト対象を網羅する」という三つのポイントがあります。テストの実施を効率化する技術の骨子は,テスト・ツールの有効活用です。


-Part 1: ソフトウエア・テストがなぜ重要なのか
--湯本 剛
--2006/11/9
--ITpro / SkillUP / 日経ソフトウェア:ソフトウェア・テストの基本を学ぼう
--http://itpro.nikkeibp.co.jp/article/lecture/20061109/253147/?ST=lecture
--(引用)ソフトウエアの開発プロジェクトを,サッカーにたとえると,テスト担当者はゴールキーパーに相当します。サッカーでは,メンバー全員が「攻め」だけではなく「守り」もできなくてはなりません。この,サッカーで言う「守り」がソフトウエア開発におけるテストに当たります。(略)実際にテストはどのようなことをどんな順序で行っていくのでしょうか。その疑問に答えてくれるものの一つが,開発工程とテストとの関係を表す「Vモデル」です。(略)ソフトウエア・テストを行うために必要な五つの知識や技術を分類してみましょう。


-テストのカテゴリー化による素早いビルド
--Andrew Glover
--2006/10/31
--developerWorks Japan / Java technology
--http://www-128.ibm.com/developerworks/jp/java/library/j-cq10316/
--(引用)開発者によるテストが重要であることは誰もが認めていますが、テストの実行にはどうしてそんなに時間がかかるのでしょうか。今月の記事では、Andrew Glover がエンド・ツー・エンドのシステムの安定性を確実にするために必要な 3 つのテスト・カテゴリーにスポットライトを当て、テストを自動でカテゴリー別に分類して実行する方法を紹介します。これにより、今日の膨大なテスト・スイートでさえもビルド時間が劇的に短縮されることになります。


-ファズ・テスト
--Elliotte Rusty Harold
--2006/9/26
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-fuzztest.html
--(引用)ファズ・テストは単純な手法ですが、コード品質に与えるその影響は計り知れません。この記事では Elliotte Rusty Harold が、障害部分を調べるためにランダムな不良データを故意にアプリケーションに注入すると、どのような結果になるかを説明します。また、チェックサム、 XML データ・ストレージ、そしてコード検証など、ランダム・データに対するプログラムの脆弱性を解消するための防衛的コーディング手法についても説明しています。そして最後に、コードを守るための決定的手法として、コード・クラッカーとしての思考を持つ訓練で記事を締めくくっています。


-反復可能なシステム・テスト
--Andrew Glover
--2006/9/26
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq09266.html
--(引用)論理的再現性を持つテストの作成は、特にサーブレット・コンテナーを組み込む Web アプリケーションのテストとなると、とりわけ困難です。この記事では、コード品質の改善を追求し続ける Andrew Glover がコンテナー管理を汎用手順で自動化する Cargo を紹介します。このオープン・ソース・フレームワークによって、毎回論理的に反復可能なシステム・テストを作成できるようになります。


-JUnit4対TestNG
--Andrew Glover
--2006/8/29
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq08296/
--(引用)新たなアノテーション・ベースのフレームワーク、JUnit 4 には TestNG の選り抜きの機能がいくつか含まれていますが、それによって TestNG が使われなくなることを意味するのでしょうか。この記事では、Andrew Glover がそれぞれのフレームワークの特徴を検討し、まだ TestNG にしか見当たらない高度な 3 つのテスト機能を明らかにします。


-テストのマネージメントとレポート(3)
--湯本 剛
--2006/6/26
--ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
--http://itpro.nikkeibp.co.jp/article/COLUMN/20060626/241754/?ST=develop
--(引用)ここまでテスト結果の適切な報告が品質向上に重要だと繰り返し説明してきました。では具体的にどのようにレポートすればいいでしょうか? ダラダラと文章ばかり書いても開発者やマネージャは読んでくれないかもしれません。そこで最後に,ソフトウエア・テストが情報サービスとして有益な情報を流すためのメトリクス(指標)の例ををいくつか紹介しましょう。


-テストのマネージメントとレポート(2)
--湯本 剛
--2006/6/5
--ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
--http://itpro.nikkeibp.co.jp/article/COLUMN/20060605/239909/?ST=develop
--(引用) たいていの場合,ソフトウエア・テストというと,どうやってテストをするのかといったテストの実施部分だけを思い浮かべるのではないでしょうか。しかし,テストを実施面だけでとらえていると,効果的なテストはできません。そこで,米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を紹介しましょう。このモデルでは,開発とテストは最初から並行して進んでいくプロセスとして表現しています。先ほど,「テストは同時並行的に進めるライフサイクルプロセスである」という定義を引用しましたが,まさにそのイメージがWモデルになるわけです。


-テストのマネージメントとレポート(1)
--湯本 剛
--2006/6/5
--ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
--http://itpro.nikkeibp.co.jp/article/COLUMN/20060605/239909/?ST=develop
--(引用)このプロジェクトの開発者は,これから納品までの間,帰れない日々を続けることになりそうですね。こんなときは,テストが余計な作業に見えて仕方ないかもしれません。でもこれは,自業自得というものです。あらかじめテストする範囲を計画的に決めておかないと,このような事態になるのです。また,納品前には品質を判断する指標を用意しておくことも,テストの大事な仕事です。これらを怠るといつまでたっても納品後のクレームに悩まされることになってしまうでしょう。 


-今こそテストの基本技術を学ぼう!(3) 
--湯本 剛
--2006/5/31
--ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
--http://itpro.nikkeibp.co.jp/article/COLUMN/20060531/239593/?ST=develop
--(引用)テスト設計には図のようなポイントがあります。テストはやろうと思えばきりがありませんから,最小限の労力で最大の効果が得られるように知恵を絞ろうというわけです。(略)テスト固有の技術の二つ目は,いかにテストを効率化して実施するかという技術です。(略)テスト固有の技術の三つ目は,テスト・ベースをレビューする技術です。テスト・ベースとは,テスト設計に使う設計資料一式のことを指します。テストベース・レビューの狙いは三つ,テスト設計の効率化,テスト実施の効率化,テストしやすさの設計への反映です。(略)テスト固有の技術の四つ目は,バグ報告の技術です。これは,バグを見つけたら,バグ・レポートを作成して,修正されたことを再テストして確認するまでを意味します。


-今こそテストの基本技術を学ぼう!(2) 
--湯本 剛
--2006/5/30
--ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
--http://itpro.nikkeibp.co.jp/article/COLUMN/20060530/239412/?ST=develop
--(引用)サッカーからの教訓で,テストは開発メンバー全員の仕事と書きましたが,それぞれのメンバーが行わなければならないテストは一言ではくくることができないくらい,いろいろな種類があります。


-今こそテストの基本技術を学ぼう!(1) 
--湯本 剛
--2006/5/23
--ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
--http://itpro.nikkeibp.co.jp/article/COLUMN/20060523/238743/?ST=develop
--(引用)これから6回にわたってソフトウエア・テストの基本について解説します。テストの基本を理解することは,品質の良いソフトウエアを作るための大切な一歩となるはずです。今回から第3回まではソフトウエア・テストに必要な技術について,第4回から第6回は品質分析やマネージメントについて解説します。


-ConTestを使用したマルチスレッド・ユニットのテスト
--Yarden Nir-Buchbinder, Shmuel Ur
--2006/4/4
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-contest/
--(引用)並列プログラミングは、バグが発生しやすいことで有名です。さらに悪いことに、並列プログラミングで発生したバグは開発プロセスの終わり近くになって発見されることが多く、この段階でのバグは開発プロセスに深刻な影響を与え、修正することも困難です。従来の単体テスト手法をどれだけ徹底的に実行しても、並列プログラミングにおけるバグをなくすことは困難です。この記事では、並列プログラミングに詳しいShmuel UrとYarden Nir-Buchbinderが、こうしたバグはなぜ見つけるのが難しいのかを説明し、IBM Researchによる新しい解決策を紹介します。


-レガシー・コードのテスト
--Elliotte Rusty Harold
--2006/4/4
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq09266.html
--(引用)オブジェクト指向プログラミングの登場以来、テスト駆動プログラミングは最も効果的なコーディング技法となっていますが、この技法はコードが何もない状態からのスタートを前提としています。もしすでにコードが存在しているとしたら、どういう作業になるでしょうか。人気の高いオープン・ソースのJava™ ツールを例に取り、これまでにテストされたことのないレガシー・コードのテスト・スイート(テスト・セット一式のこと)を作成する方法について、 Elliotte Rusty Haroldが紹介していきます。


-FITで解決する
--Andrew Glover
--2006/2/28
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq02286/
--(引用)JUnitでは、テストはすべて開発者の領域であると考えます。一方、FIT(Framework for Integrated Tests)を利用すると、要求を記述するビジネス顧客と、そうした要求を実装する開発者の間で協力してテストを行うことができます。では、FITと JUnitは競争相手なのでしょうか。絶対にそんなことはありません。この記事では、コード品質の完璧主義者であるAndrew Gloverが、FITとJUnitの良いところを組み合わせてチームワークを改善し、効果的なエンド・ツー・エンド・テストを行うための方法を解説します。


-カバレッジ・レポートに騙されないために
--Andrew Glover
--2006/1/31
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq01316/
--(引用)テスト・カバレッジ・ツールを使うとユニット・テストに深みが増しますが、このツールは多くの場合、誤って使われています。今回はAndrew Gloverが、この領域での彼の長い経験を生かして、新しいシリーズ、『コード品質を追求する』を開始します。第1回目である今回は、カバレッジ・レポートに表れる数字が実際に何を意味するのか、また逆に数字に意味がない場合について詳しく見て行きます。そして、カバレッジ・ツールを初期段階で頻繁に使用してコード品質を向上するための、3つの原則を提案します。


-品質を見極めるソフトウェアテストの基本
--克元 亮
--2006/1/24
--All About Japan / ネットビジネス / ITプロフェッショナルのスキル 
--http://allabout.co.jp/career/swengineer/closeup/CU20060125A/
--(引用)ITのプロフェッショナルを自認するなら、自己成長が欠かせません。「SEの本棚」シリーズでは、知識習得に有効な、さまざまなジャンルの本を紹介していきます。(略)シリーズ第5回は、テストに関する本をとりあげます。


--オープンソースの自動化テストツール「Jameleon」の概要
--加藤 大受
--2006/1/12
--ITmedia / エンタープライズ / DevIT / 理論的、計画的なWebアプリケーションのテストの実現
--http://www.itmedia.co.jp/enterprise/articles/0601/12/news001.html
--(引用)この連載では、さまざまなテストプロセスがあることを説明してきた。今回は、自動化に向いている機能テストを考えつつ、それを実現するオープンソースのフレームワーク「Jameleon」を紹介しよう。


-知っておきたいテストの“イロハ”(5)
--石川 和則
--2005/11/30
--ITpro / ITレポート
--http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223966/?ST=upper
--(引用)単体テストや結合テストは,システムを構成するソフトウエアに着目してテストを実施する。これに対して,システムテストは,ハードウエアと利用者という要素を加えて,システムとして動作したときに発生する総合的な問題を検出することが目的である。(略)システムテストを実施する際には,まずシステム全体を客観的に俯瞰し,システムの持つ構造上の弱点や運用上の問題点を洗い出さなければならない。


-知っておきたいテストの“イロハ”(4)
--石川 和則
--2005/11/30
--ITpro / ITレポート
--http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223965/?ST=upper
--(引用)単体テストが終了すれば,次に結合テストのフェーズとなる。結合テストは,機能や処理に対するまとめ的なテストである。事例システムの場合,単体テストでプログラムのロジックの観点から制御パス・テストを実施したので,結合テストではデータの流れに基づいたデータフローパス・テスト手法を用いることにする。


-知っておきたいテストの“イロハ”(3)
--石川 和則
--2005/11/29
--ITpro / ITレポート
--http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223964/?ST=upper
--(引用)前回までは,テストの基本的な手法や管理方法について説明した。だが,現実のプロジェクトでは基本通りに進まないことが多々ある。そこで今回からは「応用編」として,BtoCのWebシステム開発を例に,具体的なテストの進め方について説明する。


-知っておきたいテストの“イロハ”(2)
--石川 和則
--2005/11/28
--ITpro / ITレポート
--http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223936/?ST=upper
--(引用)実際にテストを実施する際には,プログラム開発と同様に,テストの「設計」が必要になる。しっかりした設計を行わずにテストを実施したのでは,テスト手法を十分に活用できない。プログラミングを覚えたてのプログラマが,いきなりコーディングを始めるようなものだ。では,テスト設計とはどのようなものなのだろうか。


-知っておきたいテストの“イロハ”(1)
--石川 和則
--2005/11/9
--ITpro / ITレポート
--http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/?ST=upper
--(引用)テストの基本的な知識は、あまねくITエンジニアが持つべきだ。しかし実際には、本当に基本的な知識でさえ浸透していないのが現状である。そこでこの記事では、ITエンジニアが最低限知っておくべきテストの基本知識と、その活用方法を解説する。


//-----------------------------------------------------------------------------
**記事(Wiki化以後・TDD関連) [#cbf840f6]


-なぜ従来のテスト自動化ツールはアジャイルを抑えつけるのか
--Mike Bria
--2008/5/15
--InfoQ
--http://www.infoq.com/jp/news/2008/05/testobsessed-agile-auto-testing
--(引用)最近、次世代機能テストツールの方向性について大きな興奮が広がっている。あぁ、多くのアジャイル組織が、今もなお従来の記録および再生する自動テストツールを動かそうと苦心している。「test Obsessed (テストに夢中)」で知られるElisabeth Hendrickson氏はなぜそのようなことをやめるべきか述べている。


-ビヘイビア駆動開発を舞台にした冒険
--Andrew Glover
--2007/9/18
--developerWorks Japan / Java technology
--http://www.ibm.com/developerworks/jp/java/library/j-cq09187/
--(引用)テスト駆動開発 (TDD) は実際には素晴らしいアイデアですが、一部には、テストという言葉に結び付けられた考え方の飛躍にどうしてもついていけないという開発者もいます。そこでこの記事では、より自然な形で TDD のこの考え方をプログラミング・プラクティスに取り入れる方法を紹介します。JBehave を使ったビヘイビア駆動開発 (BDD) を試して、結果ではなくプログラムの振る舞いに重点を置くと、どんな変化が生まれるのか自分自身で確かめてください。


-テストファーストによるソフトウェア開発の衝撃(後編)
--瀬谷 啓介
--2007/2/28
--ITmedia / エンタープライズ / DevIT
--http://www.itmedia.co.jp/enterprise/articles/0702/28/news023.html
--(引用)テストファーストがソフトウェアキテクチャに及ぼす多大な影響について説明する本稿。後編では、「究極の仕様書」と言っても差し支えないであろう受け入れテストについて触れたいと思います。


-テストファーストによるソフトウェア開発の衝撃(前編)
--瀬谷 啓介
--2007/2/27
--ITmedia / エンタープライズ / DevIT
--http://www.itmedia.co.jp/enterprise/articles/0702/27/news012.html
--(引用)皆さんはテストの本質を理解されていますか? 実は、テストには機能検証をするということ以上に重要な役割があるのです。本稿では、テストファーストがソフトウェアアーキテクチャに及ぼす多大な影響について説明します。


//-----------------------------------------------------------------------------
----
RIGHT:[[swtest.jp/wiki/readings]]に戻る
RIGHT:[[swtest.jp/wiki]]に戻る

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS