はじめに 本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。 gihyo.jp 本記事で一番伝えたいこと データモデリングについての考えが深まるぞ 開発者が読むともっと役立てることができると思うぞ QAエンジニアである私が読んでも役立つぞ 読み始めてすぐに「良い買い物だった」と思って思わずポストしている様子 目次 はじめに 本記事で一番伝えたいこと 目次 本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい SoAとSoMという整理 「残」という概念 データベース設計とは違う「データモデリング」という考え方 QAエンジニアとして、業務に役立てそうなこと

システム開発においてテストの自動化は欠かせない要素になってきている。継続的に開発を進めながらサービスを成長させるモダンな開発スタイルは、高い頻度でテストすることで品質を担保しているからだ。一方、自動テストを実施したいと考えながらも、実行まで至らない、実行し始めてもうまく継続できていないという開発者も少なくないだろう。本セッションでは、ソフトウェアテストの専門企業である株式会社ヒューマンクレストの浅黄友隆氏が、UI層を操作するE2Eテストの自動化の取り組みについて具体的に紹介した。本レポートでは、自動テストを進める際に現れる2つの山と激しい環境変化にどのように対応するのか、そのポイントを解説する。 自動テストを進めるうえで直面する2つの課題と環境変化 株式会社ヒューマンクレスト 取締役 兼 技術推進本部 本部長 / テスト自動化研究会（STAR） 浅黄友隆氏 セッションの前半で、浅黄氏は自動

🥦 バカでかいブロッコリーの絵文字を動かすことができる

(この記事は全文無料で読めます) 2023年11月に日本からカナダのバンクーバーにポップに移住しました。移住、と書くとすごく大きなことに感じますが、テンション的には東京から地方に移る、「引っ越す」みたいな感覚でした。約4ヶ月が経って今感じること、というか全然ポップじゃなかったぜ！！！ということをつらつらと書きます。 なお、書いて気づきましたが、ポップじゃない話はSTEP4なので、適宜読み流してくださいませ。また、現地就活のもっと具体的な話は別記事にしようと思うので、具体に興味がある人には違うかもという前置きをしておきます。 ポップな海外移住(イメージ) ポップな移住とは日本が嫌いになったわけでもカナダがずっと好きすぎてたまらなわかったわけではありません。日本にも30年住んだので、他の場所にも住んでみたい、選択肢を増やしたいという感じでした。妻とは数年前から話はしていて、色々なタイミングが重

皆様こんにちは。QAエンジニアのブロッコリーこと風間裕也（@nihonbuson）と申します。私は本業で株式会社10XのQAエンジニアとして勤務する一方、副業としてB-Testingを開業し、さまざまな会社でQAに関する相談に乗ったり、登壇や執筆活動を行っています。 また社外活動として、WACATE（ソフトウェアテストの合宿型ワークショップ形式勉強会）の実行委員長や、ソフトウェアテスト技術振興協会（ASTER）の主催するJaSST Review（ソフトウェアレビューのシンポジウム）の実行委員長を務めています。 本記事では、私がどうしてQAエンジニアというキャリアを歩んでいるのか、そして品質保証（QA、Quality Assurance）という分野でどのように開発チームと協調しながら開発してきたのかをお話しします。 筆者近影 学術と企業のギャップに驚いてテストの浸透に動く テスト技術に磨きを

これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力

このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

はじめに こんにちは。コンシューマ事業部バックエンドエンジニアの齋藤です。 今回はコンシューマ事業部で行った実例マッピング勉強会について紹介します。 実例マッピングについて 実例マッピングとは、 ユーザーストーリー ルール(=要件) ルールに関連する実例 疑問 の4種類をそれぞれ異なる色の付箋に書き出し、マッピングしながら関係者が会話を行うことで、ユーザーストーリーのルールを明確にするための会話を短く、強力に生産的にするための方法です。 詳しくは、ぜひ先日 高津が投稿した記事 をご覧ください！ 勉強会開催まで 1月にコンシューマ事業部のメンバーの多くが出社する日があったため、品質保証・テスト勉強会メンバー（村上、高津、大澤、齋藤）で品質改善につながるイベントを企画しようということになりました。 イベントを通して目指したい姿としては、以下のような点があがりました。 チーム全体で（エンジニア以

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 18日目の記事です。 はじめに ログラスの龍島(@hryushm)です。 ソフトウェア開発において、「シフトレフト」すなわち開発の早い段階でテスト計画を立て、実施していくことが全体的なコスト削減や価値提供の早期化につながるとよく言われています。 この記事では、シフトレフトによってもたらされる効果をログラスでの実例を用いて紹介した上で、なぜ効果が出るのか？を「抽象度」というキーワードから紐解いてみようと思います。 本記事ではスクラム開発においてPBIを完了させる中でシフトレフトしていくことを念頭に書いていきますが、ソフトウェア開発の任意のタイミングにおいて適用できる概念だと考えています。 テスト設計を実装前にやることの有用性 まずシフトレフトによって何が起こるのか？を考えます。PBIに書かれた受け入

