書評 『Agile Testing Condensed Japanese Edition』 〜アジャイルテストの一冊目として最適〜｜hgsgtk
Janet GregoryとLisa Crispinによる2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています！ Janet氏とLisa氏といえばAgile Testing DaysのYouTubeチャネルでも頻繁に登場しAgile Testingについてわかりやすい解説をしてくださってる 本書は訳者まえがきにあるが、著者たちの3冊の本（『Agile Testing: A Practical Guide for Testers and Agile Teams』、『More Agile Testing: Learning Journeys for the Whole Team』そして『Agile Testing Condensed: A Brief Introduction』
Testing JavaScript をやってみたら学びがあって良かった話 - Adwaysエンジニアブログ
こんにちは。リファクタリングが大好きなフロントエンドおじさん梅津です。 自信を持ってリファクタリングするには信頼できる自動テストが必要ですよね。 じゃあ信頼できる自動テストとはなんだろう？どう書いたらいいんだろう？と考えていました。 とくにコンポーネントを含む UI テストに対しての悩みが強かったです。 そんなときに出会ったのが Testing JavaScript です。 この記事ではその Testing JavaScript の紹介をしたいと思います。 Testing JavaScript とは Testing JavaScript は PayPal のエンジニアである Kent C. Dodds によって作成された教材です。 ページを開いてすぐ目に飛び込んでくるテスティングトロフィーが特徴的ですね。 Testing JavaScript では、ここに記されている Static, Un
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜Webエンジニアのキャリアを考える！
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 ソフトウェアのテストにおいて、最初のフェーズである単体テスト。若手Webエンジニアの中には、いきなり単体テストを任されて戸惑った方もいるでしょう。仕方なく現場で踏襲されているやり方に従っているだけ、ということもあるのではないでしょうか？ 今回は、単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 単体テストとは（各社ばらばらな単体テストの定義を再定義） コードベースの単体テスト 命令網羅（C0カバレッジ） 分岐網羅（C1カバレッジ） よくある（コードベースの）単体テストの間違い 機能単位の単体テスト 例：複雑なソート機能のテス
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
初心者プログラマーの僕が、テスト駆動開発を愛する5つの理由 - Qiita
最初に テスト駆動開発（以後TDD）の存在を知って、自分で取り入れてみてから、自分の開発は良くなったと思っています。 TDDを人におすすめしよう！ と思って本を読んだり色々と調べていたりするうちに、 TDDは死んだ とか、テスト全部書かなくても...と言われていることを知りました。 それでも自分はTDDで開発するのが好きだし、自分には合っていると思うので、自分がTDDを愛する理由を書いてみたのがこの記事です。 若干ポエム寄りになっているかもしれませんが、ご容赦いただけると幸いです。 前提としていること TDDの基本的な流れとして、タスク細分化→Red/Green/Refactoringのループを回す、であること 実践者は初心者であり、実装にまだ不慣れであること（内容についての言い訳ではなく、そういう人がTDDを実践した事で感じた事を書いたという意味） TDDではなく自動テストによる恩恵も含
xUnit Test Patternsから学ぶ12個のユニットテストの原則 - Qiita
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
手動回帰テストマニフェスト
回帰テストを自動化することは必ずしも最適解ではない。2018 fall Online Testing Conferenceで、Brendan Connolly氏はこう主張した。彼は「手動回帰テストマニフェスト」を発表し、それを使うことで、機能テストと回帰テストを区別し、テストを自動化するかどうか決める方法を紹介した。 手動回帰テストマニフェストは、アジャイルマニフェストに示された価値をモデルにしている。これはオープンな目的の宣言であり、品質について話し合い、テスターがそれにどのように貢献するかを探るためのフレームワークだ。 Connolly氏は「テスト」の問題、特に回帰テストを解決する銀の弾丸がほしいという要望があるようだ、と述べた。適切なツールを購入し、すべてのテストを自動化し、それをAIにやらせたいわけだ。これらに価値がないわけではない。ただ、ウォーターフォール・ソフトウェア開発の時代
2018年のアウトプットまとめ - t-wadaのブログ
2018年は公私ともに忙しい年でした。このエントリを書いている時点でもう年が明けてしまいましたが、1年のふりかえりとして、またある種のポートフォリオとして、1年間のアウトプットをまとめたいと思います。 手元のスケジュールを確認したところ、講演/ワークショップを53回、インタビュー/対談/Podcast出演を5回、社内読書会ゲスト参加を3回、執筆、増刷作業を6回、主要OSSプロダクトのリリースを3回行っていました（小さなモジュールはカウント外）。これらが2018年のアウトプットです。 新作登壇（6回） 私は再演が多い講演者で、登壇依頼のほとんどは既存の講演/ワークショップの再演です。それでも2018年に新しいテーマの講演をいくつか行いましたので、それら「新作」がアウトプットの筆頭となるのではないかと思います。 技術選定の審美眼（2月15日） 2月15日に「技術の進化の歴史は振り子ではなく螺旋
Storybook による UI & Unit Testing のススメ | メルカリエンジニアリング
Mercari Advent Calendar 2018 19 日目です。 担当はメルカリ JP フロントエンドチームの @nekobato がお送りします。 メルカリ フロントエンドチームでは主に React を利用してフロントエンド構築を行っており、 その中のWeb Rearchitecture では Storybook による UI Testing に取り組んでいます。 今回はフロントエンドの UI Testing と Unit Testing を Storybook & Storyshots を利用して行っているという話をします。 Storybook とは Storybook は個別の UI コンポーネントをブラウジングする開発環境を構築するモジュールです。 単独では目視による UI テストを可能にするのみですが、アドオンと組み合わせることで様々なテスト環境を構築することが可能にな
毎週リリースを実現するテスト活動 - クックパッド開発者ブログ
こんにちは。 品質向上グループの茂呂一子(@ichiko_revjune)です。 クックパッドアプリは、サブミット・リリース作業を自動化して、アプリを毎週サブミットするようになりました。これを実現するリリースフローについては、 クックパッドアプリはみんなが寝ている間にサブミットされる で紹介しました。 このリリースフローを実現していく過程では、「機械に人間があわせる」という方針で、サブミット・リリース作業が自動化されていきました。つまり、毎週サブミット・リリースをするためには、何をどのように自動化するべきかという視点で自動化する対象が決まっていきました。 アプリは開発が終わればすぐにリリースできるというものではありません。この記事では、リリース前のテスト作業をどのように調整して、毎週リリースを実現しているのかを説明していきます。自動サブミットの導入はiOSアプリが先行したため、ここではiO
QuipperのWebエンジニア採用におけるコードテスト - Quipper Product Team Blog
こんにちは、Web エンジニアの @kechol です。 Quipper では現在、ブログを再開したり StudySapuri Meetup（Product 回、Data 回）を開催したりと、採用活動に力を入れています。今日はそんな採用活動について、僕も関わっている Web エンジニアの採用プロセスの裏側を少しご紹介したいと思います。 TL;DR Quipper における Web エンジニア採用プロセスにおいては、コードテストを実施しており、そのプロセスは非常に重要なものだと考えている これまでアプリケーションを書いてもらうようなテストを実施していたが、候補者・採用メンバー双方の負担が大きく、改善の余地があった それを受けて、より小さく、実務に近いコードでテストできるようにコードテストを改善した Quipper における Web エンジニアの採用プロセス Quipper における Web
Ericssonの『ユニットテストカバレッジの神話』を読んでみる - ソフトウェアの品質を学びまくる
今年の4月に『Mythical Unit Test Coverage』（ユニットテストカバレッジの神話）という論文が出ました。ソースコードの品質指標として言及されることの多いコードカバレッジについて、先行研究を整理したうえで、商用の大規模ソフトウェアにおける追加検証をしたものです。IEEEのサイトでも全文公開されています。 Mythical Unit Test Coverage - IEEE Journals & Magazine 長い論文ではないのですが、わたしには論理展開のわかりづらい部分があったので、整理してみました。 アブストのアブスト 「リリース前にどれだけのテストをすべきか」というのはずっと問題。 テストの十分性の指針として、Ericssonで長年使ってきたユニットテストのカバレッジのクライテリアを検証した。 結果として、ユニットテストカバレッジは、欠陥のないソフトウェアを作る
テストフェーズがなくなるのが未来だろうっていう話
「じゃ、どういうプラクティスがあればいいのだろう？」と考えはじめたのが、メルカリに入る少し前の頃。そこで今ためしにAutomation & QA チーム（通称：AQA）でがんばっているのが //speakerdeck.com/assets/embed.js ↑の部署紹介資料にもある「Continuous E2E Testing」です。現在は夜間ビルド＆手動でいつでも実行。そして、最終目標はコミットごとの実行（でもすごくそれは難しい）。 だって、アジャイル開発、DevOps時代だともう、ずっとテストするしか「はやく」ならないんですもの。 CodeZineさんの「アジャイル開発におけるテストとは？ その未来とは何か？【Agile 2018】」でも、AQA POP TALKの「探索テスターの未来？ テスト戦略モデル「INFORMATION」とは何か？ via ebayのセッションより」でも登場す
世界基準の認定資格「ISTQB テスト自動化エンジニア認定資格」をゲットしました！ | メルカリエンジニアリング
ロンドンは歴史豊富で、町並みの綺麗な所です！ こんにちは。メルカリのAutomation & QAグループ（通称：AQA）でAutomationエンジニアをぶりぶりしている@gloriaです。現在、私は主にiOSアプリの自動化を担当しています（詳細はtadashi0713によるこちらの記事をご覧ください）。 私は先月、ロンドンで開催された「ISTQB Advanced Level – Test Automation Engineer Certification」のトレーニングコースに参加しました。 ＊ なお、この記事は、@gloriaの原文（英語）を意訳しております。原文はこの記事の下部にありますのであわせてお楽しみください。 ISTQBとは？ この認定テストはISTQB Foundation Levelの延長線上にあるもので、ソフトウェアテストと品質保証の国際的なガイドラインを提供するも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
明日からはじめるテストのあるフロントエンド開発 ~ テスティングトロフィー ~
Model-Based Testing in React with State Machines | CSS-Tricks
Selenium alternatives everyone is talking about - Choose wisely! - Java Code Geeks
「質」のいいユニットテストを書くためのプラクティス / practices to write better unit test
1年間単体テストを書き続けた現場から送る Vue Component のテスト / Vue Component Test - Speaker Deck
