テスト自動化から、 開発を支える継続的テストへ2023-11-02 JaSST'23 Kyushu 招待講演 https://www.jasst.jp/symposium/jasst23kyushu.html 実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」
はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 （補足）本レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Tests Effectiveness 想定読者 フロントエンドの実装はできるが、テスト経験はない方 テストに対して解像度が低い方 これからテストを学びたいと思ってい
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」 - Qiita
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」JavaScriptテストフロントエンド はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 （補足）本レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Test
どうして統合テストは重要なんだろう？
はじめに 最近では、多様なテスト手法や開発者向けツールを散見します。 エンドツーエンド（E2E）テストだけでも、「Cypress」「Puppeteer」「Playwright」「Selenium」などのツールがあります。単体テストでは「Vitest」や「Visual Studio」のビルトイン単体テスト機能など、テストの準備を容易に自動化できます。 ですが、多様なテストツールを導入しても、「When」、「How」を押さえてなければ、テストの効果を有効に得ることができないと考えています。 まず、静的テスト、単体テスト、統合テスト、E2Eテストを実装コスト、実行時間と信頼性の観点で見ていき、無駄や漏れのないテスト戦略を立てていきましょう 。 テストを実装コスト、実行時間と信頼性で考える どのテストを使用するかの選択する観点として、テストをする実装コスト、実行時間と、テスト結果の信頼性のトレード
テストコードにはテストの意図を込めよう #vstat
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート（過去のJaSSTの講演資料などが載っています） ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
和田卓人さん（t-wadaさん）をお招きし、「質とスピード」の社内講演会を開催しました - STORES Product Blog
2022年6月7日に、テスト駆動開発者の和田卓人さんをお招きし、社内講演会をオンラインで開催しました！ 経緯 弊社では、2022年3月にテクノロジー部門のマニフェストとバリューができました。CTO 藤村が「和田さんの「質とスピード」のお話はテックバリューにも通じるところがあるのでは？」と思い、和田さんのお話をみんなに聞いてもらおうとお招きすることになりました。 結論：めっちゃ盛り上がりました 和田さんの講演会をアナウンスした時の盛り上がり 事前アナウンスでも盛り上がったのですが、当日はもっと盛り上がりました！ 和田さんのアドバイスを受けて、講演会専用のSlackチャンネルを作成したのですが、講演当日の投稿数は1,223！リアクション数は1,540でした！月に一度開催される全社レビュー会での投稿数が数百なので、桁違いの盛り上がりです。同時視聴数も200人を超え、エンジニアだけでなく、色んな職
E2E自動テスト導入・運用をめぐる先入観と実際に起きたこと / Preconceptions and What Happened with E2E Testing
Scrum Fest Niigata 2022 https://www.scrumfestniigata.org/
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
APIテスト自動化ツールKarateをBDDツールとして使う - まっつんの日記
Karateとは Karateは主にe2eテストを自動化するツール。cucumber的なfeatureファイルを書くとそれを実行できる。WebAPIのテストがその中心的ターゲット github.com graalvmのjsライブラリで実現しているっぽいので、featureファイルからJavaも呼べる。 個人的にBDDというのが結構いいと思っていて、ビジネスルールの仕様なんかをビジネスサイドと意識合わせする場合に使えると思っている。アンクルボブはFitnesseというツールを作っている。 FrontPage Fitnesseは名著『実践アジャイルテスト』でも紹介されていたもの 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践) 作者:Janet Gregory,Lisa Crispin発売日: 2009/
GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ
はじめに FLAKYの内容が今はっきりした！#JaSST— broccoli (@nihonbuson) 2018年3月8日 と書い（てしまっ）たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。 JaSST'18 Tokyoについては以下のページを参照してください。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo お知らせ この記事の内容を4/11に発表しました！ nihonbuson.hatenadiary.jp 発表スライドはこちら speakerdeck.com 目次 はじめに お知らせ 目次 Micco氏のお話 ICSTでの話 基調講演「Advances in Continuous Integration Testing at Google」 講演資料 テスト文化について (3ページ付近) 回帰テスト (4ページ付近) Mil
自動テストの効果測定に使われるEMTEとは？ - LIFULL Creators Blog
こんにちは！ LIFULLのSETエンジニアのRueyです！ 今年の3月にISTQBの自動化エンジニア資格 CTAL-TAE(Advanced Level Test Automation Engineer)を取得しました。TAEの勉強で自動テストの効果を測るメトリクスが幾つかあることが分かりました。その中で工数を測るメトリクスをEMTE(Equivalent Manual Test Effort)単位で表現することが推奨されています。しかし、その時は説明を見てもこれに換算すれば何か嬉しいか分かりませんでした。 ちょうどある開発グループで自動テストを導入する案件がありましたので、実際のプロジェクトでメトリクスを計測し検証してみました。様々な知見が得られたので、今回はこの単位の紹介と使用例を紹介したいと思います。 目次 はじめに 自動テストのメトリクス EMTEとは EMTEを使って表すことが
テストの説明に安易に「正しく」とか書かない - Object.create(null)
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
質とスピード（2020春版） / Quality and Speed 2020 Spring Edition
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
テスト駆動開発（TDD）とは何か。コードで実践方法を解説します - パンダのプログラミングブログ
この記事は、弁護士ドットコム Advent Calendar 2019 - Qiitaの2日目の記事です。 TL;DR TDDの実践方法を実際にコードを書いて解説します TDDの「レッド・グリーン・リファクタリング」のリズムを学ぼう 何度もテストを実行して、プログラムに対する不安を取り除こう TDDはテスト技法ではなく設計手法 TDD Boot Camp Sendai 9thに参加しました。TDDの伝道師和田さん（@t_wada）を講師に迎え、有志たちで開かれた勉強会でした。 午前中は和田さんによるTDDに関する講演とライブコーディング。午後は参加者同士のペアプロで出題されたお題を実装していく活気あるイベントでした。 イベントを通じてTDDはテストファーストのことだと考えていた自分は目を見開かされました。TDDは単にテストファーストでプログラムを実装することではなく、実装（ソフトウェア）が
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット）
はじめに ここまで、さまざまなソフトウェアテストの考え方や種類を紹介してきました。開発者がソフトウェアテストを活用していくなかで、「どのように問題を分割してすすめて行けば良いのか」と「どのようなテストケースを選択するのか」という2つの課題は筆者に多く相談がきます。 今回は、この2つの課題に対して、どのような方法で自らのスキルを上げて行けば解決できるのかを解説します。具体的には、前者には「Mikadoメソッド」を、後者には「テスト技法」を活用します。 筆者がよく耳にするソフトウェアテストの課題 開発者がTDDやテスト設計に取り組む際、筆者はよく次のような課題を耳にします。 どのように問題を分割するのか問題に対してどのようなテストケースを選択するのか 「どのように問題を分割するのか」とは、TDDやテスト設計において「開発対象をどのような問題に分割してテストを作れば良いのかわからない」といった課
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD with git. Long live engineering.
見てわかる テスト駆動開発
テスト駆動開発の過去・現在・未来 / History of TDD - XPJUG 2018 Keynote
