はじめに Maestro の maestro test コマンドでは、--test-output-dir と --debug-output などのオプションで、スクリーンショットやログなどの artifacts が出力されます。両者はどちらも「artifacts の保存先を指定するオプション」に見えるのですが、実際には扱うファイルがやや異なります。 この違いを意識しないと、落ちたテストの調査で「あるはずの artifact が見つからない」ということが起こりえます。 たとえば、スクリーンショットを探していたら maestro.log しか入っていなかったり、逆にログだけ別ディレクトリに出ていたり。 そこで、この記事では maestro test の artifacts 周りを整理します。また、ドキュメントとサンプルコードを頼りに、これらのオプションの違いや使用例を探ってみます。 この記事で最初に押さえたいのは、次の4点です。 --test-output-dir はスクリーンショットや動画の主な置き場 --debug-output は maestro.log の主な置き場 commands-*.json は artifact 調査で見ることになる主要なファイル --flatten-debug-output は --debug-output の artifact 群のディレクトリ階層をフラットにする レポート系のフォーマットは下記の2つです。 --format : レポートのフォーマット。 例：--format junit , --format html , --format html-detailed --output : 上記のレポートの出力場所。省略した場合はカレントディレクトリに出力。 例：--output build/report.xml なお、AI 系のレポートは生成条件が別なのでこの記事では深追いしません。 参考：https://docs.maestro.dev/maestro-flows/workspace-management/ai-test-analysis 1. --test-output-dir / --debug-output / --flatten-debug-output オプションの早見表 --test-output-dir / --debug-output / --flatten-debug-output オプションの早見表をご覧ください。 ...

1.はじめに 2026年3月20日に開催された JaSST’26 Tokyo にオンラインで参加し、いくつかのセッションを視聴しました。 AI の活用や品質の捉え方といったテーマを通じて、日々の業務だけでなく、これからのキャリアの方向性についても考えさせられる内容が多くありました。 本記事では、それらの内容を備忘録として講演のポイント、感想の2つの切り口から整理し、最後にまとめとして全体の通しての学びについて触れます。 2.セッション別メモ 2-1.A1）When AI Joins the Test Team: Promise, Pitfalls, and the Future of Software Quality 登壇者：Gayathri Mohan さま 『Full Stack Testing』 の著者 講演のポイント AI は単なる自動化ツールではなく、観察して提案する「協働者」としてテスト活動に入りつつあり、機能テストに限らず非機能領域まで含めてテストのスピードを大きく向上させると述べられていました。 一方で、AI の出力に対する過信や誤った安心感といったリスクも指摘されており、特に探索的テストでは、意図や過程が見えにくくなる点が課題とされていました。 感想 探索的テストにおいては、AI の挙動や経過を追えないまま結果だけを受け取ると、その妥当性を判断することが難しくなるのではないでしょうか。 結果が高速に得られるほど、「どのような意図で、なぜその結論に至ったのか」を説明できることの重要性は高まるでしょう。 また、実務面では AI に与えるコンテキスト（ドキュメント）の整備コストが無視できないという話題もありました。 仕様や前提、判断基準を揃える必要があり、テスト実行が高速化する一方で、準備や整備の比重が増えていると感じました。 そのため、AI を活用する際は責任範囲を事前に整理する必要がありそうです。どこまで採用するのか、何を根拠として扱うのか、最終判断を誰が担うのか など。AI を活用することで移譲できることは増えたけど、この責任範囲の事前検討はじめ、依然として抱える業務はありそうです。むしろ、AI が返す回答を理解するためにこれまで以上に調査が求められるのかもしれない、、と思ったら 生成AIパラドックス という概念があるようですね。 cf. AI時代のソフトウェア開発はなぜ停滞する？ 「AIパラドックス」を解消するための戦略とは ｜ gihyo.jp 2-2.D2）品質を経営にどう語るか 登壇者： kyon_mm（デロイト トーマツ）さま naco_mm（キャディ）さま moriyuya（witch&wizards）さま https://speakerdeck.com/kyonmm/communicating-the-strategic-value-of-quality-to-executive-leadership 講演のポイント 品質を重視しているだけでは経営層に価値は伝わらず、事業への影響という観点で説明する必要があるとされていました。特にAI活用が進むことで非構造データが増え、従来のようにテストの積み上げだけで品質を説明することが難しくなっているとのことです。 そのため、品質を事業 KPI やリスクと結びつけて伝えることが重要であり、あわせて CoQ についても既存の仕組みに組み込んで無理なく運用することの重要性が述べられていました。 感想 品質を「テストした／していない」という観点ではなく、事業 KPI にどのように接続するかで捉える必要があると感じました。 ...