こんにちは。asken Androidエンジニア兼品質管理の高津です。 今回は医療事業部で実例マッピングをやってみた話です。 この記事は、ソフトウェアテスト Advent Calendar 2023 の12日目です。 実例マッピングとは 実例マッピングとは、 ユーザーストーリー ルール(=要件) ルールに関連する実例 疑問 の4種類をそれぞれ異なる色の付箋に書き出し、マッピングすることで、ユーザーストーリーのルールを明確にするための会話を短く、強力に生産的にするためのシンプルでローテクな方法です。 Matt Wynne氏が発明した方法で、Matt Wynne氏の許可を得てブロッコリーさんが翻訳された実例マッピングの紹介がこちらです。 The BDD Books - Discoveryにも記載があります。 実例マッピングの詳細はぜひそちらをご参照ください。 なぜ実例マッピングをやることにした

ご飯目的でイベントに参加するの絶対ダメ！LINEヤフーでは #jjug_ccc 2023 Fallにて寿司🍣スポンサーをさせていただきました✨そして懇親会でスポンサーLTの時間をいただいたので、会社紹介に合わせ最後に大事なことを話してきました。絶対ダメ pic.twitter.com/DifFt8QQbS — Shoco Sato (@satoshoco) November 11, 2023 ・・・・・ いつから私は「めし目的人間 ※1 」を目の敵にし始めたのだろうか。 いつから私の世界に「めし目的人間」という不快な影が忍び寄っていたのだろうか。 この感情の原点を探るべく、私は思いを馳せる。 ・・・・・ ※1 このブログの中で出てくる「めし目的人間」とは、寿司のネタだけを食べたり、ピザの端っこだけ残したり、無料でご飯を提供するイベントを渡り歩いている人のことである。明らかにご飯を食べるこ

はじめに 本記事は ソフトウェアテスト Advent Calendar 2023 および10X プロダクトアドベントカレンダー2023の5日目の記事です*1。 皆さんは「DevOpsに関する図を思い浮かべてください」と言われたら、どのような図を想像しますか？一番思い浮かべる人が多いのが、DevOpsのループ図ではないでしょうか？ DevOpsのループ図（vecteezyより拝借） 本記事では、DevOpsのループ図の発端を探しつつ、このループ図に対しての私なりの考えを述べた上で、シフトレフトテスト/シフトライトテストについて詳しく言及していきます。 目次 はじめに 目次 Danの考えるDevOpsのループ図 ループ図の解釈 テストの扱いについて ループの形について DevOpsのループ図とシフトレフトテスト/シフトライトテストの関係性 シフトレフトテストの具体的な活動は何か テスト駆動開発

こんにちは、10Xでコーポレートエンジニアをやっているハリールです。このブログは 会議全部ふっとばして社員の集中力を10xした話(バッグバン) の付録として会議ビッグバンの実現方法についてまとめたものになります。 はじめに 結果的に多くの成果とポジティブフィードバックで完遂できた10Xの会議ビッグバンですが、udonさんのアイデアを初めて聞いた時に、実は強めに反対していました。 実行することで得られるメリットは理解できるものの、安全に実行するためのロジックの準備やテスト期間が短いこと、なによりまずは段階的にルール策定と啓蒙を行い、それでもイシューが解決できない場合に、次のステップとして会議ビッグバンの流れがよいのではと当時は思っていました。 そんな私に対して、それならばとまずは特に会議が多いメンバーに対して実態をヒアリングし、そのほぼ全員が賛同している点、また、ロジック準備・テストのための

