第3回次期バージョン1.8に見るTestLinkの過去・現在・未来 TestLink日本語化部会 2008-10-17
連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社
第3回次期バージョン1.8に見るTestLinkの過去・現在・未来 TestLink日本語化部会 2008-10-17
ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組
WACATE 2011 夏に誘われたのがキッカケでソフトウェアテストを勉強しはじめて10ヵ月くらいがたちました。 先日、わんくま名古屋でソフトウェアテストの勉強法についてLTしたのですが、みなさんにいろいろ聞かれたのでここにまとめておこうと思います。 本当は1年の区切りで書こうと思ったけど、まぁいいでしょう。 追記ここから わんくまで発表したLT資料はこちらです うさみみのソフトウェアテスト勉強法 View more presentations from Kyon Mm 追記ここまで こういうのを書くときに時系列で書くべきか、コツを書くべきか悩みますね。 でも、みんなが知りたいのは僕の歴史じゃなくってコツだと思うので後者で書きます。前者はTwitterとか勉強会とかお食事とかお茶でもしているときに聞いてみてください。 以下では多くの書籍を紹介していますが、僕がこの10ヵ月で読んだ本。ってい
逆引きソフトウェアテスト関連技術まとめ - >& STDOUT
「Software Test ＆ Quality Advent Calendar 2011」の8日目。アドベントカレンダーということで、普段と少しトーンを変えてソフトウェアテストにあまり造詣のない方へ向けて何か役に立つ記事を考えてみました。先の記事でも述べたとおり、ソフトウェアテストの関連技術を表す用語はそれが何に使えて、何に役立つのか、門外漢にはとってもわかり難いので、そちらを軸にした紹介があると便利かもしれないということで、関連技術を目的別に整理し、参考になる記事や資料にリンクする形でお届けします。 テストの戦略を定めたい ソフトウェアテストプロジェクトの最上流工程と考えられているテスト分析の方法論です。プロダクト、プロジェクトに対してそれぞれ独自の方式で戦略を検討します。テスト計画と一部被る部分もありますが、プロジェクトの予算やスケジュールをひとまずおいて技術的な視点から本当に必要な
富豪的 Android プログラマの為の Eclipse Memory Analyzer Tool 入門 - sandbox
はじめに Android プログラマのみなさん、こんにちは。 今日も元気に Out Of Memory してますか? ということで、この記事では日々 OOM に悩まされる Memory 的な意味で富豪的な Android プログラマの為に、Eclipse Memory Analyzer Tool、通称 MAT の基本的な使い方を紹介します。 尚、この記事は [twitter:@youten] さんが企画された裏 Android Advent Calendar 12/20 の記事ですが、内容的には比較的オモテなものになっています。 対象読者 Andoid アプリ作ってる/はじめたけど、まだ MAT を使ったことがない方 MAT を使ってみようした事はあるものの、画面から難しそうな雰囲気を察知し、起動10秒後にはそっとタブを閉じてしまった経験がある方 DDMS の基本的な使い方を理解している方
Android MockとRoboGuiceでTDD - 遥かへのスピードランナー
Androidアプリ開発（に限った話ではないですが）でTDDしたいと思ったときに、テスト対象クラスのフィールドをモックで差し替えたい、と思うことがしばしばあります。依存するクラスの振る舞いを固定化することで、テスト対象オブジェクトの振る舞いだけに着目したテストケースを書くことができるからです。 そんな時に、DIコンテナ上でコードを書いていると便利です。以前、少しだけSeasar2+EasyMockでテストを書いていたことがあったのですが、作成したモックオブジェクトの差し替えを、ほぼ全てSeasar2がやってくれたのでものすごく便利でした。 Android開発でもSeasar2+EasyMockくらい簡単にテストを書きたい！ ということで、 Android Mockでモックオブジェクトとその振る舞いを定義 RoboGuiceでモックオブジェクトをテスト対象クラスにインジェクト ということをや
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
Androidのシナリオテストツール Robotium やってみた。 - しかじろうがプログラム作るよ！
昨日、パプテマス Scirocco 触ってたら中はRobotiumというのを使っていたので調べてみたら、そこそこメジャーなシナリオテストツールだったので、触ってみました。 Robotium とは Androidのシナリオテストを簡単に書けるライブラリです。UIスレッドを意識せずに書けるので、テスト仕様書に近いコードを書くことができます。ブラウザテストツールのSeleniumを意識してるみたいですね。 公式サイト robotium - It's like Selenium, but for Android™ - Google Project Hosting サンプルプロジェクトを動かす。 とりあえずサンプルプロジェクトを動かします。やることは二つ。 SDKのサンプルアプリ notePad をインポート ExampleTestProjectをインポート テスト対象となるプロジェクトはSDKに含
Archived Projects | The Eclipse Foundation
Archived Eclipse Projects You are seeing this because the project you were looking for has been archived. When projects are archived their data(downloads,source and website), is collected into a single tar.gz file. Please note: Some projects did not have all of the above data. Please note: The source files (if available) included in these files are direct copies of the available CVS/SVN data. You
【超訳】AndroidのUIをUnitTestできるNative Driver - Android Zaurusの日記
Introducing Native Driverの超訳。 Native DriverはWeb Driver APIの実装で、WebアプリケーションではなくネイティブアプリケーションのUIを叩くもの。Android版がダウンロード出来るようになったので、ユーザとコントリビュータをゆっくり募集。Google Code (http://nativedriver.googlecode.com/ )に置いてある。iPhone(iOS)版も開発中でもうすぐ使える。 WebDriverはブラウザの機能を綺麗でオブジェクト指向なAPIとして見せてくれるので、Googleでは多くのプラットフォーム上でWebアプリケーションをテストするのにWebDriverを使っている。（WebDriverについては、このブログ記事を参照） なぜWebDriver APIをネイティブアプリケーションに使うのか不思議に思うか
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
テンプレートから学ぶ 受注する開発者のためのテスト仕様書
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
ソフトウェアテストの勉強室
CEGTest はJavaScriptを使って、オフラインでも動作するように実装していますが、ウェブ版ではニフティクラウド（mBaaS）を利用して、いくつかのサンプルデータを取得できるようにしました。 サンプルデータは、原因結果グラフの演習で公開しているデータが利用できます。なお、演習問題のページで紹介している模範解答はあくまで「解答例」の一つですので、仕様の考え方や何の検証を優先するのか、などによって原因結果グラフは異なります。 今後は、FacebookやTwitterなどSNSとの連携ログイン機能やログインユーザ毎のデータ保管などを考えてみます。
FitNesseが本当にソフトウェアテストの未来を示しているかが分からない - チラシの裏 - スコトプリゴニエフスク通信
FitNesseはAcceptance TestingをWikiフォーマットで記述するためのフレームワーク・ライブラリ。http://fitnesse.org/『実践アジャイルテスト』や『ビューティフルテスティング』で肯定的に紹介されているプロダクトだから、ちょっと気にしているのだが、自分でインストールして使ってみようと思うと、躊躇われる。テスターやプロダクトオーナーやプログラマがWikiベースのドキュメントを維持することによってテストを維持しようって思想は理解できるのだが、その思想をありとあらゆるポジションの人に押し付けるには、ツールとして弱すぎる感じがする。FitNesseはちょっとどうなのかなと思うけど、『実践アジャイルテスト』や『ビューティフルテスティング』で示されているQAに対する考え方は素晴らしい。おすすめ。実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
BuildBot メモ :: 幕の内 - CMS - コンテンツマネジメントシステム
BuildBotはPythonで記述されたテスト自動化システムです。任意のイベントを契機に動きだし、必要なリソースの取得・テスト・記録・通知を行います。幕の内の開発ではBuildBotを用いてSubversionからのチェックアウト・テスト・メール通知を行っています。 BuildBotとは BuildBotはPythonで記述されたテスト自動化システムです。任意のイベントを契機に動きだし、必要なリソースの取得・テスト・記録・通知を行います。幕の内の開発ではBuildBotを用いてSubversionからのチェックアウト・テスト・メール通知を行っています。 BuildBotは基本的に自動テストツールなので、テストをたくさん書いておかないとあまり意味がありません。幕の内開発では UnitTest, functional-test, Seleniumでのテストを行っていて、これらのうちUnitT
第5回 継続的テスト | gihyo.jp
継続的なテストの重要性について 松野です。こんにちは。 今回は継続的なテストという話題についてお話したいと思います。本稿では、少人数のチームによるWebサイト開発というケースにフォーカスして論じていきます。 本稿で取り上げる継続的テストとは、端的にいえば「自動でテストを定時実行させる」ということです。 make testするのをうっかり忘れたりしていませんか？ テストを動かすのを面倒がってテスト動かさずにコミットしていませんか？ そして、そのままデプロイしたりしていませんか？ 割れ窓理論というのがあります。これは「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなくすべて壊される」（引用：Wikipedia）という理論です。 これは、テストスィーツにも言えることです。1つのテストがこけていると、make testする気力が失せます。あるいはテ
TestLink
How to Write a Thesis on T-Building A strong introductory paragraph starts with a hook that grabs the reader’s attention. Then, it provides details that lead to the thesis statement. The T Building—formerly the Triboro Tuberculosis Hospital in Queens, New York —is now affordable and supportive housing. It’s also a model for adaptive reuse of historic buildings. Adaptive Reuse of an Historic Buildi
ウノウラボ Unoh Labs: 見ないと損する ソフトウェアテスト関連サイト色々
こんにちは！やまもと＠テスト番長です。 今回は自分が普段チェックしている、ソフトウェアテスト系のサイトを色々ご紹介してみようと思います。既にご存知のサイトもあるかと思いますが、宜しくお付き合いください。 swtest.jp/wiki http://www.swtest.jp/wiki/index.php?swtest.jp/wiki 最近wiki化され、情報更新が活発になっています。必見です。 StickyMinds.com http://www.stickyminds.com/ コラムなどの読み物が充実しています。 Google Testing Blog http://googletesting.blogspot.com/ グーグルのテストチームのブログです。面白くないはずがありません。 Open source software testing tools http://www.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
