『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ！【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
本記事では、1日目におこなわれた『龍が如く7 光と闇の行方』（以下、『龍が如く7』）のデバッグに関するセッション“「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム”をリポート。 セッションには、セガのQAエンジニア・阪上直樹氏と、ビルドエンジニアの粉川貴至氏が登壇した。 バグをハグしたくなる自動システム！ まずは阪上氏が開発者たちへ向けて、「バグは好きですか？」という質問からセッションがスタート。最初に龍が如くスタジオの各タイトルで、バグを発見した数の推移が公開された。ゲームの規模が大きくなるにつれ、バグも増加傾向にあるという。 そして全自動バグ取りシステムを運用した『龍が如く7』では、なんと25000ものバグが発見されたという。こう見るとネガティブな印象を受けるかもしれないが、バグ発見数が多ければ多いほど、ゲームクオリティがアップするということだ。 バグとい
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
マイクロソフト、Webアプリのテスト自動化サービス「Microsoft Playwright Testing」プレビュー公開。クロスブラウザ／クロスプラットフォームのテストを並列実行
マイクロソフトは、Webアプリケーションのテスト自動化ライブラリ「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプレビュー公開を発表しました。 Microsoft Playwright Testingに使われている「Playwright」は、マイクロソフトが中心となってオープンソースで開発しているWebアプリケーション向けテスト自動化ライブラリです。対応環境が幅広く柔軟で、精度の高いテストを特長としています。 具体的には、Chrome、Edge、Firefox、Safariの主要なWebブラウザのすべてを対象にしたテスト自動化が可能で、ヘッドレス、ヘッドありのいずれにも対応。モバイルエミュレーションを用いたAndroid版Google ChromeとMobile Safariのテストも、実
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
CEDEC2020の講演資料です。 『「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム』 株式会社セガ 第1事業部 阪上直樹 / 株式会社セガ 開発技術部 粉川貴至Read less
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
こんにちは、Software Engineer in Qualityチーム(通称SEQチーム)の @teyamagu です。 私たちのチームは普段自動/手動テストの基盤開発や開発フィードバックサイクルの高速化に向けた開発をおこなっています。 その一環で、先日、社内でfreeeの自動テストシステム全体像を共有したのですが、この辺りのことを社外の友人達と話したところ、自動テストの具体的な構成や普段の運用など事例が少なく、どんなことをやっているのかイメージしにくいとの話を伺ったので、社内向け原稿をちょっと手直しして、おすそ分けと言うことで、ここで紹介します。 特に変わったことをおこなっているわけではありませんが、自動テストの関係性の理解に参考になれば幸いです。 基本的な考え方 自動テストが既存のデプロイ・リリースのブロッカーではなく、開発のフィードバックを加速させるために、自動テストそのものが高
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか？ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか？また、カオスエンジニアリングテストやアクセシビリティテストはありますか？ 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ
変更容易性と理解容易性を支える自動テスト（2024/02版） / Automated Test Knowledge from Savanna 202402 YAPC::Hiroshima edition
YAPC::Hiroshima 2024
この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは？ Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright
フロントエンドのテストをしよう Webのフロントエンドの自動化を進めようか。という話をしていて、 「そもそもテストってなんだ？」 「フロントエンドに特有のテストってなんだ？」 「〇〇ってツール流行ってるらしいってどうよ？」 みたいなことを話をしていました。そうしたときに、やっぱり知識足らねぇなぁ。と思ったので、2,3日でゴリゴリと内容をまとめてみる作業をしてみました。 あんまりこういう書き方はしないんですが、私自身散発的な思考で、フロントエンドのテストを調べることをしたので、そのような語り口で書いてみようと思います。 以下の内容は、あくまで例なので、別にこういう仕事があったわけではないです。 とりあえず投げられた要求・仕様 とりあえずなんか仕事が振ってきた。パラパラと要求を聞いてみると、こんな感じだった。 承認のダイアログが欲しい メッセージのフォントはOswald メッセージは変更できる
フロントエンドのテスト戦略について考える
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、FANTS におけるフロントエンドのテスト戦略について書きたいと思います。 🙋🏻♂️ はじめに みなさんはフロントエンドのテストを書いていますでしょうか？ 私が所属しているチームでは、今まで全体的なテスト指針が明文化されていなかったので、機能によってテストが書かれたり書かれなかったり、テストを書くにしても個人によって書く粒度にバラツキがありました。 直近でフロントエンドを書く人が増えていく / プロダクトがスケールしていくにつれて、そうしたバラツキによって生まれるコミュニケーションコストが大きくなってきたり、システム的な安全性を継続的に担保していくことが難しくなっていくように感じました。そのため、今まで方針を定めていなかったテスト戦略を、これから事業やプロダクト、チームがス
E2Eテストを Playwright で作り直して開発プロセスに組み込む話 - SmartHR Tech Blog
こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ
自動テスト速度改善 - 自動テストが品質のボトルネックとならないために - freee Developers Hub
freee人事労務の品質改善を専任で活動している keik です。 freee人事労務ではアプリケーション開発の自動テスト環境として CircleCI を利用しています。すべてのコードの変更は GitHub 上の Pull Request を経由して行われますが、Pull Request のマージ条件の一つとして自動テストをパスすることを求めるようにしています。 つまり、どんな些細な変更であっても、急ぎの変更であっても、リリースするためには基本的には自動テストの結果を待つ必要があります。一方で、コードベースは日々成長しており、それに比例して自動テストの実行時間も長くなっています。 ここに、ゆっくりと、ジレンマが生じはじめます。 品質を高める目的の自動テストだが、実行時間が長いと品質のボトルネックになりうる。 具体的には以下のようなシナリオが考えられます。 些細な改善が億劫になる（自動テスト
こんにちは。BacklogのGit機能の開発を行っているテリーです。 今回はGitチーム（後述する僕の所属するチーム）でAutifyによるリグレッションテストの自動化を進めてみて感じたメリットと工夫したところ、苦戦したところを紹介したいと思います。 スモールチームの規模感とテストの現状 BacklogのGitチーム 長らくBacklogは固定のチームが専任で固定の機能をみるような体制になく、アプリケーションエンジニアが比較的流動的にBacklog全体の機能を担当しており、なんとなく“この人”は“この機能”が得意というような体制でした。 ですが最近のチーム編成により固定のチームが固定の機能を開発するようなフィーチャーチームがいくつかできました。Gitチームはその中で生まれたBacklogのGitの機能についての開発責任を持つチームです。チームメンバーは3人で、そのメンバーでインフラからフロン
近年、ソフトウェアテストの自動化が一般的になり、多くの企業で導入が進んでいる。自動テストなしではもう、ソフトウェア開発は成り立たないと言ってもいいだろう。では10年後、テスト自動化はどのような進歩を遂げていくのだろうか。ソフトウェアテスト専門会社であるヒューマンクレストの取締役 浅黄友隆氏は、テスト自動化がこの10年間でどのように変わっていったのか、そして10年前と変わらなかったことを中心に語り、今後の自動テストについて語った。 株式会社ヒューマンクレスト 取締役 浅黄友隆氏 10年前といまではソフトウェアテスト自動化の認識が変わってきている ソフトウェア開発で欠かせないのがソフトウェアテストだ。10年前は、まず手動テストをつくり、それをいかに自動化するのかがソフトウェアテストの自動化だと考えられていた。浅黄氏が10年前に抱いていた自動テストのイメージも「人間の手で操作しているテストを自動
開発時の動作確認ツールとしてCypressのE2Eテストを導入した話 - visible true
ユビーAI問診は、Ubieが提供する医療機関向けのプロダクトです。患者さんに対して問診を実施し、医師向けのカルテを作成します。現在は大きく分けて、タブレットとスマートフォンの２つの利用方法があります。 タブレット用、スマートフォン用の画面 これらはどちらもWebアプリケーションとして実装していて、フロントエンドはReact/TypeScriptで書いています。 問診のプロセスは画面遷移が多い ユビーAI問診は紙の問診票で書くような定型的な質問だけでなく、来院した目的に合わせて様々な質問を行います。 例えば「頭が痛い」といった症状を入力した場合、発症時期や部位、痛みの程度、持続時間、経過、頻度などを掘り下げて、更にそれらの回答内容から疑われる疾患に関連する質問を重ねていきます。あるいは「足をひねった」など外傷に関する場合は、スポーツをしていたかや事故かといった状況を聴取したりします。問診の長
リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～ 2022-07-27 での講演スライドです。
こんにちは！ LIFULLのSETエンジニアのRueyです！ 今年の3月にISTQBの自動化エンジニア資格 CTAL-TAE(Advanced Level Test Automation Engineer)を取得しました。TAEの勉強で自動テストの効果を測るメトリクスが幾つかあることが分かりました。その中で工数を測るメトリクスをEMTE(Equivalent Manual Test Effort)単位で表現することが推奨されています。しかし、その時は説明を見てもこれに換算すれば何か嬉しいか分かりませんでした。 ちょうどある開発グループで自動テストを導入する案件がありましたので、実際のプロジェクトでメトリクスを計測し検証してみました。様々な知見が得られたので、今回はこの単位の紹介と使用例を紹介したいと思います。 目次 はじめに 自動テストのメトリクス EMTEとは EMTEを使って表すことが
MSW はネットワークレベルでリクエストをインターセプトする、自動テストで便利なモックサーバーです。過去記事でも紹介したとおり、スパイ（モック関数）をネットワークレベルに忍ばせることが可能です。実際に WebAPI が呼ばれた時の Payload の検証は、Jest 組み込みのモック機能では実現できない領域です。本稿は「WebAPI リグレッションテスト」を実施するための、MSW 活用方法を解説します。記事で使用しているサンプルコードはこちら。 課題の概要 Web アプリケーションページのほとんどは「1.UI を表示し／2.入力操作し／3.WebAPI 通信し／4.通信後処理を行う」という一連処理が責務です。このようなページに書かれるテストは、WebAPI 通信前後に集中しがちです。MSW を使用すると、以下の図の様に「送信後処理」まで到達可能なため、例えば「WebAPI レスポンスが返っ
ビジネスとコード品質の接合点 そしてコード品質がそこに及ぼす影響 / The Intersections of Business and Engineering, and The Impact of Code Quality There
2024-03-21 Findy TechBrew in 東京 https://findy.connpass.com/event/310772/
E2E自動テストサービスAutifyを導入しました - ROBOT PAYMENT TECH-BLOG
はじめに Autify導入前の状況と課題 初期（2016年頃〜2018年頃） 中期（2019年〜2020年） 現在（2020年〜） Autify導入時のススメ方 導入、運用時の工夫 Autify導入後の現状 今後について さいごに はじめに こんにちは。 請求管理ロボPMの田本（@tamotamo97）です。 今回はE2E自動テストサービスのAutifyを導入するに至った経緯と導入してからどうなったかを書いていこうと思います。 品質向上（ここでいう品質は主にシステム不具合）に関しての施策はどの会社でも色々な施策を実施されていると思います。 1ケースとしてご参考になれば幸いです。 Autify導入前の状況と課題 Webサービスに限らずシステムを運用していくに当たり、不具合はつきものです。 不具合にも色々ありますが、その中でも既存機能の不具合は新規機能よりも既存ユーザーに大きな影響があるため、
スタディサプリのコーチングサービス (合格特訓コース、個別指導コース) 開発チームで Engineering Manager をしている @pankona です。 最近弊チームで取り入れている Autify の良さについて紹介します。 TL;DR 弊チームでは最近 E2E テストとして Autify を便利に活用しています。 Autify の便利ポイントは以下。 E2E テスト構築が容易。非エンジニアでもある程度すぐに作れるようになる。細かいところは JavaScript や CSS セレクタを用いてエンジニアが補うこともできる。 多少 UI の見た目が変わってもテストが壊れにくい。UI の見た目が変わったことは検知することができ、問題ないと人間が判定することでテストが修復される。 チャットで質問を出すと結構すぐに返事がきて嬉しい。感謝。 Autify について Autify ランディング
こんにちは！エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyで社員代表（笑）をしている西岡（@TakeshiNishioka）です。 今回はスタートアップ企業の社員代表がどのような役割を担っているかを、この場を借りて紹介させていただきたいと思っています。 …というのは冗談で、今回は主に業務で携わっているプロダクト開発のプロセスや、QAまわりのお話をさせていただこうと思います。 前回に永井（@sho0910K）から紹介させていただいたATDDの話にも関係する内容になりますので、併せてご覧いただけると嬉しいです。 techblog.gaudiy.com プロセスやQAまわりお話といわれても「？」と思いますので、そもそもの前提からお話しします。 Gaudiyに求められる速度と品質 Gaudiyはいわゆるスタートアップといわれる企業ですが、事業ドメインがエンタメ領域というこ
ビジュアルリグレッションテストのすすめ
日々いろいろなWebサイトの制作や修正を対応していく中で、修正したページとは関係ない（と思っていた）ページで表示が崩れてしまったことってありませんか？ 私はたびたび経験があります。 毎回目視で全ページをチェックすれば防げるのかもしれませんが、それは現実的ではありません。 自動で全ページをチェックしてくれて不具合があれば教えてくれる、そんな便利なツールがあればと何度も思いました。 どうやら現代の技術でそれは作れるみたいです。ビジュアルリグレッションテストというらしいです。 ビジュアルリグレッションテストとは ざっくりいうと「見た目の比較」をするテストのことです。 変更前のWebサイトのスクリーンショットを用意しておき、変更後のスクリーンショットを撮り比較することで、どこが変わったか差分を表示し確認することができます。 どうやって使うの ビジュアルリグレッションテストを導入するための方法はいく
PythonでWindowsアプリを操作する（１）：環境構築と動作確認／RPAサンプル - SE_BOKUのまとめノート的ブログ
目次 Windowsのデスクトップアプリケーションの自動操作 WinAppDriverのインストール WinAppDriverの動かし方の確認 PythonのAppiumモジュールのインストール Appiumのサンプルプログラムで電卓を操作する Appiumの他の使い方はどうやって調べるのか？ アプリケーションの識別名や画面部品のID調べ方 調査用ツールのインストールと実行方法の確認 第二回目・第三回目のリンク Windowsのデスクトップアプリケーションの自動操作 Windowsのデスクトップアプリケーションを、Pythonから自動操作してみます。 ３回シリーズの1回目です。 今回のポイントとしては。 WinAppDriverのインストール WinAppDriverの動かし方の確認 PythonのAppiumモジュールのインストール Appiumサンプルプログラムで電卓を操作する 自動操
英語力と技術力向上のための海外Tech系Youtuber10選 +n こちらの記事へのオマージュ的な感じで・・・・ 1. Naveen AutomationLabs SDET / 自動化アーキテクトとして働く、Naveen氏によるYoutubeチャンネル。 本人曰く、Java, JMeter, Selenium-WebDriver, APIが大好き。とのこと。 豊富にコンテンツが揃っているが、個人的には Testing Mock Interviewシリーズ、模擬面接シリーズが面白く、興味深い。 Official site http://naveenautomationlabs.com/ 2. Automation Step by Step - Raghav Pal 自動化アーキテクト、自動化エンジニア、DevOpsエンジニアとして10年以上のキャリアを持つ、Raghav氏のよるYoutub
現在はまさしく、JavaScriptの時代と言えるでしょう。最近の2〜3年で、JavaScriptは最も人気のある言語ランキング1位を維持しており、今も急速に成長しています。10年前、Web標準という概念すらないときからフロントエンドの開発を続けてきた開発者にとっては、非常に感慨深いものがあるでしょう。当時は開発環境という言葉すら恥ずかしいほどに不毛な環境でしたが、現在流通している新しい技術と開発ツールを眺めてみると、まさに”豊かな時代”と言えるでしょう。 なかでも、特に有望なのは「テスト方法論とツールの発展」でしょう。この数年間、フロントエンドのテストは、はるか彼方にある幻想のようなものでした。従来のどのような方法を試してみても、フロントエンドのコードテストには適しておらず、テストコードを作成する努力に比べて、実際に得られる効果はわずかなものでした。しかし、最近登場したテストツールは、過
Autifyを活用したE2EテストとこれからのQA - LegalOn Technologies Engineering Blog
こんにちは、LegalForce CTOの時武（@tokichieto）です。 今日はLegalForceで行っている品質保証（QA: Quality Assurance）の取り組みについてご紹介します。 LegalForceでは、契約書のレビューや管理を行うためのSaaSを提供しており、サービスのユーザーとなるのは企業の法務部や法律事務所で契約書業務に携わる方々です。契約書を扱う業務システムという性質上、ユーザーから求められるサービス品質の期待値は高く、開発速度を落とすことなく期待に応えられるだけの品質を維持していく必要があります。 しかし、限られた開発メンバーの中でサービスを継続的に改善し、ユーザーに期待感を持たせながら高い品質を保ち続けるのはなかなか困難でした。2019年4月に "LegalForce" を正式版としてリリースした後、開発者の増加に伴って新機能を並行開発するケースも増
テスト自動化を始める前に、アジャイル・DevOpsチームが考えるべきこととは？ アジャイルテスティングの実現に向けた分析と戦略
本連載では、スピードと品質を両立するためのアジャイルテスティングにおける重要なキーワードである「テストの自動化」について、WebブラウザやAPIレベルのエンドツーエンドテスト（E2Eテスト、この連載でのテスト自動化は主にE2Eテストの自動化を指しています）が求められる時代背景から、戦略や戦術、組織づくり、ノーコード・SaaS型のAIを活用したテスト自動化サービスの進化と具体的な実装、ベストプラクティスを解説します。前回は、アジャイル開発やDevOpsが当たり前になった時代において求められるテストや品質について紹介しました。今回は、テスト自動化の戦略について考えていきます。 はじめに 前回は、アジャイル開発やDevOpsが求められる時代において、「アジャイルテスティング」の必要性について解説しました。今回は、テスト自動化をうまくすすめるための戦略を考えていきます。 テストと品質の現状分析 筆
ログイン読み込んでいます…
Storybook の Component Story Format 3.0 では新機能として play() 関数が追加されました。 play() 関数は Storybook 上でユーザーのクリックやフォーム入力のようなインタラクションな操作を表現できます。 以前は composeStories() 関数により Storybook 上で作成したストーリーを Jest で再利用する方法を書いたのですが、どうやら Storybook のみで完結してテストを実行できるようですのでこちらを試してみます。 Vite プロジェクトの作成 まずは以下コマンドで Vite プロジェクトを作成します。 $ npm init vite@latest my-vue-app -- --template vue-ts $ cd my-vue-app $ npm install Storybook のインストール 続
gTAAとは？ gTAAとは、generic Test Automation Architectureの略で、直訳すると「汎用テスト自動化アーキテクチャ」ですが、つまり何？かと言うと、 ソフトウェアのテストを自動化しよー！と考えた時、どんな...
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
(自分の) JavaScript のユニットテストの書き方
テストコード導入奮闘記～私はこうやってプロジェクトにテストコードを導入しました～ - Qiita
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
freeeの自動テストの全体構成 - freee Developers Hub
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
Webフロントエンドにおける網羅的テストパターンガイド
PlaywrightのVSCode拡張を使って効率的にテストを書く
あなたはフロントエンドの何をテストしたいのか。 - Qiita
スモールチームにおけるAutifyを用いた効率的なE2Eテストの自動化 | 株式会社ヌーラボ(Nulab inc.)
ソフトウェアの自動テストはこれからどう変わるのか――これまでの10年から考える【デブサミ2022】
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう
自動テストの効果測定に使われるEMTEとは？ - LIFULL Creators Blog
MSW を活用した WebAPI リグレッションテスト
Autify を導入したらなかなか良かった話 - スタディサプリ Product Team Blog
GaudiyがAutifyを導入して手戻りコストを削減した話 - Gaudiy Tech Blog
英語力とテスト力向上のための海外Testing系Youtuber4選 - Qiita
実用的なフロントエンドのテスト戦略（1） | NHN Cloud Meetup
20221119-アクセシビリティとE2Eテスト.pdf
Storybook 単体でインタラクションテストを実施する
Test-Hack | Knowledge and Technology in 3 minutes