並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 23 件 / 23件

新着順 人気順

自動テストの検索結果1 - 23 件 / 23件

  • 「ふりかえり」にKPTだけなんてもったいない!? チームの状況に応じたレトロスペクティブの選び方 ばやしさん×いくおさん 対談 - Agile Journey

    アジャイルにおいて開発の過程や成果を振り返ることは、チームの改善につながる大切な行動です。とくにスクラムにおいては、スプリントごとにレトロスペクティブ(retrospective、ふりかえり)のイベントを実施します。ふりかえりのフレームワークといえば「KPT」がまず思い浮かびますが、実際にはチームの状況やふりかえりの目的に合わせて、さまざまなレトロスペクティブの手法をチョイスするのが望ましいでしょう。 それでは具体的にKPT以外ではどんなフレームワークがあり、それぞれチームがどのような状態のときに用いると効果的なのでしょうか。ブログに「自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由」という記事を執筆したソフトウェアエンジニアの大金慧(@bayashimura、ばやし)さんと、その記事で引用された講演資料の発表者で長年エンジニアリングマネージャーを務める小田中育生(

      「ふりかえり」にKPTだけなんてもったいない!? チームの状況に応じたレトロスペクティブの選び方 ばやしさん×いくおさん 対談 - Agile Journey
    • 短期間だけ別チームで仕事をする「レンタル移籍」でソフトウェア開発の知識共有を促進! ユーザベース独自のチーミング制度を体験ベースで紹介する - Agile Journey

      あなたの組織に「あの人が抜けたら動かない」というチームはありませんか? 関わっていた人が組織からいなくなって誰も詳細を知らないAPIが存在したりしませんか? アジャイル開発を導入しているのに、組織としての成長が止まっていると感じることはありませんか? 「どうすれば組織全体の知識共有を促進し、自己組織化を加速できるのか?」「どうすればキーパーソン依存のリスクを低減できるのか?」「どうすればチームごとのよい取り組みを組織全体に広げられるのか?」これらは多くのエンジニア組織が直面している課題でしょう。 私たちユーザベースのスピーダ事業のProduct Teamでは、こういった課題を解消するために「レンタル移籍」という人事制度を実施しています。レンタル移籍はこれらの課題を同時に解決できる取り組みであり、アジャイルをさらに加速させます。 1週間だけ他のチームに移籍できる独自の制度 レンタル移籍に取り

        短期間だけ別チームで仕事をする「レンタル移籍」でソフトウェア開発の知識共有を促進! ユーザベース独自のチーミング制度を体験ベースで紹介する - Agile Journey
      • Llama 4 の概要|npaka

        以下の記事が面白かったので、簡単にまとめました。 ・The Llama 4 herd: The beginning of a new era of natively multimodal AI innovation 1. Llama 4本日、「Llama 4 Scout」と「Llama 4 Maverick」がリリースしました。これらは、前例のないコンテキスト長のサポートを備えた初のオープンウェイトネイティブマルチモーダルモデルであり、MoEアーキテクチャを使用して構築されています。 また、新しいモデルの教師として機能する最も強力な「Llama 4 Behemoth」のプレビューも行います。 ・Llama 4 Maverick ・17Bのアクティブパラメータ ・128のエキスパート ・合計400Bのパラメータ ・100万トークンのコンテキスト長 ・Llama 4 Scout ・17Bのアク

          Llama 4 の概要|npaka
        • 「本当に必要なエンジニア」とは何か - AIアシスタント時代の新たなエンジニア像

          はじめに 近年、私たちの生活や仕事の様々な場面でAI(人工知能)の存在感が増しています。特にエンジニアの世界では、Claude、GPT-4、Geminiといった大規模言語モデル(LLM:Large Language Model)を搭載したAIアシスタントが、プログラミングの方法そのものを大きく変えつつあります。 これらのAIアシスタントは単にテキストを生成するだけでなく、コードの作成や修正、バグの発見と修正案の提案など、かつてはエンジニアだけが行えた専門的な作業を驚くべき精度で実行できるようになりました。特に注目すべきは、CLINEやCursorのようなエージェントモード機能を持つAIアシスタントの登場です。これらは単にコード生成を行うだけでなく、実際にコマンドを実行したり、ファイルを操作したり、更にはデータベースに接続するといった実務的な作業まで行える能力を持っています。例えば、「このJ

            「本当に必要なエンジニア」とは何か - AIアシスタント時代の新たなエンジニア像
          • 要件定義とソフトウェアアーキテクチャ設計 - TRACERY Lab.(トレラボ)

            シリーズ: 要件定義とはそもそも何か 要件定義の目的とゴールとは 要件定義の重要ポイント〜要望・要求・要件を見極める 事業・業務・システムの3階層で要件を捉える 業務フロー図で見える化する業務プロセスからシステム要件への道筋 ユースケースとロバストネス図によるシステム要件定義 システム要件定義の成果物〜設計へのインプットを作成する 要件定義とソフトウェアアーキテクチャ設計(本記事) 要件定義とクラス設計 TRACERYプロダクトマネージャーの haru です。 設計プロセスでは、要件定義で作成された成果物をもとに、各種の設計が進められます。 そのため、設計プロセスの流れや観点を理解しておくことで、「どのような情報を、どの粒度で要件としてまとめるべきか」が明確になり、要件定義の成果物の実用性や完成度が大きく向上します。 設計プロセスについて、たとえば、以下のような観点を押さえておくことが重要

              要件定義とソフトウェアアーキテクチャ設計 - TRACERY Lab.(トレラボ)
            • アプリケーションアーキテクチャをいい感じに検証し続けたい話 - CADDi Tech Blog

              こんにちは、Drawer Growthグループ ソフトウェアエンジニアの内田(id:usadamasa, @usadamasa)です。弊社ではApache Icebergの活用*1とともに、一部のアプリケーションにJavaを導入しています。今回は、システムアーキテクチャから一段レイヤを下げてアプリケーションレベルのお話しをしたいと思います。 アプリケーションアーキテクチャの設計と運用課題 アプリケーション開発において、私たちエンジニアは通常、パッケージ構成やレイヤの依存関係、ロギングなどの観点からアーキテクチャを設計します。 しかし、実装との不整合やチーム内での共通認識が不十分なまま進むと、品質課題として潜在化し、やがて本番障害や開発者の疲弊といった形で問題に発展します。また、DevinやClineなどのAIエージェントに適切に実装してもらうにはプロンプトやドキュメントで設計を伝える必要が

                アプリケーションアーキテクチャをいい感じに検証し続けたい話 - CADDi Tech Blog
              • runn と Testcontainers で「ちょうどいい」Go API テスト - Techtouch Developers Blog

                はじめに バックエンド API のテスト事情 バックエンドのテスト構成(これまでとこれから) テスト構成分類(これまで) テスト構成分類(これから) 「ちょうどいい API テスト」とは API テストに求める価値 実行の容易性 メンテナンスのしやすさ 技術選定のポイント runn の採用理由 Testcontainers の活用 実装例 API サーバー実体 APIテスト runn シナリオ APIテストコード おわりに はじめに バックエンドエンジニアの nome です。花粉症🤧なのでこの時期はリモート仕事の幸せを改めて実感しています。 テックタッチのバックエンドAPIでは、これまでユニットテストと Postman による API 統合テストを中心に自動テストを実施してきましたが、テストカバレッジの不足や実行・メンテナンスコストの課題がありました。 本記事では、これらの課題を解決する

                  runn と Testcontainers で「ちょうどいい」Go API テスト - Techtouch Developers Blog
                • プロジェクト管理のタスクリスト - Qiita

                  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記(2025年04月21日) この記事は一部古い情報もありますので気をつけてください。 現代の開発ではCICD/自動テスト/コードレビューなどは必須レベルであった方が良いし、インフラはクラウドが主流になっていると思います(記事公開時点でも世の中的にはそうでしたが...)。 また、この記事は小規模受託に特化しているので、一定以上の規模のアプリケーション開発においては気をつけるべきポイントに抜けがあります。 そんなこの記事の上位互換とも言える記事が公開されました。ぜひこちらも目を通していただけると良いことがあると思います。 今一定以上の規

                    プロジェクト管理のタスクリスト - Qiita
                  • Cursor開発を高速化する10のテクニック

                    はじめに Cursor(カーソル)はAI搭載のコードエディタとして、開発者の間で急速に人気を集めています。Visual Studio Codeをベースにしながら、強力なAI機能を統合することで、コーディング効率を大幅に向上させることができます。私は日々の開発作業でCursorを活用しており、様々なテクニックを試してきました。 この記事では、私が実際に使用している10のテクニックを紹介し、Cursorでの開発をさらに効率化する方法を解説します。初心者から上級者まで、これらのテクニックを活用することで、開発速度と品質を同時に向上させることができるでしょう。 1. YOLOモードの活用 Cursorの隠れた機能の一つに「YOLOモード」があります。この機能を使うと、AIがコードを書くだけでなく、自動的にテストを実行し、エラーがあれば修正してくれます。 設定方法 設定画面(Preferences)

                      Cursor開発を高速化する10のテクニック
                    • 📝Playwright-mcp を使ったE2Eテストスクリプトの作成を試してみた

                      こんにちは!アルダグラムでQAエンジニアをしている千葉です! 最近AIの進化が目覚ましく、画像生成とかコードを書くAIとか何にでもAI使えるようになってきて、技術の進歩が凄まじい勢いだなって感じている今日この頃です。 突然ですが、私が担当している業務として、E2Eテストの自動化があります。 弊社でのE2Eテストの自動化は、MagicPodとPlaywrightを利用しており、併用してテストの自動化を進めている状況です。 開発のメンバーでは、様々なAIを駆使して開発業務の効率化を行っていますが、QAメンバーでもAIを利用してテスト自動化の工数を削減する取り組みを行っていきたいと考えています。 今回は、Playwright-mcpとCursorを使って、E2Eテストを自動で生成する方法の検証を行ったので、こちらをご紹介したいと思います! 1.Playwrightとは? まずはPlaywrigh

                        📝Playwright-mcp を使ったE2Eテストスクリプトの作成を試してみた
                      • 新卒OSS体験記 - Techouse Developers Blog

                        OSSとの出会い 2024年04月18日、弊社ではOSS Gate ワークショップというイベントを開催しました。このイベントは新卒向けの内容であり、講師として株式会社クリアコード様をお招きし、OSSにIssueを立てて実際にPull Requestを作成するまでを伴走していただく内容でした。詳細なイベント内容については弊社の過去ブログをぜひご参照ください。 developers.techouse.com 私も昨年、同イベントに参加しました。私がエンジニアを志したのは、経験豊富なエンジニアがインターネットを介して空間や言語の障壁を越え、社会課題を解決するソフトウェアを構築するという世界に憧れを抱いたからです。当時フィンランドの大学生だったLinusが開発したLinuxの発展や、日本ではMatzによって開発され世界的に普及したRubyといったOSSには、一部の天才のアイデアが世界を変えるワクワ

                          新卒OSS体験記 - Techouse Developers Blog
                        • MagicPod導入で実現!enechainにおけるE2Eリグレッションテスト自動化の全貌 - enechain Tech Blog

                          はじめに こんにちは。enechainのQAエンジニアのtaise- です。 enechainのQAチームでは、昨年より各プロダクトのE2Eリグレッションテストの自動化を進めており、ツールとしてMagicPodを活用しています。既に導入・運用を開始しているプロダクトがある一方で、現在導入準備中のプロダクトも存在します。 本稿では、以下の点について、enechain独自の経験を交えながらご紹介します。 自動化ツールの選定 ツール導入から運用開始までの流れ 自動化推進における課題と展望 本稿が、E2Eリグレッションテストの導入を検討されている方、または運用中の方にとって、少しでも参考となれば幸いです。 E2Eリグレッションテスト自動化のモチベーション E2E(End-to-End)リグレッションテストは、機能追加や修正によって既存機能が意図せず壊れていないかを確認するために行われます。 E2E

                            MagicPod導入で実現!enechainにおけるE2Eリグレッションテスト自動化の全貌 - enechain Tech Blog
                          • アプリを起動せずにアプリを開発して品質と生産性を上げる - 10X Product Blog

                            先日、Flutter Tokyo #6 で同タイトルの発表をさせてもらいました。10分ほどの発表でしたが、割と良い反応をいただけたので、少し内容を補足してブログとしても公開します。 発表時のスライドは以下です。 前提 一般的に、モバイルアプリは自動テストしづらい箇所が多いと言われます。たしかに、画面から素朴に実装していくと、自動テストでは確認が難しくなりやすいです。そうなってしまうと、アプリを起動して手動で動作確認するしかなくなってしまいます。 一方で、設計やツールを適切に使えば、モバイルアプリであっても広範囲が自動テストで検証可能になります。手動での動作確認を完全になくすことはできませんが、手動テストへの依存度は下げられます。 手動テストへの依存度が下がると、検証時間の短縮、手戻りの抑制など、さまざまなメリットが得られます。また、手動テストにも良い影響を与え、手動テストでなければ確認でき

                              アプリを起動せずにアプリを開発して品質と生産性を上げる - 10X Product Blog
                            • 生成AI活用を「セキュリティファースト」で進めるための6つのステップ

                              6つのステップは2つの段階に分かれる。まずは、生成AIの利用を始める前の「AI戦略策定」「AIプランニング」「AI準備」だ。 生成AIの利用を開始した後は「AIガバナンス」「AI管理」「AI保護」の3ステップをサイクルで回す必要がある。図1の6ステップの内容をまとめると次のようになる。 ステップ1 「AI戦略策定」 ここで重要なことはユースケースの特定の他、目標や目的、定量化可能な指標の設定、社内の評価、自動化可能な箇所の探索、SaaS/PaaS/IaaSのどれを選ぶか、自社における「Responsible AI」(責任あるAI)の定義、著作権に関する検討といった事項だ。従業員にどのように生成AIを利用してもらうべきなのかを見極めることが目的だ。 ステップ2 「AIプランニング」 ユースケースに基づいたAIスキルの評価と小規模な概念実証(PoC)、Responsible AIの実装、組織へ

                                生成AI活用を「セキュリティファースト」で進めるための6つのステップ
                              • JaSST '25 tokyo 参加レポート 〜現地参加ならではの交流と熱量〜 - Nealle Developer's Blog

                                こんにちは、QAチームでSETを担当している宮内です。 少し時間が経ってしまいましたが、JaSST '25 Tokyoに初参加してきたのでレポートを書きました。 1日目は現地参加、2日目はオンライン参加でした。本記事では、現地参加での体験を中心に会場の様子や印象に残ったセッションを共有します。 今回初めてJaSSTに現地参加し、月並みな感想ではありますが現地ならでは熱量を感じ、このようなタイトルにしました。1日目の終了後には有志コミュニティの交流会にも参加させていただき、改めてオフラインでの交流の良さを再確認できました。 オンラインで参加した別のメンバーも先日レポートを投稿しているので、あわせて読んでいただけると嬉しいです。後日また他のメンバーから、今度はJaSSTの内容をチーム内で振り返った結果のレポートを公開予定です。 nealle-dev.hatenablog.com いざ、出発 い

                                  JaSST '25 tokyo 参加レポート 〜現地参加ならではの交流と熱量〜 - Nealle Developer's Blog
                                • Web開発者のための便利ツールを集めたMCPサーバーを作って公開した

                                  はじめに Web開発やスマホアプリ開発をしていると、様々な"変換作業"や"ちょっとした処理"が必要となりますよね? Base64エンコード/デコード、カラーコードの変換、日時フォーマットの変更、QRコード生成など、これらの作業をスッとできると、開発効率がちょっと良くなると思います。 それが、VS CodeのGitHub Copilotで「やりたいこと」を投げるだけで、ツールが自動選択され、結果が返ってくると便利かなーと思いました。 ただ、こういった "計算" や "変換" をAIにしてもらうのはまだ不安があるので、流行りのMCPを作ることにしました。 そんな思いからできたのが web-development-toolbox-mcp です。 このMCPサーバーの紹介と、MCPサーバー作るときのTipsなどを書き残しておきます。 提供機能 このツールボックスには以下の機能が実装されています:

                                    Web開発者のための便利ツールを集めたMCPサーバーを作って公開した
                                  • Amazonで買った本全てを購入履歴から確認してみた Part1

                                    2025年悪文 (第三版)2025年2月28日 未読 2024年トラブルを防ぐ 著作権侵害の判断と法的対応2024年8月31日 未読 著作権法(第4版)2024年8月23日 必要だったところだけ読んだら正直物足りない内容で、この数ページを読むためだけに8000円!?となった 扉は閉ざされたまま (祥伝社文庫)2024年8月13日 未読 面白いらしい わかったつもり~読解力がつかない本当の原因~ (光文社新書)2024年8月6日 未読 <新版>日本語の作文技術 (朝日文庫)2024年7月18日 途中まで読んだ 確かにレビュー通り作者の思想が強い Jump-Start! 英語は39日でうまくなる!2024年5月19日 途中まで読んだ 数ページぐらい 中学英語をもう一度ひとつひとつわかりやすく。改訂版2024年5月19日 未読 名訳を生み出す翻訳トレーニング2024年4月24日 最初

                                      Amazonで買った本全てを購入履歴から確認してみた Part1
                                    • PlaywrightのMCP対応で広がるビジネス自動化

                                      1. はじめに 日本時間2025年3月25日、Microsoftが自社開発のブラウザ自動化ツールPlaywrightがModel Context Protocol (MCP)に対応したと発表しました。この発表は一見すると技術的なアップデートの一つに過ぎないように思えますが、実は生成AIとブラウザ自動化の融合という観点から見ると、ビジネス現場に大きな変革をもたらす可能性を秘めています。 これまで生成AIは主に情報提供や内容生成が中心でしたが、MCPに対応することで、AIがブラウザやデスクトップアプリケーションを直接操作できるようになります。つまり、AIが「考える」だけでなく「行動する」能力を手に入れたといえるでしょう。本記事では、PlaywrightのMCP対応の概要と技術的背景、そしてこれによって可能になる新たなビジネスユースケースについて解説します。 また、後半で試しにClaude fo

                                        PlaywrightのMCP対応で広がるビジネス自動化
                                      • 生成AI時代のITエンジニアの需要予測

                                        2024年度はこれまでにも増して生成AI(人工知能)が大きく進化した年であった。特に得意領域であるプログラム作成に関しては、大きく性能が向上したと言ってよいだろう。何より、推論型大規模言語モデル(LLM)が登場して論理的な思考が可能となり、やや難度の高いプログラムであっても作成できるようになったことは大きな進展だと言わざるを得ない。 今後はAIエージェントが登場し、複雑なタスクにおいて複数のツールやWebサービスと連携するようになるだろう。AIが自動テストツールと連携した品質管理を行って実際に仮想環境でテストを実施し、その結果を分析してプログラムを自己評価して、自律的な修正を行うことが想定される。 当然、そうなればソフトウエア開発にエンジニアは不要になるのではないかという話が出てくる。実際に海外企業ではITエンジニアの新規採用人数を削減するという報道もある。 ITエンジニアが不要にならない

                                          生成AI時代のITエンジニアの需要予測
                                        • GitHub Copilot の使用についてのベスト プラクティス - GitHub Docs

                                          Copilot の長所と短所を理解する GitHub Copilot は AI コーディング アシスタントであり、コードをより速く楽に記述できるため、問題解決とコラボレーションにより多くのエネルギーを集中できます。 Copilot の操作を開始する前に、使用すべき場合と使用すべきではない場合を理解しておくことが重要です。 Copilot が最適な場合の一部を次に示します。 テストと繰り返しコードの記述 デバッグと構文の修正 コードの説明とコメント 正規表現の生成 Copilot は次の場合には適していません。 コーディングとテクノロジに関係のないプロンプトに対応する 専門知識やスキルを更新する。 自分自身が責任者であって、Copilot はサービスの強力なツールであることを忘れないでください。 ジョブに適した Copilot ツールを選択する Copilot コード補完と Copilot

                                            GitHub Copilot の使用についてのベスト プラクティス - GitHub Docs
                                          • 売却査定サービスにおけるE2Eテスト高速化の取り組みについて - LIFULL Creators Blog

                                            プロダクトエンジニアリング部の千葉です。 LIFULL HOME'S不動産査定とホームズマンション売却の開発に携わっています。 この記事では、売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介していきます。 売却査定サービスにおけるE2Eテストについて 環境 テスト観点 高速化の取り組み 背景 取り組み1 - 項目の精査と方法の最適化 取り組み2 - 処理の共通化 取り組み3 - ジョブの最適化 取り組み4 - 実行の並列化 取り組み5 - タイムアウト設定 結果 全体 Botでページを開いた際のHTTPステータスコード200の検証 モバイル端末でページを開いた際のHTTPステータスコード200の検証 PC端末での主要導線の確認 モバイル端末での主要導線の確認 まとめ 売却査定サービスにおけるE2Eテストについて 環境 売却査定サービスではE2Eテストを自動化するためのフレー

                                              売却査定サービスにおけるE2Eテスト高速化の取り組みについて - LIFULL Creators Blog
                                            • フレームワークのアップグレード作業を計画的に進めるための手順

                                              Next.jsを14系から15系に、Reactを18系から19系にアップグレードする作業をしていて感じたのが「計画的に進めないと、見通しがつけられなくてしんどいな」ということ。 最初は計画もなく一気に進めようとしていましたが、状況が把握しきれなくなり、情報を整理してから別ブランチでやり直すことになりました。 原因としては、色々なことを試しているうちに、何をしたからうまくいって、逆になぜうまくいかないかが把握できなくなったこと。 そして、レビューに出す前の最終確認がとてもやりにくいと感じましたし、整理されていない状態だとレビュアーの負荷がかなり上がってしまいます。 フレームワークのアップグレード対応に関する具体的なコード例は記事がありますが、計画的な進め方に関する記事は見かけないなと思ったのが、この記事を書いているモチベーションです。 もっといいやり方や追加情報などがあればコメントいただける

                                                フレームワークのアップグレード作業を計画的に進めるための手順
                                              • AWS CodeBuild を利用した CI の高速化: 並列テスト実行が利用可能に | Amazon Web Services

                                                Amazon Web Services ブログ AWS CodeBuild を利用した CI の高速化: 並列テスト実行が利用可能に AWS CodeBuild で並列テスト実行のサポートが開始されたことをお知らせします。これにより、テストスイートを同時に実行し、ビルド時間を大幅に短縮できます。 この記事のために作成したデモプロジェクトでは、環境をプロビジョニングする時間を含め、テストの合計時間が 35 分から 6 分に短縮されました。AWS マネジメントコンソールの次の 2 つのスクリーンショットは、その差を示しています。 テストスイートの順次実行 テストスイートの並列実行 継続的インテグレーション (CI) を大規模に実行する際に、テスト時間が非常に長くかかることは大きな課題となります。プロジェクトの複雑さが増し、チームの規模が大きくなるにつれて、包括的なテストスイートの実行に必要な時

                                                  AWS CodeBuild を利用した CI の高速化: 並列テスト実行が利用可能に | Amazon Web Services
                                                1