2023-11-02 JaSST'23 Kyushu 招待講演 https://www.jasst.jp/symposium/jasst23kyushu.html 実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
(ポジション名をクリックすると詳細をみることができます) 軸 上図のチャートは、以下の5つの軸で構成されています。 技術力: 技術スタックとツールに関する知識 システム: システムに対するオーナーシップのレベル 人: チームとの関係 プロセス: 開発プロセスへの関与度合い 影響力: そのポジションの影響力の範囲 影響力 の軸は直交しており、他のすべての軸に適用されるため、別の次元 と見なすことができます。 各軸には、5つの異なるパフォーマンスレベルがあります。ここで重要なのは、どのレベルにも前のレベルが含まれているということです。例えば、技術力が evangelizes レベルの方は、その技術力のspecializes と adopts のレベルを満たしているということです。 各レベルの理解を深めるために読み進めてください。 レベル 技術力 Adopts: チームで定義された技術やツールを
近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA(品質保証)という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA(品質保証)の言葉がどのように定義されているか、整理して解説します(結論からいうと三流派あります) 国際標準規格での定義:品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000:2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って
The language resources on this page can help you develop localized versions of applications that integrate with Microsoft products. By using the same terminology and style that Microsoft uses, your customers will find it easier to get started with your applications when used with Microsoft products. Terminology Microsoft Terminology can be used to ensure that terminology in your localized versions
GitHub ActionsではGITHUB_TOKENで権限が足りない場合、PAT(Personal Access Tokens)がよく使われます。しかしPATより優れた選択肢があります。それがGitHub Appsトークンです。本記事ではGitHub Appsトークンの実装方法をゼロから学びます。目標はPATの完全駆逐です。 本記事で学べること PATとGitHub Appsトークンの違い GitHub Appsの作成・インストール方法 GitHub ActionsでGitHub Appsトークンを払い出す方法 本番運用で考慮すべきセキュリティとトレードオフ イントロダクション GITHUB_TOKENはGitHub Actionsのワークフロー開始時に自動生成され、終了時に自動削除されるトークンです。GITHUB_TOKENで済むなら、これがベストです。何も悩む必要はありません。問題
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね?」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発
こんにちは、今年は家電が何かと壊れる freee会計のアプリケーションエンジニア id:him0 です。 この記事は freee Developers Advent Calendar 2022 の19日目の記事です。 今年自分のチームは特定のドメインの DB を分離しパフォーマンスのカイゼンを図るプロジェクトに取り組んでいました。下調べを行いドメインの境界を定義し分離できるぞーとプロジェクトは走り始めましたが、やはり単純には行かないのがアプリケーション開発、ちゃんと問題に突き当たります。特定の検索条件を利用する際に分離される予定の 2 つの DB を横断して JOIN を行っていることが発覚しました。 この問題に対して我々チームは当初パフォーマンス犠牲に元ある機能を再現することを考え始めたのですが「この検索軸消しちゃっていいんじゃない?」というメンバーの提案をきっかけに方向を転換して「ユー
この記事は、Money Forward Engineering 1 Advent Calendar 2022 16日目の投稿です。 Money Forward ME サーバサイドエンジニアの島津です。 今回は、Dependabot 運用の自動化について、ご紹介したいと思います。 Dependabot について Dependabot は、プロジェクトで使用されているライブラリの脆弱性を監視し、依存関係を最新の状態に保つための、GitHub のサービスです。 その中でもいくつか機能がありますが、今回は Dependabot version updates の機能を使用した際の自動化についてです。 この機能を使うと、リポジトリ内の各種パッケージのバージョンをチェックし、常に最新に保つために自動的に bot が プルリクエストを作成してくれます。 詳しい設定方法は割愛しますが、リポジトリ内で .g
Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
こんにちは。AutifyのSET(Software Engineer in Test) 、末村(@tsueeemura)です。 皆さん、E2Eテストしてますか?以前はほぼSelenium一択みたいなところがありましたが、最近はPuppeteerやCypress、TestCafeなどいろいろなフレームワークがあり、ついつい目移りしてしまいますね! さて、どのフレームワークを使うにせよ、E2Eテストを書く上で共通で意識しないといけない重要なファクターがいくつか存在します。 その一つが ロケータ です。操作や検証の対象となる要素を指定するためのキーのことです。 ロケータにはCSSセレクタやXPathが利用でき、idやclass、name といった属性を利用するのが一般的です。 今回はこのロケータについての話を書こうと思います。 ロケータとは 要素を一意に指定できさえすればロケータに使うものは何で
以前書いた「GitHubActionsのSelf-hosted runnerで、SpringNativeのビルド時間を短縮する」の続きです。 SpringNativeでNativeイメージ化する際のビルド時間の短縮に「Self-hosted runner」に強めのEC2インスタンスを使用してビルド時間の短縮した話を書きました。 https://qiita.com/renave/items/561904b2988ebb6f0534 今回は費用の節約のために「Self-hosted runnerを必要な時だけ起動する」ようにしたお話です。 こちら、強めのEC2インスタンスなので起動しっぱなしにすると結構お金がかかります。 使うたびに手動で起動/停止するのも大変です。 そこで、 1:GHA実行時に標準のUbuntuのrunnerを使用し、Self-hosted runnerインスタンスを起動。
prismatix事業部の塩谷 (@kwappa) です。 1月の後半からずっと、自分の部署に限定しない1on1を「かっぱ談話室」というタイトルで実施しています。話題はなんでもよくて、ぼくの経験やキャリアをお話ししたり、単に雑談をしたり、ガチなお悩みの相談を受けたりと、いろんな目的で参加してもらっています。 この記事では、部門も話題も限定しない1on1である「談話室」というメソッドと、その効能としての「コミュニケーションのバイパス」についてご紹介します。 「談話室」メソッド 「談話室」は、部門・話題を限定しない誰でも歓迎の1on1です。 やりかた 談話室を希望する人は予定を予約します Google Calendarの「予約枠」機能を使います 30分1枠で、他の予定に重ならない時間帯をあらかじめ予約可能にしておきます Google Meetで談話します 基本的には会話をするだけです 話題はど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く