プロダクト開発部の千田です。 チームで「実例マッピング」を実施してみたので、今回はそのことについて記事を書いていこうと思います。 ユーザーストーリーが曖昧なまま開発が進んでいる、ビジネスサイドと開発者の一体感がないなどの課題感があるチームの参考になったら嬉しいです！ 前提 チームが抱える課題 実例マッピングとは 実施方法について 良かった点 まとめ 前提 基本的にコドモンでは開発を進める際に、ユーザーストーリーを作成します。私が所属するチームでは、機能を開発する際にPdMがカスタマーサポートなどのビジネスサイドのメンバーから要件をヒアリングした後に機能の仕様を整理し、ユーザーストーリーの一覧を作成します。 その後、PdMと開発メンバーでユーザーストーリーの読み合わせをし、ストーリーポイントを付けていました。しかし、この方法には課題がありました。 チームが抱える課題 PdMが事前に作成したユ

こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ

こんにちは。品質管理部のブロッコリーです。 現在、品質管理部ではQA（Quality Assurance, 品質保証）エンジニア、テストエンジニア、シニアテストエンジニア、SET（Software Engineer in Test）の募集をしています。 この中で、10Xが目指している品質管理部全体の姿については、以前に記事にしています。（記事公開当時は「品質管理部」ではなく「QAチーム」と表現しています） product.10x.co.jp 品質管理部全体については示したものの、SET職種について明確に何を求めているのか示すことができていませんでした。そのため、SETで応募しようか悩んでいる方にも分かりづらい形になっていたと思います。 そこで10XにおいてSETに求めることを言語化したので、本記事ではそれを紹介していきます。 本記事で言いたいことを3行で ただ単にテストコードを書くことでは

個人開発やってると、正直、「動くものを作るのに精一杯で品質のこと考えている余裕がない」と思うことが頻繁にある。 QA界隈では「開発チーム（実装担当者やPdM、デザイナー等ステークホルダー）に対して品質を意識する文化を築いていこう」的なムーブメントがあるように思うんだが、これって彼らにとっては結構な負担じゃないか、などと想像したりする。 僕のソフトウェア開発スキルが弱いだけかもしれないが、僕がQA以外のステークホルダーだったら「いや趣旨は分かるんですが実際問題こっちも余裕なくてですね、、」と言いたくなりそうな気がしている。 各企業のテックブログなんか読んでいると、「開発者が品質を意識してくれるようになりました」「E2EテストやAPIテストを実装してくれるようになりました」みたいな記事が散見されるんだけど、これって開発者の（品質を意識することにより増幅した）負荷をどれくらい考慮したものなんだろ

従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追われる中で実装されたソフトウェアは、動作確認も十分にされない状態でテストフェーズをむかえることになる。こうして品質の保証は、テスターに丸投げにされるというのが実態ではないだろうか。もちろんここでテスターに丸投げされているのは外部品質、特に機能面での品質の保証のみだ。非機能面での品質の保証は手薄になり、内部品質は顧みられることはない。 これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすく

最小限のコードで動く最も汚いコードから始める 2023.09.02 コードを書く際の重要な要点は、読みやすく他人に理解される「良いコード」を書くことです。しかし、完璧を目指して最初から書こうとすると行き詰まります。代わりに、荒削りながらも動くコードを作成し、徐々にリファクタリングして完成度を高めます。型エラーやリントエラーを無視しても構わないので、まずは動くものを作成しましょう。それからリファクタリングして「良いコード」を作成できます。 コードを書くときに最も大切なことってなんだろう？聡明な読者諸君ならご存知だろうが、コードは書く時間よりも読む時間のほうが長い。だから他人に読まれることを意識して、読みやすい「良いコード」を書かなくっちゃならない。コンポーネントは適切な粒度で分割されていて、適切な名前がつけられている。型システムに安全性だって守られてるし、最新のなんとかアーキテクチャにも準拠

［CEDEC 2023］「テストエンジニアが伝える　テストを実施する前に考えるべきテストの話」聴講レポート。開発が参加し，欠陥を未然に防止するテストの大切さ ライター：箭本進一 ゲーム開発者向けカンファレンス「CEDEC 2023」で，「テストエンジニアが伝える　テストを実施する前に考えるべきテストの話」と題された講演が行われた。ソフトウェアを作る前に一歩立ち止まり，必要になるテストについて打ち合わせをすれば，コストや手間を削減できるという。ソフトウェアのテストといえば，完成後に行うものというイメージがあるが，その前に行うべきテストとは，どのようなものなのだろうか？ 開発が参加し，欠陥を未然に防止するテストの大切さ 10X / B-Testing Qualityチームの風間裕也氏 講演を行ったのは，10X / B-Testing Qualityチームの風間裕也氏。ソフトウェアのテストに関す