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

今回は、タイミーの「 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, .table-of-contents li:nth-child(2) { 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マネージャーに求められるのは、各チームを俯瞰し、リソースをどこに集中させるべきかを示す「テストの地図」を描くこと

事業が急速に拡大するメガベンチャーにおいて、複数プロダクトやマイクロサービスの品質を横断的に担保することは容易ではありません。 各チームが独立して開発を進める中で、テスト方針の不一致や手戻りの増加に課題を感じる場面も多いはずです。 これまでのUI主体のテストだけでは、リリースの高速化と複雑なシステム構造に対応し続けることは限界を迎えています。 そこで重要となるのがAPIテストの自動化です。 今回は部分最適に陥りがちな現場の改善を全体最適へと導くために、APIテスト自動化の戦略的な進め方や具体的な手法につい

リリース直前のテストや本番環境で、「まさかこんな操作をするなんて」「そこまで想定していなかった」という不具合に遭遇し、肝を冷やした経験はないでしょうか。 QAエンジニアとして真面目に仕様書と向き合っている人ほど、記載された「正しい挙動」を完璧に確認することに集中してしまい、異常な入力や予期せぬ操作に対する備え、すなわちネガティブテストが手薄になってしまうことがあります。 「テスト観点が浅い」という指摘を恐れる必要はありません。ネガティブテストが漏れてしまうのには明確な理由があり、それをカバーするための「思

システムのリリース直前、あるいは運用が始まってから「想定外の入力でエラーになった」「ネットワークが切れた瞬間にデータが消えた」といった不具合に直面し、焦った経験はないでしょうか。 仕様書に書かれた通りに動くことを確認するだけでは、現実の多様なユーザー操作や不安定な実行環境からシステムを守り切ることはできません。 品質の高いプロダクトを作るためには、正常な挙動を保証する「ポジティブテスト」と、異常な事態への耐性を確認する「ネガティブテスト」の両輪が必要です。 しかし、これら二つのテストの境界線や、よく似た言

大規模なプロダクト開発において、QA（品質保証）の役割は「不具合を見つけること」以上に「リリース可否の判断軸を示すこと」へとシフトしています。 特に週次や日次でのリリースが繰り返されるメガベンチャーの現場では、QAの一言が開発スピードを左右すると言っても過言ではありません。 しかし現場では「念のため確認してください」「一通り見ておきましょう」といった曖昧な言葉が飛び交い、結果として過剰なテストや重複確認を招いているケースが多く見受けられます。 QAが良かれと思って発する言葉が、実はチームの足を引っ張り、ス