Autify Genesisは、生成AIを活用してプロダクトの仕様書からテストケース・テストシナリオを自動生成するソリューションです。
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
こんにちは。決済プロダクトでQAエンジニアをしているrenです。freee QA Advent Calendar2024の23日目です。 今回は、決済プロダクト開発にテストアーキテクチャを設計した事例について紹介します。 テストアーキテクチャとは テストアーキテクチャによって解決したい課題 テストアーキテクチャ設計のステップ 1. この振る舞いを担保するためには、どのようなテストが必要だろうか？という問いを立てる 2. 抽象化して考えるための概念を学ぶ 3. テストアーキテクチャを描き、議論する テストアーキテクチャ設計のインパクト 実装改善に関する気づき テストの構造とソフトウェアの構造に関する気づき 自分たちのテスト活動の課題に関する気づき チーム開発の支援を通じた工数上のインパクト テストアーキテクチャがもたらす価値 今後の展望 [appendix]今回設計したテストアーキテクチャの
この記事は 食べログアドベントカレンダー2024 の12日目の記事です🎅🎄 目次 目次 はじめに 自動テスト作成の課題 テストケースを考えることの難しさ テストコードに落とし込む作業の負担 テスト対象のコード例 RSpecでのテストコード例 自動テスト作成の課題がもたらす影響 生成AIと自動テスト 自動テスト作成の効率化を目指して 導入の条件 Difyを活用したチャットボット チャットボットの利用方法 テスト生成の障害 実装コードをそのまま送った場合の問題点 良い自動テスト生成が可能なケース プロンプトの工夫 プロンプトや対話の工夫では解決できないこと 設計の重要性 まとめ ロジックを切り出した対象での有効性 自動テストと設計の相乗効果 最後に はじめに こんにちは。食べログ開発本部 ウェブ開発2部 第1プロダクトチームで主にバックエンド周りの開発を担当しています、エンジニアの高田です
LangChainを使って色々LLMアプリを作って遊んでいます。 体感速度が遅いけど、どこが遅いかわからない サンプルソースをコピペして作ったので、実は中身のことをわかってない 入力と出力だけじゃなくて、中間の状態も知りたい みたいなことってありませんか？そんなときに使えるツールを見つけましたのでご紹介します。 環境構築の方法などは前回の内容を参照ください。 トークン数計算 Langfuseにはトークン数と価格を計算する機能があります。Bedrockのモデルの場合は少し設定が必要です。 Modelsメニューを開きます。 モデルごとの価格が設定されています。LangfuseのデフォルトではOpenAIのGPT-4やAnthropicのClaudeなどが登録されています。 モデル名の正規表現で対応するモデルがある場合にトークン計算が行われますが、Bedrockで使用できるClaudeの場合はマ
ジェネラティブエージェンツの大嶋です。 先日LangChainから、LLMアプリケーションのテストに関する決定版ガイド「The Definitive Guide to Testing LLM Applications」が公開されました。 LangChain公式によるXでのアナウンスはこちらです。 The Definitive Guide to Testing LLM Applications by LangChain Reviewing LLM app responses can be a time-consuming and daunting process, from defining criteria for style and accuracy, to spotting new regressions. After partnering with hundreds of compa
はじめに Mochaのフレームワークに従うテストコードの構造とコールバックに関する備忘録。基本ではあるが、理解していないと思わぬところで足をすくわれるかも知れない。(筆者も含めて) なんとなく使っているという人は、一度基本を確認して見るのも悪くはないかも。 Mochaとは何か そもそもの話として … MochaはJavaScriptを対象としたテストフレームワーク。 Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. https://mochajs.org テスト対象は、ローカルにある単体の関数からリモートのRest APIまで、テストコードから呼び出し可能な機能であれば何でも良
Motivation I started working with language models five years ago when I led the team that created CodeSearchNet, a precursor to GitHub CoPilot. Since then, I’ve seen many successful and unsuccessful approaches to building LLM products. I’ve found that unsuccessful products almost always share a common root cause: a failure to create robust evaluation systems. I’m currently an independent consultan
最近ChatGPTの人気がまさに爆発的です。ChatGPTは、知りたいことを入力すると、人間と会話しているかのように自然な答えが返ってくる対話型生成AI（人工知能）です。この対話型生成AIは業務効率化や生産性向上などのメリットがあることから、企業での活用事例も増えてきています。 ということで、ソフトウェアテスト業務でも使えるのではと思い、さっそく色々と試してみました。結論からいうと「活用方法は無限大で、どんな場面でも使えるもの！」、「どんな相談にも乗ってくれる優しい物知り」のような感じでした。ただし、結果（AIの答え）を信用しそのまま使うというよりは、補助的な手段として「参考にする」、「ヒントを得る」、「土台を作る」という程度で活用できればと思いました。また、そのまま使ってもいいくらいの答えであっても、専門家＆有識者によるレビューや事実関係確認があれば、もっともっと信頼できる形で活用できる
2024.6.29に行われた「開発生産性Conference2024」の登壇資料です。 https://dev-productivity-con.findy-code.io/2024
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 僕がやっている案件(PHP)はもともとテストコードのないレガシーなプロジェクトで、それを改善するためにずっと動作を確認するための結合レベルの自動テストを増やしてきました。 そんな中で、僕のところではどうやってテスト用のfixtureを管理しているか事例として紹介したいと思います。 最初にコアとなるfixtureを用意するみんながたくさんテストを作る前にコアとなるテスト用のfixtureは用意しておきます。 さもないと、みんなが好き勝手にfixtureを作ってしまい、あっという間に混乱に陥ります。 プログラム本体と同様に、DRYの原則で、同じようなテストデータを繰り返し作ってしまうよう
Merpay Tech Openness Month 2022の6日目の記事です。 こんにちは、Merpay Credit Design Teamでバックエンドエンジニアをしている@youxkeiです。 テストを書く際、その前提条件としてデータベースの状態をフィクスチャとして準備して、データベースにデータを投入することがよくあります。このフィクスチャはYAMLなどの外部ファイルに書かれることもありますが、この記事ではテストコード上にGoで記述する方法を考えていきます。 この記事では、データベースはリレーショナルデータベースを想定していて、具体例として架空の図書館蔵書管理システムのデータベースを使っています。 素直にモデルを使う 多くの場合、以下のようにデータベースのそれぞれのテーブルに対してモデルが定義されています。 package model import ( "time" ) type
1. テスト用の一時的なリソース作成の有無 Testsはテスト実行時に、テスト用のリソースを一時的に作成することができます。 上記の何が嬉しいかというと、直接リソースを作成しない(※)モジュールでテストが行いやすいです。 tfファイルを直接みる静的解析に比べて、ApplyやPlanを伴うテストの方が得られる情報は多いため踏み込んだテストができます。 呼び出し側でテストをする場合、関連するリソースの数が多く1回あたりの実行に時間がかかります。 全体に比べて作成するリソース数が少ないため、Testsはモジュール単位でテストを行うことに適しています。 ※ディレクトリで直接terraform applyを行わない。他tfファイルから呼び出して、リソースを作成する。 2. ライフサイクルの外側でのチェックの有無 Terraformの設定ファイルだけでは、ステータスがわからない項目もあります。 例えば
July Tech Festa 2020 TrackB https://jtf2020.peatix.com/
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。最後に、テストダブルとテストピラミッド、サイズダウン戦略について話します。 テスト用に使う偽物「テストダブル」和田卓人氏：じゃあ次。テストダブルの話にいきます。「忠実性と決定性のトレードオフを理解しよう」という点です。これはもうちょっとあとにまた出てきます。 テストダブルというもので、モックオブジェクトとかスタブとかを使って、本物ではない偽物をテスト用に使ってテストをすることはよくありますよね。 データベースの偽物とか外部システムの偽物とか、Amazonの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
