はじめに このAdvent Calendarでは、過去に私が書いたテストや品質に関する記事の紹介をします。 本日紹介する記事はこちらです。 https://gihyo.jp/dev/serial/01/tech_station/0006 掲載日：2008年7月4日 掲載メディア：gihyo.jp（技術評論社） 生成AIによる要約 この記事では、Webアプリケーションを対象にした「統合テスト」や「システムテスト」でのテスト内容に焦点を当てています。特に「機能」に関する観点を詳細に取り上げ、Web特有の課題や

2025 年 5 月、私たちは AWS Transform for mainframe をリリースしました。これは、メインフレームのワークロードを大規模にモダナイズするための、初のエージェント型 AI サービスです。AI 搭載のメインフレームエージェントは、モダナイゼーションの各フェーズにおける複雑でリソース集約型の作業を自動化することで、メインフレームのモダナイゼーションを加速します。COBOL、CICS、DB2、VSAM を含むレガシーメインフレームアプリケーションを最新のクラウド環境へ移行するプロセ

本記事は 2025 年 11 月 20 日に公開された “ Accelerating data modeling accuracy with the Amazon DynamoDB Data Model Validation Tool ” を翻訳したものです。 Introducing the Amazon DynamoDB data modeling MCP tool では、 Amazon DynamoDB Model Context Protocol (MCP) サーバー を発表しました。これは、Dyn

はじめに このAdvent Calendarでは、過去に私が書いたテストや品質に関する記事の紹介をします。 本日紹介する記事はこちらです。 https://gihyo.jp/dev/serial/01/tech_station/0001 掲載日：2008年5月13日 掲載メディア：gihyo.jp（技術評論社） 生成AIによる要約 この記事は、ソフトウェアテストの全体像を整理することから始める連載の導入回です。まず「テストにはいろいろな種類があるが、“テスト”という言葉だけでは示す範囲が広すぎる」と指摘。

本記事は【 Advent Calendar 】の4日目の記事です。 こんにちは、マイナビに業務委託で参画しているY.Hです。 現在携わっているプロジェクトでは、Playwright MCP を活用して E2E テストを実施しています。 しかし、MCP 単体だけでテストを書き続けると、どうしても「つらみ」が出てきます。 Playwright MCP だけで書き続けると起きる「つらみ」 Playwright MCPはテストコードを爆速で書ける一方で、"プロジェクト全体としてのテスト設計"までは面倒を見てくれま

品質保証（QA）部門が、経営層から「コストセンター」として見られがちな状況は、多くのIT企業で共通の課題です。 特に「テストコストが想定を超過」という言葉は、品質保証マネージャーにとって最も重い言葉の一つでしょう。 今回の主人公、品質保証マネージャーの近藤 恒一もまた、コスト削減を迫られる中で「人を削る前に、ムダを疑え」という信念を抱き、組織の構造的な非効率に立ち向かうことを決意します。 彼のチームでは、Excel管理による情報分散、属人化した工数、再利用されないテストケースが蔓延していました。本記事は、

1人のエンジニアとして成長し続けるために、私たちは何を意識するべきでしょうか。特定の知識を極めることでしょうか。最新の技術トレンドを追いかけることでしょうか。 それらも言うまでもなくとても重要なことですが、もう1つ普遍的な要素があるかもしれません。 武道やスポーツの世界で一流を目指す者が重んじる「心技体」という言葉があります。この「心技体」とは、心と技術と身体能力……この三つの要素がバランス良く揃って、初めて真の実力が発揮されると言われます。 このような三位一体的な依存関係という考え方は、ソフトウェア開発

ソフトウェアテストの見積もり手法について説明しています。JSTQB Foundation Levelのシラバスに紹介されている4つの手法（比率に基づく見積もり、外挿、ワイドバンドデルファイ、三点見積もり）について、それぞれのメリットとデメリットを解説します。

タイミーQA Enabling Gのkishikenです。 「 Tokyo Test Fest 2025 」が11月14日に大崎ブライトコアホールにて開催されました。 タイミーには世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。詳しくは以下をご覧ください。 productpr.timee.co.jp 今回はこの制度を使って参加しました。 参加して 聴いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。 Zen of Te

はじめに Luupに所属している、ぐりもお（@gr1m0h）です。 2025年7月、私が所属していたInfra/SREチームとQAチームが統合し、新たにQualityチームが発足しました。この体制変更は、品質保証とサイト信頼性エンジニアリングを統合的に捉える試みであり、従来の組織サイロを超えた挑戦だと考えています。 本記事では、SREチームのメンバーとしての視点から、私の考えを整理してお伝えします。QAとSREをどのように統合するか、そしてSREのプラクティスを用いて品質と信頼性を一貫して確保していくかに

ソフトウェア開発の現場では、日々、無数のテストが実行されています。 しかし、「このテスト、前にもやったな…」と感じたことはありませんか？ テストケースの作成は、プロジェクトの初期段階では品質を担保するための重要な作業ですが、プロジェクトが進行し、機能が追加・変更されるたびに、膨大な量のテストケースが重複したり、メンテナンスが困難になったりします。 まるで、苦労して作った貴重な資産が、時間の経過とともにガラクタに変わってしまうかのようです。 そこで今回はある開発チームのリアリティのあるストーリー

複数プロジェクトが同時進行する中で、毎回テストケースを一から作り直す状況に疲弊していませんか。 論理的で無駄を嫌うQAエンジニアの方々にとって、この非効率な現状は大きなストレスになっていることでしょう。 チーム内で「前回のテストどこにありました？」という質問が度々飛び交い、過去のテストが見つからず、探すだけで数時間が消えてしまう…。 このような「探す手間」は、直接的にテスト設計や実行の時間を圧迫します。 これは個人の努力で解決できる問題ではなく、テスト資産を効率的に再利用できないという構造的な課題から生じ

はじめに SAPシステムの適切な負荷テストを実施することは、ピーク使用時にシステムがビジネスのパフォーマンスと信頼性の期待に応えられることを保証する主要な要因です。負荷テストが必要となる典型的なシナリオには、新しい会社/国の展開、ECCからS/4HANAへのソフトウェアリリースアップグレード、アプリケーションパッチ（例：サポートパッケージ）、S/4HANA変革プロジェクト、またはSAP RISEへの移行があります。このような大規模な変更後の安定した運用を確保するため、潜在的なパフォーマンス関連の問題を回避

こんにちわ。SCSKの曽我です。 普段、扱っているZabbixの導入作業をオンプレだけでなくAzure上に構築することもあります。 その際、負荷テストを行うことがあります。スクリプトを使ってテストする方法もあるのですが、 もっと簡単にかということで、AzureのAzure Load Testingを使います。 Let’s Try! 環境 AzureのVirtual MachineにRedhat Enterprise Linux＋Zabbixを事前に用意します。 また、App Load Testingが、V

ソフトウェア開発において、テストや品質保証（QA）は安定したリリースに不可欠なプロセスです。 しかし「テストの情報共有」という目立たない作業が、チーム全体の生産性を著しく下げているケースが少なくありません。 テストケースはExcel、進捗はSlack、バグは課題管理ツール…と情報がバラバラに散らばっているため、必要な情報の確認に時間がかかり、会議は長引き、手戻りが頻発。 その結果、本来集中すべきテスト設計や自動化といった本質的な業務にリソースを割けず、開発サイクルが遅延するという悪循環に陥って