これは 社会人学生 Advent Calendar 2024 3 日目の記事です。 ぼくは 2021 年春へ帝京大学理工学部(通信教育課程)へ編入していたのですが、2024 年夏に卒業しました。 入学してよかったか 編入学当初は 腰を据えて勉強したい と意気揚々と二足の草鞋に励んでいましたが、とんでもなくたいへんでした、、。勉強すればするほどかえって自分の無知さを思い知る日々が続き、いつしか卒業することが目的となったというのはここだけの話です笑。 一方で 足るを知り、足らざるを知る という考えを持つことができたことはポジティブなことでした。結局は自分の現状を認めなくちゃしんどいなと。 これから 仕事はもちろんですが、これまで存分に楽しめなかった旅行や登山などなどやっていきたいです。編入学当初に思い描いていた景色とは違うものとはなりましたが、Connecting the dots という言葉のとおり、これまでのすべての選択が次の選択の糧となるようにがんばります。 網笠山の山頂からの一枚 :) 3-4 年目に取得した科目 最後に、後述するブログでは触れていない、3-4 年次に取得した科目を列挙します。なお、現在は履修できなかったり、履修方法が異なる科目があるかもしれません。ご注意ください。 Web アプリケーション オートマトンと計算理論 情報科学演習 3 情報科学演習 4 情報技術者演習 オペレーティングシステム コンピュータアーキテクチャ 画像情報処理 応用数学 情報システム 情報システムデザイン 情報社会論 情報理論 情報セキュリティ オペレーションズリサーチ ディジタル通信 英語コミュニケーション ディジタル信号処理１ 自動制御論 論理回路 以下は単位認定 コンピュータグラフィックス 電波法および電気通信法 通信方式 参考) 編入学当初や在学時代のふりかえり いろいろ悩んで帝京大学理工学部（通信教育課程）の社会人大学生になった 帝京大学理工学部（通信教育課程）の社会人大学生 1 年目をふりかえる ｜ gkzz.dev 帝京大学理工学部（通信教育課程）の社会人大学生 2 年目をふりかえる ｜ gkzz.dev p.s. 最近、ネトフリで 愛の不時着 を観たのですが、間違った電車がときには目的地へ連れて行く というフレーズを知りました。厳しくも鼓舞してくれるすてきな言葉ではないでしょうか。

※ 結論だけ知りたい方は、4.結論 をご覧ください 🙏 1.前提とこの記事で解決したい課題 1-1.前提 最近は MagicPod という E2E テスト自動化ツールを触ることが多い。 MagicPod では、複数のテストシナリオを実行（MagicPod ではこれを テスト一括実行/一括テスト実行 と称している。）することができる。また、テスト対象のアプリケーションのアーカイブ（App ファイル）には、MagicPod 上でユニークな連番である、app_file_number を割り当てられ、テスト一括実行 の際にはこの app_file_number を指定することで、任意の App ファイルを指定することもできる。 app_file_number のいちばんカンタンな取得方法は、App ファイルを MagicPod 側にアップロードする際のレスポンスから取得することである。 $ app_file_number=$(./magicpod-api-client upload-app -a <path to app/ipa/apk>) $ ./magicpod-api-client batch-run \ -t "${token}" -o "${organization}" -p "${project}" -S "${test_settings_number}" \ -s "{\"app_file_number\":\"${app_file_number}\"}" 参考: https://github.com/Magic-Pod/magicpod-api-client#upload-app-run-batch-test-for-the-app-wait-until-the-batch-run-is-finished-and-delete-the-app-if-the-test-passed 1-2.この記事で解決したい課題 しかし、App ファイルを MagicPod 上にアップロードするジョブとテスト一括実行のジョブが独立しているとしたらどうだろうか。App ファイルのアップロードのレスポンスから取得した app_file_number をテスト一括実行の引数として渡すことができない。そのため、指定したい App ファイルの app_file_number の取得方法を新たに用意しなければならない。 あるいは、App ファイルに test など任意の文字列が含まれさえしなければ、最新のもの指定したい場合もあるだろう。この場合はどうやって指定すればよいだろうか。 この記事では、そのような課題に対する解決策のひとつを書き留めたい。 2.環境情報 この記事で扱う MagicPod Web API のバージョンは v1.0 https://magic-pod.com/api/v1.0/doc 3.MagicPod のテスト一括実行をおこなう際、任意の App ファイルの app_file_number を指定する 3-1.MagicPod のテスト一括実行をおこなう際、直近にアップロードした App ファイルを指定する MagicPod Web API を眺めると、/v1.0</{organization_name}/{project_name}/list-files API で、以下のように書かれていることに目がいく。 ...