ソフトウェア開発におけるユーザー視点を重視したユースケース駆動開発を基にしたテスト設計手法について説明しています。ユースケースの構成要素をテスト観点に展開し、ユーザー操作に即した網羅的なテストケースを作成する方法とそのメリット、注意点を解説しています。

本記事は 2026 年 1 月 15 日 に公開された「 From AI agent prototype to product: Lessons from building AWS DevOps Agent 」を翻訳したものです。 re:Invent 2025 で Matt Garman は、インシデントを解決し、事前に防止することで、信頼性とパフォーマンスを継続的に改善するフロンティアエージェントである AWS DevOps Agent を発表しました。DevOps Agent チームのメンバーとして、

ソフトウェアテストの研修でテスト技法を学んだとき、「状態遷移図」は比較的理解しやすい技法だと感じていました。 状態と状態を線で結ぶだけで、画面や処理の流れが整理できる。 しかし、いざ実務で使ってみると、研修では見えていなかった“つまずきどころ”がいくつも浮かび上がってきました。 そこで今回は、テスト初心者である私が、状態遷移図を実務に適用する過程で特につまずいたポイントを整理します。 ※本記事は株式会社モンテカンポの新人スタッフが記録したレポートを元に、記事として編集しなおしたものとなります。 参考： テ

このシリーズは、私自身の「初心者研修記録」をもとに、研修で学んだテスト技法を実務でどのように活用したのかを記録したものです。 今回はその中から、実務で初めてテスト技法を意識的に活用した取り組みとして、「状態遷移図」を用いた検証の記録を整理し、記事としてまとめました。 私自身、ソフトウェアテスト受託業務の企業に就職してまだ3カ月ほどであり、ソフトウェアテストに関しては社内研修で学んだ知識しか持っていない状態でした。 実務経験がほぼない中で、研修で学んだテスト技法をどのように業務に落とし込んだのか、その過程と

システム開発におけるテスト工程の重要性と、機能テストおよび非機能テストの種類と目的について説明しています。各テストの具体的な内容とその役割を紹介しています。

今回は、タイミーの「 Kaigi Pass 」制度を利用して、12/4に開催のされたプロダクトマネージャーカンファレンス（以下、pmconf）に参加してきました。 この制度を通じて、非常に有意義な学びを得ることができましたので、その内容を共有します。 参加セッション 「メルカリのデータ分析AIエージェント『Socrates（ソクラテス）』と、それを支えるデータ整備」 登壇者：株式会社メルカリ データアナリティクスチーム セッション詳細・学び 1. 背景と課題 (As-is) メルカリでは専任のデータアナリ

急成長を遂げる事業において、海外展開は避けて通れない大きな一歩です。 しかし、複数のプロダクトやマイクロサービスが並走するメガベンチャーの現場では、各チームでテスト方針や品質基準がバラバラになり、思わぬ手戻りやブランド毀損のリスクに直面することも少なくありません。 特に「ローカライゼーション」は、単に言葉を置き換えるだけの作業と誤解されがちですが、その実態は「特定の市場でプロダクトが自然に受け入れられる状態」を保証するための極めて戦略的なプロセスです。 そこで今回はQAマネージャーや品質推進リードが、部分

急成長する開発現場において、チームごとにテスト方針や品質基準が異なり、思わぬ障害や手戻りに頭を抱えるケースは少なくありません。 個別最適の積み重ねだけでは組織全体の品質を担保するのに限界が見え始めている場合、必要となるのは論理的かつ客観的な品質の物差しです。 国際標準規格であるISO25010は、単なる用語の定義集ではなく、プロダクトの価値を最大化し、組織横断で品質を議論するための強力なフレームワークとなります。 そこで今回はこの品質モデルをどのように実務のテスト設計やCI/CDパイプラインへ組み込み、事

はじめに 実施したミニユーザビリティテストの目標とステップ ステップ1：自分を初見ユーザーと想定してサイトを触り、直感的に気になった点を洗い出す ステップ2：具体的なユーザー像と状況を設定し、その立場でサイトを操作して問題点を抽出 ステップ3：生成AIに簡単なタスクを作ってもらい、タスクを行う中で問題点を抽出 まとめ はじめに こんにちは！社会人3年目の小澤です。 前回の記事からおよそ2年が経ちましたが、相変わらずミッフィーが大好きです。 この1年半は、保守・運用案件やリニューアル案件に携わってきました。

.entry .entry-content .table-of-contents > li > ul { display: none; } はじめに こんにちは、検索基盤部検索研究ブロックの小倉です。普段はZOZOTOWNの検索精度改善を担当しています。検索研究ブロックでは2020年から検索結果の「あなたにおすすめ順」（以降「おすすめ順」と呼びます）とその改善に取り組んできました。その過程で「これまで積み重ねてきた改善は、トータルでどの程度効果があったのか？」を確かめるために、ネガティブテスト（最新のロジ

急成長を続けるメガベンチャーの開発現場において、マイクロサービス化によるシステムの複雑肥大化は、従来の品質保証を困難にしています。 ステージング環境で本番を完璧に再現することには限界があり、リリース直前の全件テストが事業のスピードを阻害するボトルネックとなっているケースも珍しくありません。 こうした状況下で、QAマネージャーや品質推進リードが「部分最適」な改善から脱却し、組織全体のスピードと品質を両立させるための鍵となるのが、フィーチャーフラグを活用したテスト戦略です。 フィーチャーフラグは単なる条件分岐

こんにちは！ アマゾン ウェブ サービス ジャパンのソリューションアーキテクト馬渕です。普段は交通業界のお客様の技術支援を担当していますが、その他にも業界問わず Dify や Amazon Bedrock を活用したお客様の AI 活用推進をご支援しております。 2025年11月21日（金）15:30-17:00に「企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜」を開催し、多くのお客様にご参加いただきました。今回のイベントでは

前回 はエントリーキャリアの方に向けて、在宅勤務における「他人を思いやる力」を具体的な行動レベルで深掘りしました。 連載第3回となる今回は、対象を少し広げ、中堅（ミドルキャリア）のQAエンジニアの皆様に向けてお話ししたいと思います。テーマは、実務とエンジニアの「心（マインドセット）」を照らし合わせた、 「コミュニケーションに重点を置いたドキュメンテーション」 についてです。 記事一覧：AI時代だからこそ「あなたにお願いしたい」と頼まれるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」 （連載初

技術を土台にして自分なりのQAエンジニアを目指す本連載、第6回のテーマは「テスト自動化」です。 前回の記事 をご覧いただいた方はご存じだと思いますが、私は文系大学出身で、キャリアのスタートは営業職でした。 実務で、商用のプロダクトコードを書いた経験は、今もありません。 もっと言えば、かつての私は「Pythonの環境構築」をするためだけに、1カ月以上も躊躇して手が動かなくなるような人間でした。当時の上司から「Python興味あるんだったらなんで入れないの？」「やらないってことは興味ないってことじゃん」と言わ

急成長を遂げるメガベンチャーにおいて、マイクロサービスアーキテクチャの採用は事業スピードを加速させる強力な武器となります。 しかし、品質保証の観点に立つと、その複雑性はモノリスなシステムとは比較になりません。 サービスが細分化されるほど、チーム間でのテスト方針のズレや、予期せぬ場所での副作用、そして重すぎる統合テストといった課題が顕在化します。 現場の個別改善だけでは限界が見え始めている今、QAマネージャーに求められるのは、各チームを俯瞰し、リソースをどこに集中させるべきかを示す「テストの地図」を描くこと