この記事は「 MEDLEY Summer Tech Blog Relay 」11 日目の記事です。 はじめに こんにちは、メドレーでAI推進している人材プラットフォーム本部 VPoE の倉林( @terukura )です。 前回の記事「 AI for All - 全社でAI活用を推進する取り組み 」でお伝えした通り、メドレーでは「AI for All」を合言葉に、全社的なAI活用を推進しています。あれから約4ヶ月が経過し、プロダクト開発チームにおけるAI活用は大きく前進しました。 本記事では、メドレーのプ

日々増加するテストケースの管理に頭を悩ませていませんか？ 手作業でのデータ入力や、テストスクリプトに直接データを書き込む「ハードコード」方式では、メンテナンスが困難になり、テスト自動化のメリットを十分に享受できないこともあります。 このような課題を解決する手段として今、注目を集めているのが「データ駆動テスト」です。 そこで今回はデータ駆動テストの基本的な概念から、具体的な実装方法、メリット・デメリット、そして明日から実践できる導入手順まで、ソフトウェアテストエンジニアが知っておくべきポイントを網羅的に解説

2025年8月の主な製品アップデートをご紹介します。 製品アップデート ダッシュボードからインスタンスデータへのドリルダウン バーグラフ、円グラフ、分布表などのダッシュボード項目をクリックして、特定のインスタンスデータを直接参照できるようになりました。例えば「特定のテスターが担当した Passed のインスタンス」を選択すると、自動的に「Test Sets & Runs」モジュールのインスタンスビューに遷移し、クリックした条件でフィルタリングされた結果が表示されます。 マイルストーンベースのトラッ

はじめに

帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3

はじめに こんにちは。最近ジムに通い始めてダイエットをしております、25卒の桑原です。 今回は、Distributed Load Testing (以下 DLT と略 ) ソリューションをデプロイするための手順書になります。 CloudFormationテンプレートを利用してDLTソリューションをデプロイしていきます。 01.DLTソリューションのデプロイ 01-01. CloudFormationスタックのデプロイ ①ブラウザで新しいタブを開き、 分散負荷テストの Web ページ にアクセスします。 h

テストエンジニアのユッキーです。 普段は自動化担当部署で、お客様のテスト自動化導入をご支援したり、社内の自動化技術の研究開発に携わっています。 皆さんの周りでも、「AI」という言葉を聞かない日はないのではないでしょうか。ある調査では、2024年のソフトウェア開発トレンドの第1位が「生成AI」で、半数以上の開発者が実際に導入しているという結果も出ています 。この大きな波は、私たちテストエンジニアの仕事にも確実に押し寄せています。 しかし、「AIがテストを自動化する」という言葉だけが先行し、具体的に「何が」「

創業期からSHIFTの成長を支えてきたソフトウェアの品質保証事業。これまで取り組んできたテストケースは1億1,451万件以上（※2025年1月時点）にのぼります。 この膨大なテストデータを活かすべく手がけているのが、 テスト設計ツール「TD AI Assistant」 です。生成AIによるテスト設計の高速化・高品質化を目指しています。

創業期からSHIFTの成長を支えてきたソフトウェアの品質保証事業。これまで取り組んできたテストケースは1億1,451万件以上（※2025年1月時点）にのぼります。 この膨大なテストデータを活かすべく手がけているのが、 テスト設計ツール「TD AI Assistant」 です。生成AIによるテスト設計の高速化・高品質化を目指しています。

創業期からSHIFTの成長を支えてきたソフトウェアの品質保証事業。これまで取り組んできたテストケースは1億1,451万件以上（※2025年1月時点）にのぼります。 この膨大なテストデータを活かすべく手がけているのが、 テスト設計ツール「TD AI Assistant」 です。生成AIによるテスト設計の高速化・高品質化を目指しています。

本稿は、2024 年 11 月 29 日に公開された “ Faster scaling with Amazon EC2 Auto Scaling Target Tracking ” を翻訳したものです。 はじめに AWS クラウドの主な利点の 1 つは弾力性です。これにより、ユーザーは必要なリソース分だけをプロビジョニングして利用できます。ユーザーは弾力性の利点を最大限に活用するために、自動化された幅広く簡単に操作できるメカニズムを必要としていました。 Amazon EC2 Auto Scaling は、

はじめに - Vol.16 本記事では、IPA[1] が公開する 非機能要求グレード[2] の「A.3 災害対策」と「A.4 回復性」を対象に、 金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。 筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。 シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。 A.3 災害対策A.4 回復性 中項目「A.3 災害対策」では、いわゆる災害対策に関連する

開発の現場では、教科書通りの定義だけでなく、プロジェクトやチーム独自のテスト手法が用いられることも少なくありません。 そんな中で、特に混同しやすいのが「サニティテスト」と「スモークテスト」です。 そこで今回は開発プロセスにおけるサニティテストの役割や、スモークテストとの違い、そのメリット・デメリットについて網羅的に解説します。 この記事を読めば、サニティテストの正しい知識が身につき、自信を持ってテスト作業を進められるようになるでしょう！ import haihaiInquiryFormClient fro

エンタープライズのコンタクトセンターでは、独立した IT および運用チームを持つ複数の事業部門 (LOB) をサポートするのに苦労しています。特にビジネスプロセスアウトソーサー (BPO) では、独自の要件を持つ数百の顧客を管理するため、この複雑さがさらに増大します。コンタクトセンターの移行パターンにより、これらの課題に対処し、デプロイメントを加速し、運用を簡素化することができます。 この投稿では、中規模から大規模なコンタクトセンターの移行において堅牢な基盤を構築する、実証済みの 5 つのパターンについて

ソフトウェア開発において、品質の高いプロダクトを効率的に提供することは、どのチームにとっても重要な課題です。 特に新しいビルドが頻繁に作成されるアジャイル開発の現場では、そのビルドが安定しているかどうかの確認を迅速に行う必要があります。 そんな品質保証の「入り口」として欠かせないのが、スモークテストです。 このテストは開発プロセスの初期段階で、致命的な欠陥がないかを短時間でチェックすることで、後工程での手戻りを防ぎ、プロジェクト全体の生産性を飛躍的に向上させます。 そこで今回はスモークテストの基本的な知識