弥生開発者ブログ弥生開発者ブログ2024-10-29弥生は第23回Quesに協賛します。告知こんにちは、かとあず(@kato_az)です。弥生でQAエンジニアをしています。弥生は2024年11月8日(金)開催の第23回Quesに協賛しています。いつもすてきなQuesのアイキャッチ画像イベントページより開催当日にスポンサーブースを出すわけでもなく、スポンサーとしてお話しするわけでもなく、協賛の一覧に名前を連ねているだけではありますが、ぜひイベントが多くの人に周知できて盛り上がることができればと、Quesを応援をしています。第23回Quesのテーマは「QAチームの在り方」です。今回のテーマは「QAチームの在り方」。QAの必要性が広く認知されてきた中、QAチームを持つ企業・プロジェクトも増えてきたように思います。自分たちにあったQAチームの在り方を模索されている方も多くいらっしゃるのではないかと考え、取り組みの工夫をご紹介することで、QAチーム活性化の一助となればと思い、今回のテーマとしました。QAエンジニアのみなさんはもちろん、QAのコミュニティーを覗いてみたい方、QAエンジニアとの関係性を考えたい開発者、QAって何しているの?という開発以外のみなさんも興味深く参加できる内容になりそうです。第23回Quesは、株式会社タイミーさんの会場とオンラインのハイブリッド開催です。会社を超えたつながりができたり、情報交換ができたり、SNS上でコミュニケーションをとったり、たのしい会になることと思います。弥生では、2024年5月に第22回Quesを開催しました。オフィスで集まってオンライン視聴したりすることを予定しています。tech-blog.yayoi-kk.co.jp会場やSNS上で弥生株式会社社員を見かけましたら、ぜひお声がけください。一緒にたのしい時間を過ごしましょう。イベント参加ご希望の方は、以下のconnpassページからお申し込みください。ques.connpass.com弥生では、一緒に働く仲間を募集しています。11:00もっと読むコメントを書く2024-10-16MagicPodで自動化したシナリオの実行時間が手動実行時間より長くなってしまったので改善した話QAこんにちは、かとあず(@kato_az)です。弥生でQAエンジニアをしています。好きな勘定科目は未払金です。先日、MagicPodを導入したブログを公開しました。今回は、自動化したシナリオの実行時間が本気を出した手動実行実行よりも遅かったことと、それに対応したお話しです。判決「要改善」......?リグレッションテストを自動化ひとこと「リグレッションテスト」と言っても想像するものは人それぞれです。「あなたが言っているEndはどこのこと?」となると理解がずれてしまいます。今回は、システムテストのリグレッションを自動化しました。具体的には、「テスト対象のスマート証憑管理にデータが入ってくる処理」から「スマート証憑管理がデータを送信する処理(と、確実に送信できたことを確認する)処理」を範囲としています。CONNECTに仕訳情報を連携するシナリオがあります。CONNECTに仕訳情報を連携するシナリオをもう少し具体的に書いてみます。CONNECTの「未確定の取引」に仕訳データが連携されていることを確認するここまでが目的としている連携のテストです。この後、繰り返しテスト実行ができるよう、データの片付け処理をしていきます。オンラインからログアウトするMisocaにログインするMisocaで作成した証憑を選択し、ゴミ箱に入れるMisocaからログアウトする連携を少し待つスマート証憑管理にログインするスマート証憑管理でMisocaから連携された証憑が、「削除済みの証憑」に移動していることを確認するスマート証憑管理からログアウトする連携を1パターン実行するのにこれだけの操作が必要になります。手順で記載している「連携を少し待つ」は、システム間の連携です。連携が完了するまでにかかる時間は、各システムの負荷状況によるため一定ではありません。手動でテストしている際は、様子を見て画面更新しながらしばし待つという対応をしています。自動テストでは「様子を見ていい感じのタイミングで次の確認を始める」という手順が作れず、どうしても「一定時間の待機処理」に頼ってしまっています。Misocaからスマート証憑管理への連携方法は全部で11パターンあります。Misocaからスマート証憑管理へ連携するパターン手動で実行しているリグレッションテストでは、テストのたびにランダムにパターンを選んで確認をしていますが、自動テストでは全11の連携パターンを作成しました。全11パターンを作成したら毎回全パターンの実行をしたくなりました。実行!11パターンのテストを実行し終えるのに、約120分かかりました。して?なんとか改善をしなければ......自動化したことで、早朝や深夜、昼休み、ミーティング中、他の作業をしながらテスト実行ができるため、人が作業をする時間は実行結果を目視確認する1分程度になり「ほぼゼロ」と言えます。こんな時にもテスト実行できるのが自動化の強みただ、11パターンを私が本気を出して手動で実行したら120分もかからないのです。一つ一つの処理は、手動実行するより自動実行した方が確実に早いにもかかわらず、全体の実行時間が長くなっている主な原因は以下2点です。ログイン処理について弥生のサービスでは、前回ログイン情報のセッションが残ってしまったときに、重複ログインの確認画面を表示します。この重複ログインの確認画面を表示した場合、処理を続行する選択をしてから進まなければなりません。ほとんどのテスト実行では発生しないのですが、テスト実行前に正常終了できていなかった場合やセッションが残ってしまった場合、重複ログインの確認画面でテスト実行が進めなくなってしまいテストがFailで終わってしまいます。このため、「重複ログイン画面が出た場合」の分岐処理を入れる必要がありました。これにより、手動のログイン実行よりも時間がかかってしまっています。今後改善できるかもしれませんが、すぐに対応できる解決策がみつからないため、ひとまずテストが安定してPassするために処理の変更は入れませんでした。システム間連携の待ち時間について確実にシステム間のデータ連携が完了してしてから次の処理に進めるように調整をした結果、「60秒待機」「120秒待機」といった待機時間が入ることになってしまいました。「画面更新がされたら次のステップに進む」という設定にすることで待機を最小限まで短縮することも考えましたが、自動で描画が更新されないこともあり、手順の作成が複雑になってします。そこで思い切ってテストケースの実行順序を変更し、まとめて確認できる内容については、1回ずつ確認するのではなく、まとめて確認をするようにケースを組み替えることにしました。Misocaからスマート証憑管理への請求書連携を例にして、具体的に説明していきます。変更前は、連携方法ごとにケースを作成していました。請求書の連携では4つのケースになっています。計画したシナリオのとおりになっています。CONNECTにデータ連携されたことの確認以降のケースを分離しました。これにより、テストケースは1つ増えて請求書連携テストを完了するには、4ケースから5ケースが必要になりましたが、「連携待ち」の回数が減りました。変更後のケース例示した、Misocaからスマート証憑管理への請求書連携と同じような組み替えを、Misocaからスマート証憑管理への納品書連携とMisocaからスマート証憑管理への見積書連携でも対応しました。まとめ11パターンのMisocaからスマート証憑管理への連携確認が約120分かかっていたところから、改善により約45分に短縮することができました。手動で実行するよりもはやく正確にテスト実行ができるようになり、デプロイ完了から結果の確認までの短縮といったチーム内でのメリットと、「クラウド端末(テスト一括実行)」の専有時間が短くなるといった社内のチーム外へのメリットもありました。自動テストのシナリオは、作成して終わりではありません。日々運用することで効果をもたらします。テストの網羅率をあげることも大事ですが、作成したシナリオを運用し続け改善することも大事な対応の一つです。今回は、はじめての自動化で手探りだったため、一度作成してから実行順序を組み替えるという方法をとりました。今後は実行する時間のことも考えてテストシナリオを検討し、テストケースを作成していきます。弥生では、一緒に働く仲間を募集しています。弥生R&D室のsiidaです。プロジェクトを進めています。SageMakerはMLのための様々な機能が搭載されたサービスであり、データ分析からモデル訓練、ひいてはワークフローの構築まで、SageMakerの中で完結させることができます。今回はこれまでに投稿してきたSageMakerの使い方記事をまとめました。いわゆるAI/MLを活用したPoCの範囲で扱うSageMakerの基本的な機能を一通り網羅しています。11:00もっと読むコメントを書く2024-09-27SageMakerでProcessingJobを使用するPythonラッパーの紹介AWSはじめにこんにちは。弥生R&D室のsiidaです。プロジェクトを進めています。SageMakerはMLのための様々な機能が搭載されたサービスであり、データ分析からモデル訓練、ひいてはワークフローの構築まで、SageMakerの中で完結させることができます。SageMakerにはProcessingJobという機能があり、こちらはコマンドをジョブの形でサーバ上から実行できるというものです。重い計算を実行したり、再現性のある実験を行うために有用な機能ですが、実はPythonラッパーで簡単に実行することができます。今回はそのラッパーについて紹介します。11:00もっと読むコメントを書く2024-09-24ProcessingJobで使用可能なジョブ数を上げる方法AWSはじめにこんにちは。弥生R&D室のsiidaです。プロジェクトを進めています。SageMakerはMLのための様々な機能が搭載されたサービスであり、データ分析からモデル訓練、ひいてはワークフローの構築まで、SageMakerの中で完結させることができます。SageMakerにはProcessingJobという機能があり、こちらはコマンドをジョブの形でサーバ上で実行できるというものです。重い計算を実行したり、再現性のある実験を行うために有用な機能ですが、同時に実行できるジョブの数には制限があります。今回は、この使用可能なジョブ数を上げる方法を紹介します。背景ProcessingJobでジョブを作成しようとしたところ、ジョブ多すぎ!という感じのエラーが。ジョブの作成には、下記のPythonラッパーを使用しました。quota.現在の設定では、使用しているインスタンスでは同時に10件のジョブまでしか利用できないとのことでした。この件数を引き上げたいと思います。対処法01まずAWSコンソールを開きます。入力し、表示されたリンクをクリックします。