InfoQ: あなたがやっているのはテスティングかチェッキングか？
原文(投稿日：2009/12/08)へのリンク ソフトウェアテスティングとは、ステークホルダにテスト中の製品やサービスの品質に関する情報を提供するために実施する、経験的調査のことだ。しかし、この定義では、テスティングとチェッキングの微妙な違いを生む「知恵」については語られていない。Michael Bolton氏は、これら2つの違いと、その違いがある理由について語った。 Michael氏によると、 チェッキング（チェックすること）とは、すでにある信念を確認するという動機から実施するものです。チェッキングは確認、検証、妥当性確認というプロセスになります。すでにそれが正しいと信じているときに、チェッキングによってその信念を確認します。コードを変更してもこれまで同じようにすべて動作することを確かめたいときに、私たちはチェックします。 テスティング（テストすること）とは、新しい情報を見つけるという動
受け入れテストの自動化 ～ OpenCVの「眼」で捉え、Pythonの「脳」が思考し、Appiumの「指」で動かす - Speaker Deck
2017/02/03 JaSST’17 Tokyo
スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
テストを書くかどうか議論するの不毛だから、どうやってテストを書きやすくするか議論しよう - Qiita
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするかという記事がバズりました。みんなテストについて思うところがあるようだ。テストを書くべきか否かは机上の空論になりがちで不毛なので、どうやってテストを書くか、テストの書き方、について、種を巻いた私が書いておく。 もっと詳しい方からのお話お待ちしています。 書くこと テストの書きやすくするためのいろいろ（箇条書き） 書かないこと テストの基本 テストファースト 実装ありきでテストを書くのではなく、テストありきで実装を変える。 はっきり言って、テストを考慮せずに実装されたコードは、書き直さずにはテストできない。 そういう点で、テストなしで実装する選択肢は不可逆なので、初期実装では特に注意が必要。 クリーンアーキテクチャ(DDD) クリーンアーキテクチャの考え方はテストファーストを語る上で重要。私個人としてはまだクリーンアーキテクチャ
すでに生み出されて動いているレガシーコード（テストのないコード）との戦争。結局武器はテスト - Qiita
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか というという記事がバズって以降テストの記事ばかり投稿しています。この際だからテストに関するもやもやを吐き出しておきます。 上記記事にてToDoとして、 すでに生み出されて動いているレガシーコードにどう立ち向かうか と書きました。 一回レガシーコードと戦って勝利一歩手前まで行った経験があるのでその経験をまとめます。 どんなコードだったか 規模は小さめ ユニットテストなし 自動テストなし テストはデプロイしないと不可 前任者（作成者）いない UIなし やりたいこと テストがあれば一時間で終わる程度の変更を加える 格言 レガシーコードの改変について有名な格言があり、 レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。 「レガシーコード
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
xUTP Magazine - xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」
書いた人：@yujiorama(id:yujiorama) 目次 目的 はじめに テストの匂い テストコードの匂い Obscure Test Conditional Test Logic Hard-to-Test Code Test Code Duplication Test Logic in Production 振る舞いの匂い Assertion Roulette Erratic Test Fragile Test Frequent Debugging Manual Intervention Slow Tests プロジェクトの匂い Buggy Tests Developers Not Writing Tests High Test Maintenance Cost Production Bugs さいごに 目的 この連載記事の目的は次のような感じです。 xUTP読書会で得られた知見を
テストという破壊的な作業の建設的なやり方
大西 Rexさん、このたびはJaSST'05の基調講演のために来日くださり、ありがとうございます。この懇談会では、まずRexさんから、2冊にわたるテスト管理の本を書かれた際の裏話や、苦労話、はたまた面白い話などありましたらお聞きかせいただけないでしょうか。 Rex Black（以下Black） 苦労というほどのことは、そんなにありませんでした。ほとんどの場合、自由に何でも書いてよい立場にあったからです。クライアントからはNDA（Nondisclosure Agreement＝守秘義務契約）上の制約こそありましたが、開発の人たちが体験したことを書いてよいとの承諾を得ることができましたから。もちろん、プロジェクトが明示的に分からないように日付を変えたり名前を変えたりはしています。また、ケーススタディでは不適切と思われる表現は変えています。皆さんも経験があると思いますが、プロジェクトを進めていく
B2 テスト自動化
A U T O M A T O R A U T O M A T O R A U T O M A T O R A U T O M A T O R A U T O M A T O R A U T O M A T O R A U T O M A T O R A U T O M A T O R T E S T T E S T T E S T T E S T T E S T T E S T T E S T T E S T なれる！Test Automator -テスト自動化を成功に導く3つの真実- 2013/1/30 テスト自動化・TABOK研究会 JaSST’13 Tokyo セッションB2 セッションの流れ セッションの流れ セッションの流れ セッションの流れ ホームルーム 1時限目: テスト自動化の現場より 2時限目: 真実1. テスト自動化のスコープ 3時限目: 真実2. テスト自動化のRO
自動テスト知識体系TABOKのご紹介
1. テスト自動化知識体系 「 TABOK 」のご紹介 Company LOGO ソフトウェアプロジェクトにおけるツールの活用を考える会 松木 晋祐 2. 松木 晋祐 @snsk しんす ( く || け ) さん とよく呼ばれてます 所属しているコミュニティ 株式会社 ACCESS NPO 法人 ASTER JaSST 東京実行委員会 /ASTER ToolWG/ 智美塾 Android テスト部 ソフトウェアプロジェクトにおけるツールの活用を考える会 アジャイルプロセス協議会 ( テスト、レビュー WG) 思いつきでノージャンルの勉強会主催 Android 開発入門 /Selenium 入門 /Web 技術概論講座 等 何の人？ ひたすらウェブブラウザやってた関係でずっとウェブ でも基盤技術 (HTML,CSS,JS/DOM,HTTP,SSL 等 ) しか知らない 「派遣テスター」から
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
続・そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
3年前にこんな記事をあげました。 bleis-tift.hatenablog.com 3行でまとめると、 Power Assertはユニットテストのためにほしかったものではない 欲しいのは結果の差分 誰か作って！ というエントリでした。 そしたら id:pocketberserker が作ってくれました！ github.com PowerAssertより強そうな名前でいい感じです。 Power Assertは時代遅れ、今はMuscle Assertだ！的な話かな？— 裸のWPF/MVVMを書く男(マン) (@gab_km) 2016年6月1日 MuscleAssertの使い方 このライブラリは、PersimmonというF#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき
テスト計画の立て方 - Qiita
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
Persimmon用アサーションライブラリMuscleAssertを作った - pocketberserkerの爆走
正確には「作っていたライブラリをPersimmon.MuscleAssertにrenameした」です。 注意 この記事はあくまで私の考えでありpersimmon-projectsの総意であるわけではありません。 前提 PersimmonはF#用のテスティングフレームワークです https://github.com/persimmon-projects/Persimmon そんなにF#寄りの話はしないはずなのでこれくらいの情報量で大丈夫なはず…？ Persimmonはpower assertの夢を見るか？ 昨今はpower assertの認知度が格段に上がっているようですね。 これはJavaScript向けのpower-assertによるものが大きいのではないかと思われます。 ちょっと脱線しつつPersimmonにpower assertが必要か考えてみましょう。 どの意図でのpowert
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストを書こう!!
Blogger
GitHub - microsoft/pict: Pairwise Independent Combinatorial Tool
QAエンジニアを通じて�弊社の開発環境がより良くなる日� 〜 OpenSTF 編 〜
Scrum,Test,Metrics #sgt2016
