タイミーでは、Flaky Test がデプロイの妨げになることで開発効率が悪化していました この問題を解決するため、AI エージェント「Devin」を活用し、Flaky Test の検出から修正プルリクエストの作成までを完全に自動化しました 結果、CIは安定し、開発者は本来の業務に集中できるようになったことで、開発体験が向上しました こんにちは！タイミーでバックエンドエンジニアとして働いている 福井 (bary822) です。 皆さんは Flaky Test に悩まされた経験はないでしょうか? タイミーでも、Flaky Test によって CI の信頼性が低下し、開発者の貴重な時間を奪ってしまうという課題を抱えていました。 ある期間においては master ブランチにおけるテスト実行の 4.5% が Flaky Test によって失敗しており、20+回/日 の頻度でデプロイされていることを
スクラム新潟2025でプレゼンしました。 https://confengine.com/conferences/scrum-fest-niigata-2025/proposal/21850/2025 グローバルなソフトウェアテストにかんするサーベイであるThe State of Testin…
こんにちは。SEQ (Software Engineering in Quality)のzakiです。 これまで、freeeのE2Eテストは、Selenium、RSpec、Capybara、およびSitePrismを基盤とするRubyのテストを、Jenkinsを用いて実行していました。この構成にはいくつか課題があったため、現在は PlaywrightをベースにしたTypeScriptのテストを、GitHub Actionsで実行する新構成への移行を進めています。今回はその内、JenkinsからGitHub Actionsへの実行基盤の移行について紹介します。 従来のE2E実行基盤の構成とその課題 現在のE2E実行基盤図 (Jenkins) これまでのE2E実行基盤はEC2上にJenkinsを構築し、その中でE2Eテストを実行していました。しかし、この構成には以下の課題がありました。 テスト
今や、AIを活用してソフトウェア開発すること自体は一般的になり、一種のブームと化している。 しかし、Web上で見かけるのはワンショットでテトリスを作る程度の小規模なプロジェクトの話がほとんどで、驚けるものの、正直あまり実用性は無いように感じる。 俺たちが本当に知りたいのはテトリスの作り方じゃねえ！現実の中規模以上のシステム開発で、いかに楽に良いものを作れるかだろ！ ということで、まずは弊社から現時点のノウハウを全公開しようと思う。 弊社ではCursorを1年以上活用（サービスがGAになったタイミングから全社員で利用）しており、一定のノウハウを蓄積してきている自負がある。ただ、あくまで一例ではあるので、ぜひみなさんの現場での活用事例も共有してほしい！ 免責事項AIエディタでの開発は、LLMとAIエディタの進化に伴い、常に変化している。 そのため、この記事で述べる方法論は、現時点での、弊社での
Terraform から LocalStack にデプロイする場合，以下のように provider.tf の provider 設定で LocalStack のエンドポイントを参照するように実装する必要がある💡 provider "aws" { region = "ap-northeast-1" access_key = "DUMMY" secret_key = "DUMMY" s3_use_path_style = true skip_requesting_account_id = true skip_credentials_validation = true skip_metadata_api_check = true endpoints { s3 = "http://localhost:4566" } } しかし LocalStack のために設定が必要なのは微妙だったりもして，そ
自分はDBをモックしてテストを行うのが嫌いですが、もし実際のDBを利用し並列実行する場合にポートやtruncate周りの問題が発生します。 今回は、それを解決するためにTestcontainersとVitestを利用したコードで解決します。 Testcontiners Docker社が買収したTestcontainersは、Dockerコンテナをテストで利用しやすくするライブラリです。 開発時にdocker composeを利用している人が多いと思うので、そこで利用しているcompose.yamlの定義をまんまテストで再利用できる点も便利かなと思います。 Testcontainers Testcontainers is an opensource library for providing lightweight, throwaway instances of common dat...
こんにちは。 苦しんでプログラミングを学んだ柴犬こと、くるしばです。 独学でプログラミングを学習し、Webサービス作りITベンチャーを起業しました。 その後個人開発したサービスを売却したり、また別のIT系の会社を創業したりしています。 下記のTwitterにてプログラミング学習に関して発信し、1.9万人以上の方々にフォローして頂きました。 また、最近はUdemyでReactとFlutterのプログラミング講座も出して、ベストセラーにも入っています。 初心者のうちは知らなかったが、学習を進めたり実務に入って経験が長くなってから 「こんな便利なものあったんだ...！」 となるツールってありませんか？ 僕はめちゃくちゃありました。 こういったツールは他の詳しい人から教えてもらうケースも多いので仕方がないのですが、もしこれらを初心者のうちに知ってたら色々楽だったのにな...と思うものが沢山あります
インフラ開発部でテックリードを務めております上畑です。 みなさんはAnsibleコードを修正した後に そのAnsibleコードを本番環境へ適用する際、ドキドキしていませんでしょうか? 前回、Ansibleをバージョンアップする記事を執筆し、大量のコード修正が必要になりました。 この記事では、ラクスがどのようにしてAnsibleコードをドキドキせずに本番に適用しているか、その仕組みを紹介します。 目次 目次 1. はじめに 2. DockerによるAnsible自動実行CIシステム 3. その他、CI環境の工夫 3-1. 本番環境Dockerイメージの最新化 3-2. CI実行時のエラー調査 3-3. CI/CDの並列実行を実現するコード化 3-4. 定期Dockerイメージの構築 4. 最後に 1. はじめに 一般的に、Ansibleコードを修正してマージする際には、以下のような事前チェッ
こんにちは！ アジャイルプロセス推進チームの日下（LINEヤフー株式会社）、岩井（LINEヤフー株式会社）、荒瀬（PayPayカード株式会社）です。私たちは、アジャイルコーチとしてPayPayカードのアジャイル開発を支援しており、現在E2E自動テスト（以下、E2Eテスト）の導入を進めています。この導入における戦略、直面した課題、そしてそれらをどのように克服したかについてお話しします。組織にこれからE2Eテストを導入しようと検討している方や、既に導入済みで安定稼働や運用に課題を抱えている方にとって、お役に立てれば幸いです。 また、私たちアジャイルコーチはLINEヤフー株式会社およびPayPayカードのものづくりに深く関わり、プロセス改善や仕組み作り、最新技術の導入を行っています。過去の事例は以下のリンクからご覧いただけます。 SWAT×Agile Coach: 異なるスキルが共創するまでヤフ
『ゼルダの伝説 ティアーズ オブ ザ キングダム』のスクラビルドは開発時に12万通りをチェック。「ムリでは？」の空気を分解する仕事術【CEDEC2024】 国内最大規模のゲーム業界カンファレンス「CEDEC2024」が、2024年8月21日（水）から8月23日（金）までの日程で開催されました。 初日の8月22日（木）には、任天堂 企画制作部の『ゼルダの伝説 ティアーズ オブ ザ キングダム』のチームから、ディレクターの藤林 秀麿氏とゲーム開発インフラ担当の廣瀬 賢一氏が登壇。「『ゼルダの伝説 ティアーズ オブ ザ キングダム』のスクラビルドができるまで ～準備のために準備する～」と題した講演を行いました。 主人公・リンクが使う武器などに素材をくっつけられる能力「スクラビルド」は、その組み合わせの数が膨大となり、開発には困難を伴います。 その実現過程を通じて、問題解決の方法やチームとのコミュ
こんにちは。SEQ (Software Engineering in Quality)のnakamuです。 freee QA Advent Calendar2024 11日目です。 これまで、freeeのE2EテストツールはSelenium+RSpec+Capybara+SitePrismをベースにした独自基盤を利用してきました。 この基盤は、2016年からページオブジェクトモデルを採用し、今日に至るまでE2Eテストの保守および運用を支えてきました。 今年度からは、Playwrightを基盤にした新しいE2Eテスト環境への移行を推進しており、新基盤でも引き続きページオブジェクトモデルを使用しています。 そこで今回はページオブジェクトモデルに関連する実装の工夫点について紹介します。 注意点 コード例はPlaywright + TypeScriptを想定しています。 ページオブジェクトモデルと
こんにちは。QAエンジニアをしているharashinです。 freeeプロダクト共通で利用される従業員情報や取引先などのマスターデータを扱うプロダクトを担当しています。 freee QA Advent Calendar2024 1日目です。 adventar.org 去年に引き続き、QA Advent Calendar2024の発起人です。 今年も無事QAエンジニアだけでアドベントカレンダーを実施できることを大変うれしく思います。 去年のアドベントカレンダーを実施するにあたり、多くの方に圧をかけた結果、社内ではharashin とハラスメントがかけ合わさったハラシンメントという造語が作られました。 harashin とハラスメントがかけ合わさったハラシンメントという造語 今年は、「テストレシピをやってみた」というタイトルでアドベントカレンダーを書いてみようと思います。 チームのQAに関する
この記事は、負荷テスト初学者向けの記事の第 1 回として『負荷テストとは？』『AWS上での負荷テストの方法』を解説しています。 次回の記事以降にて、「 Distributed Load Testing on AWS 」を利用して実際に負荷テストを実施するまでの試験計画〜実施までの流れを解説します。 こんにちは！エンタープライズクラウド部クラウドコンサルティング課の日高です。 もし私のことを少しでも知りたいと思っていただけるなら、私の後輩が書いてくれた以下のブログを覗いてみてください。 sabawaku.serverworks.co.jp はじめに 負荷テストの基礎 負荷テストとは何か 処理量（スループット） 処理時間（レスポンスタイム） Tips: レスポンスタイムを平均値ではなく統計的に見る理由 なぜ実施するのか 定義 負荷テストの進め方 全体像 試験計画 試験準備 試験実施 結果評価
株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションを掲げた、医療系のスタートアップです。現在は薬局向けのSaaSを主軸としたビジネスを行っており、多くのエンジニアがチームを組んで開発に取り組んでいます。その開発チームのひとつ「yabusame」は、特徴的なチーム編成もあって社内外で注目を集めています。 メンバーの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さん、種岡篤志さん、平松拓（@hirataq__）さんは、それぞれが開発チームをリードできる高い技術力やマネジメント能力だけでなく、細やかな対人スキルや広い視座でメンバーの関係性を捉える能力を備えたシニアエンジニアでありながら、同じチームのメンバーとして開発に取り組んでいます。 日本の古式弓馬術である流鏑馬(やぶさめ)から「変化が速い中を駆け抜けて、的確にゴール
はじめに こんにちは。newmoでソフトウェアエンジニアをやっている@tenntennです。 newmoには2024年8月に入社しました。この記事を書いているのは2024年9月なので、入社してだいたい1ヶ月ちょっとが経過したところです。 なお、筆者が入社した経緯などは次の記事を読んでください。 note.com 入社した当初、newmoのバックエンドコードのコードを眺めていると、次のように宣言された関数を見つけました。 func Now(_ context.Context) time.Time { return time.Now().In(time.UTC) } 単にtime.Now関数を呼び出して、LocationをUTCに設定しているだけです。 しかも、引数はブランク識別子になっているので使用していません。 しかし、筆者はこれを見て、これは後々のことを考えているなと感心しました。 ちな
この記事は、CYBOZU SUMMER BLOG FES '24 (Frontend stage) DAY13 の記事です。 こんにちは、フロリアでエンジニアとして活動している hacchan です。 現在 kintone ではフロリアというプロジェクトの中で、Closure Tools から React への移行作業に取り組んでいます。 以前、そのフロリアのチームの 1 つである Reactone チーム が Storybook をフル活用してテストを実装した話 を紹介しましたが、今回はそのアフターストーリーを紹介します。 Storybook のフル活用はやめた 以前の Reactone チームでは、Storybook の Test Runner を使って、Integration Test を実行するなど、Storybook をフル活用してテストを実装していましたが、新たな領域の刷新を開
読んでよかった book.mynavi.jp 評判通りよかった そっかーなるほどなぁ。面白いなぁ。と思うことがいろいろあった とはいえ、著者の主張全てに同意というわけではなく「著者はそう考えるんだな。自分は違う考えだな」と考えさせられる部分もいくつかあった 苦手な部分もあった 古典学派とロンドン学派に分けて話を展開しているのはあまり好きじゃないなと思いながら読んだ 定理やマトリクスに当てはめて話を展開する部分があって、いくつかは無理やりだったり話をややこしくしていたりするように自分は感じた。そういう部分は苦手だなぁと思いながら読んだ というのが全体の感想。内容はとてもよかったし、苦手な部分もそれはそれで考えさせられたので、読んでよかった。ってことでパラパラめくりながらメモを書いていこう あらためて意識したい2本 「第4章 良い単体テストを構成する4本の柱」の中の2本が、当たり前のことではあ
Last time, we saw how deleting stuff from a test case can be an easy and fun route to the root cause of a bug. It’s less easy and less fun when the test cases get big. The inner loop of test-case reduction can get old quickly: delete stuff, run the special command, check the output to decide whether to backtrack or proceed. It’s rote, mechanical, and annoyingly error prone. Let’s make the computer
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発（以下、TDD）のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
