「龍が如く」も「スーパーモンキーボール」も自動化！クオリティエンジニアリングチームによるマルチゲームエンジン対応で進化した「龍が如くスタジオ」のテスト自動化環境についてCEDEC2024の講演資料です。 『「龍が如く」も「スーパーモンキーボール」も自動化！クオリティエンジニアリングチームによるマルチゲームエンジン対応で進化した「龍が如くスタジオ」のテスト自動化環境について』 株式会社セガ 第１事業部 並木 勇人 / 株式会社セガ 第１事業部 桑原 和人 /…
E2Eテストの部分実行によるテスト時間短縮 - Cybozu Inside Out | サイボウズエンジニアのブログ
この記事は、CYBOZU SUMMER BLOG FES '24 (kintone Stage) DAY 1の記事です。 初めに kintoneチームの前田です。 kintoneチームでは最近E2Eテストを部分的に実行するという実験を始めています。 これによりテストの実行時間が短縮されフィードバックが迅速になり、 たとえばフロントエンド刷新に貢献するのではないかと期待しています。 本記事ではこのE2Eテストを部分的に実行するという取り組みについて紹介します。 E2Eテストと問題点 kintoneチームのE2Eテストは機能が期待通り動いていることをユーザー視点で確認するテストです。 E2EテストはSeleniumとJavaで実装されています。 試験対象であるkintoneは本番環境とほぼ同じ構成で開発環境にデプロイされ、これに対してテストが実行されています。 kintoneチームでは通常機能
生成AIでソフトウェアテストはどう変わる？ 和田卓人氏、川口耕介氏、近澤良氏が語る
ソフトウェアテストの自動化やローコード・ノーコードツールへのAI技術導入が急速に進んでいる。とはいえ、生成AIはいまだ研究段階にあり、日本でも海外でも有効な活用方法を模索している途上にある。本セッションでは、ソフトウェアテスト領域のトップランナーである3人、Launchable,Inc共同社長の川口耕介氏、プログラマでテスト駆動開発者の和田卓人氏、オーティファイ株式会社代表取締役 CEOの近澤良氏が、生成AI時代のソフトウェアテストの現状と課題、これからの展望について語った。 海外と日本のソフトウェアテストの現状 アメリカに住み、20年間アメリカのソフトウェア開発現場を見続けてきた川口氏は、「故郷に錦を飾りたい」という思いから、日本でもJenkinsやDevOps、ソフトウェアテストのような取り組みを進めていきたいと考えている。しかし、取り組みの中でいろいろな難しさを感じ、日本と海外のソフ
オープンソースのメーラー「Thunderbird」の開発チームが「バグを減らす開発手法」を解説
メールソフト「Thunderbird」では、ソフトウェアの品質向上のために開発チーム内で日常的に自動テストが実行されています。その理由や手法についてThunderbirdの開発チームが解説しています。 Automated Testing: How We Catch Thunderbird Bugs Before You Do https://blog.thunderbird.net/2024/04/automated-testing-how-we-catch-thunderbird-bugs-before-you-do/ ◆自動テストの目的とメリット Thunderbird開発プロジェクトではコードの変更によるバグの発生を最小限に抑えるために「自動テスト」が重視されています。開発チームによると、、Thunderbirdのコードや機能に変更が加えられるたびに、Windows、macOS、Li
高速道路の出口案内のようなQAエンジニアでありたい ─自動テストより前にやるべきことがあると気づいた話 - Findy Engineer Lab
皆様こんにちは。QAエンジニアのブロッコリーこと風間裕也（@nihonbuson）と申します。私は本業で株式会社10XのQAエンジニアとして勤務する一方、副業としてB-Testingを開業し、さまざまな会社でQAに関する相談に乗ったり、登壇や執筆活動を行っています。 また社外活動として、WACATE（ソフトウェアテストの合宿型ワークショップ形式勉強会）の実行委員長や、ソフトウェアテスト技術振興協会（ASTER）の主催するJaSST Review（ソフトウェアレビューのシンポジウム）の実行委員長を務めています。 本記事では、私がどうしてQAエンジニアというキャリアを歩んでいるのか、そして品質保証（QA、Quality Assurance）という分野でどのように開発チームと協調しながら開発してきたのかをお話しします。 筆者近影 学術と企業のギャップに驚いてテストの浸透に動く テスト技術に磨きを
エンジニア1人で4年間プロダクトを開発。ミニマムな体制で効率的な価値検証を行う知見 - what we use（技術スタックデータベース）
「サービスがPMFするまで、どのような体制で開発を進めるか」というテーマに、わかりやすい正解は存在しません。企業の創業メンバーの内訳や各々のスキル、会社の資金、世の中や他社の動向など、さまざまな変数が「開発組織のあり方」に影響します。CTOやVPoEといった企業の技術リーダーたちは、そうした変数を鑑みつつ自社の方針を決める重要な役割を担っています。 営業活動支援のSaaS事業およびコンサルティング事業を展開するSALESCORE株式会社のCTOを務める成澤克麻さんは、MVP開発開始から4年間は「エンジニア1人でフルスタックにサービス開発すること」を選びました。そして事業が軌道に乗った現在は方針転換をし、人を増やしながらスケール可能な体制作りを目指しているのです。今回は成澤さんに、SALESCOREがこれまで選択してきた開発組織の方針について聞きました。 KPIを可視化し、営業組織の実行力を
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog
FindyでEMをしている栁沢（@nipe0324a）です。 今回は、FindyのとあるRailsのCIのテスト実行時間を10分から5分に高速化した話をご紹介します。 「CIのテスト実行時間が遅い...」 「CIの実行時間を短くしたい!!」 と感じている方はぜひご覧くださいませ。 Findyでは2024年2月現在、1人あたり1日4プルリクを平均で作っています。静的解析や自動テストなどを即時に行うCI環境がないとスピード感のある開発ができなくなるため、CIを高速で回しタスクを完了させる必要があります。機能も増え、テストケースも拡充したことでCIの高速化が求められるようになりました。 また、個人的には、CIは遅くても10分、理想は5分以内で終わるのを1つの目安にしています。これぐらいのスピード感でCIが完了すると、「プルリク作ってレビュー依頼する」、「レビューコメントもらって対応する」といった
Goのテスト安定性向上のためにFlakyなテストを再試行する機能を導入する提案 - tomato3713’s blog
Go言語にFlakyなテストへのサポートを追加する提案が面白かったので紹介します。 概要 Flakyなテストとは、コードに変更がないにもかかわらずテストが成功したり失敗したりと不安定な実行結果になるテストのことです。 テスト結果は本来なら全て成功ならリリース可能、1つでも失敗すればバグがあるのでリリース不可のようにリリースの可否を判断するための情報です。 そのため、不安定なテストは書かないようにすることが大前提です。 しかし、実際にはflakyであるとわかっていても修正が難しかったり、修正するための時間がないのでそのまま残すという判断をすることもあります。 Flakyなテストは削除するというのも手ではありますが不安定であってもテストが無いよりはマシとして残すこともあると思います。 github.com この提案では、Flakyなテストを扱うための機能を追加するものです。 初めの提案内容は、
ZennのE2Eテスト基盤をリプレイスしました（開発体験向上、CI時間の短縮、Playwright移行）
はじめに 2023年にZennチームにJoinしたdyoshikawaです。 このたびZennのE2Eテスト基盤をリプレイスしました。このような下回りの改善はユーザへの価値提供との距離が近い機能開発と比べてどうしても後回しになりがちな中、Publication Proという大きなリリースを迎えて少し開発が落ち着いたタイミングであり、E2Eテストを拡充できる土台を整えることで今後より安心して機能を追加していけるようにするために必要だということで実施しました。 各テストを独立実行可能にすることによる開発体験向上、CI（GitHub Actions）の実行時間短縮、そして将来を見据えてのCypressからPlaywrightへの移行を行いました。 本記事ではリプレイス前に抱えていた課題、それに対して打ち出した解決方針、そして具体的にどんなことをやったのかを紹介します。 抱えていた課題 前提として
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
MysqlRewinder という gem を作った | BLOG - DeNA Engineering
gem の概要 database_rewinder という gem があります。 これを使うとテストケースを実行するたびに DB の中身が初期化されて、しかも超速いというすごい gem です。 弊社でもヘビーユースさせていただいていたのですが、あるプロダクトの自動テストにおいて適切にデータが初期化されないケースがあり、 Flaky test の原因となっていました。 今回ご紹介する mysql_rewinder は、この問題を解決するために database_rewinder の代替を目指して開発した gem です。 使用例 Ruby on Rails / RSpec と組み合わせる場合、以下のように利用します。 RSpec.configure do |config| # MysqlRewinder の初期設定 config.before(:suite) do db_configs = A
RustでTestcontainers入門: テストコードから依存サービスを起動してテスト環境を作成する - kymmt
この記事はRust Advent Calendar 2023 シリーズ1の4日目の記事です。 あるソフトウェアをテストするとき、そのソフトウェアがデータベースやメッセージブローカのような外部のサービスに依存する場合に、その依存をどのように扱うかという問題がつきまとう。この問題へのよくある解決策としては 依存サービスを差し替えられるような設計にして、テスト実行時はモックに差し替える Docker Composeなどであらかじめ依存サービスをテスト用のコンテナとして立ち上げておき、テスト実行時はそれらのサービスが動くコンテナにアクセスする などが挙げられる。 今回はさらに別の方法として、テスト実行時にテストコードの中から依存サービスをコンテナとして立ち上げるためのフレームワークであるTestcontainersを紹介する。また、RustでTestcontainersを使うときの実例を紹介する。
そのテスト、最後まで実行されていますか？ jestとnpm-run-allの恐るべき罠
皆さんこんにちは。この記事では、筆者が最近業務中に経験した恐るべき罠についてシェアしたいと思います。 CIでユニットテストを実行することは、とても多くのプロジェクトで行われています。ユニットテストは特に、既存のコードの変更を自信を持って行うために必要なものです。弊社でも、CI (GitHub Actions) でユニットテストを実行しています。 あるとき、CIの挙動が不安定になったことをきっかけに、CI上でのユニットテストの実行について調べてみました。その結果、とんでもないことが判明したのです。 不安定になったCI 時折、CIにすごく時間がかかり、30分経ったあたりでタイムアウトしてしまうことがありました。そのときのログを見てみると、jestによるユニットテストが実行されている最中に、何のログも出力せずに突然止まっているようでした。そのようなときはリトライするとそこそこの確率で成功します。
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
【書き起こし】1週間リリースを支えるAndroid自動テスト運用のその後 – Kenta Takahashi / Shintaro Miyabe【Merpay & Mercoin Tech Fest 2023】 | メルカリエンジニアリング
Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「1週間リリースを支えるAndroid自動テスト運用のその後」の書き起こしです。 @kenken：それでは、「1週間リリースを支えるAndroid自動テスト運用のその後」について発表します。 簡単に自己紹介をします。 @kenken：メルペイAndroidチームの@kenkenと申します。2021年5月にメルペイへ入社しました。現在はメルペイのあと払いをはじめとした、与信領域の機能開発やリグレッションテストの自動化などを担当しています。 @shinmiy：
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
単体テストを書かない技術 #phpcon_odawara
Talk about CI and testing of the STORES
テスト自動化から、 開発を支える継続的テストへ
Androidアプリの良いユニットテストを考える / Thinking about good unit tests for Android apps
