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

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

はじめに この記事は10X 創業6周年アドベントカレンダーの15日目の記事になります。 昨日はアプリケーション開発部のjojoさん*1が、「10Xに入社した、そして4ヶ月後…」という記事を公開しています。 本記事では2023年5月に10Xに入社した私が、入社1ヶ月目に実際に行った、ソフトウェアテストプロセス（以下、テストプロセスと表記）に基づいたテストケース作成についてお話しします。 目次 はじめに 目次 テストプロセスに基づいたテストケース作成を行おうとしたきっかけ 前提：プロセスとは何か？ プロセスの例 テストプロセスを考えよう 今回定義したテストプロセス テスト分析 テスト対象分析 テスト要求分析 テスト設計技法の選択 テスト設計 テスト実装 記事冒頭の例が分かりづらかった理由 実際に適用した例 レビュー内容 今後の展望 おわりに テストプロセスに基づいたテストケース作成を行おうとし

はじめに 〜記事執筆のきっかけ〜 先日、以下の記事についてのツイートが流れてきました。 zenn.dev この記事の内容については、ChatGPTをはじめとするAIによるテストの可能性を示した素晴らしい内容だと思います。 ですが、果たして"今時点（元記事の執筆時点）の"出力結果*1が実用に耐えうるものになっているのか検討し、提示する必要もあると感じました*2。 そこで本記事では、テストエンジニアである私の回答例と"今時点の"AIの出力結果を比較しギャップを示すことを目的とします*3。 決して、AIによるテスト自動生成の進化自体を否定している訳ではないことを念頭にお読みいただければと思います。 結論 本記事では、"今時点の"AIの出力結果に対して、以下の結論を導き出しています。 状態遷移図のテスト設計の題材では、根幹となる機能に関する不具合が含まれていた デシジョンテーブルのテスト設計の題材

はじめに〜本記事の目的〜 2020年の4月に実例マッピングを日本語訳で紹介してから3年弱で、色々な人が実例マッピングを試しています。 本記事では、これから実例マッピングを試そうとしている人向けに、実例マッピングに関する日本語情報を提供することを目的としています。 目次 はじめに〜本記事の目的〜 目次 実例マッピングとは何か 考案者による実例マッピングの説明記事 実例マッピングの説明スライド 実例マッピングの説明記事 実例マッピングについて言及している書籍 The BDD Books - Discovery Agile Testing Condensed 実例マッピングの実践報告 アルプ株式会社様 実践報告スライド 株式会社リンクアンドモチベーション様 伊藤忠テクノソリューションズ株式会社様 株式会社サーバーワークス様 aki.mさん 株式会社永和システムマネジメント様 実例マッピングを利用

はじめに 本記事は、ソフトウェアテスト Advent Calendar 2022の5日目の記事です。 本記事では、ソフトウェアテストと一緒に語られることが多い品質について、野球を題材に考えてみたいと思います。*1 ちなみに、もっときちんと品質について考える機会として、次回のWACATEがあるので、品質に興味がある方はそちらのご参加も検討してみてくださいね。（唐突な宣伝） wacate.jp 目次 はじめに 目次 ソフトウェア品質とは何か スポーツと品質 野球と品質 落合博満元中日ドラゴンズ監督の戦略 バレンタイン元千葉ロッテマリーンズ監督の戦略 千葉ロッテマリーンズの河合克美オーナー代行兼球団社長の戦略 品質基準と最終的な目標との関係性について ソフトウェア品質は野球の品質よりも難しい？ おわりに ソフトウェア品質とは何か Wikipediaの「ソフトウェア品質」のページには、以下のように

目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North

先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】

はじめに 本記事はソフトウェアテスト Advent Calendar 2021の22日目の記事です。 今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述したいと思います。 前編である本記事では、テスト実装までの話を書きます。 発表スライド＆発表動画 speakerdeck.com www.youtube.com 目次 はじめに 発表スライド＆発表動画 目次 今回のお題 因子水準を考える 因子水準表を元に全組み合わせを書く 予約番号の印刷を任意にする 名前に関する条件と人数に関する条件を別表に分ける 名前と人数の条件を掛け合わせる必要もあるのでは？ 人数の同値クラスを考える 合計人数という因子を追加する ここまでのまとめ テスト観点との関係性について考える 初期のテスト観点 無則な観点を削った場合 人数の条件でま

はじめに（翻訳記事の前提となる知識など） 本記事は自動テスト・テスト自動化Advent Calendar 2021の7日目の記事です。 最近、BDDなどでのテスト自動化を行うにあたり、Discovery（発見）*1→Formulation（定式化）→Automation（自動化）という流れが考えられるようになりました*2。 記事「Behaviour-Driven Development」内の画像を引用し翻訳 この中の「定式化」では、後に自動化するテストシナリオの整理を考えます。*3 テストシナリオを作成する際に、ただ単にGherkin記法（Given/When/Thenなどを用いた記法）を利用するだけでは、保守性の低いテストシナリオが作られてしまいます。 そこで今回は、保守性の高い状態でテストシナリオを記述する際に役立つ原則「BRIEFの原則」について書かれた記事「BRIEFの原則を保った

はじめに 本記事はテスト駆動開発 Advent Calendar 2021の1日目の記事です。このアドベントカレンダーはスカスカなので、テスト駆動開発の経験談などをエントリーしてもらえると嬉しいです！ qiita.com 目次 はじめに 目次 本記事で伝えたいこと 今回のお題 新しいテストケースを考えて対応する サイクル2周目の「3.そのテストを実行して失敗させる」 サイクル2周目の「5. 2で書いたテストを成功させる」 サイクル2周目の「6. テストが通るままでリファクタリングを行う」 関数を呼び出す形に変更する テストケースを1つ削除する メソッドをインライン化する おわりに 本記事で伝えたいこと TDDをやっている皆さんは、下記のサイクルをご存知の方が多いと思います。 見てわかるテスト駆動開発 / TDD Live and Workshop 2019 Spring - Speaker

JaSST Reviewを今年も開催します。4回目の開催です！ 本記事では今回の見どころをざっと紹介していきます。読んだ上で興味がある発表がありましたら、ぜひイベントに参加登録をお願いします！ www.jasst.jp 目次 目次 JaSST Reviewとは何か 今回のJaSST Reviewのテーマ 顧客が本当に必要だったもの 今回のJaSST Reviewで掘り下げていきたいところ おわりに JaSST Reviewとは何か JaSSTとはソフトウェアテストシンポジウム（JaSST）のことで、2003年から全国各地で開催されているテストのイベントです。全国で年間10回以上開催されています。 そしてJaSST ReviewはJaSSTの一つで、ソフトウェアレビューに特化したイベントです。 詳しくは以前書いた下記記事を参照してください。 nihonbuson.hatenadiary.jp

はじめに 最近、下記のようになっている人を見るようになりました。 「Aさんは私の知らないテスト技法を知っていてすごい！それに比べて私なんか…」（自分への劣等感） 「Aさんは私の知らないプラクティスを教えてくれる！だからAさんはなんでも解決できる神のような人だ…！」（盲目的な信者） ただ、それは自分の知らないことを知っているだけであって、必ずしもその人（Aさん）が素晴らしいかどうかはちゃんと見分けないといけないと思っています。それはどういうことなのかを、中学数学の例を使って説明してみようと思います。 目次 はじめに 目次 二次方程式の解き方 因数分解を用いて解く方法 解の公式を用いて解く方法 3人がとある入試問題を解く Xさんが入試問題を解く Yさんが入試問題を解く Zさんが入試問題を解く Yさんからはどのように見えるのか？ Zさんの吹聴に騙されてはいけない 日常でも同様のことが起きてないで

はじめに 業務中の自分の発言やSlackのtimesチャンネルを見返して、「これ、頻繁に伝えているなー」というものを書き出してみます。 自分の仕事上、Agile、Scrum、テストに関する話が多めです。 目次 はじめに 目次 「進捗に遅れが出ています」という発言が出てきたら 「プロダクトオーナーの動きを理解してもらえてないなー」と思ったら 「心理的安全性ってみんなで仲良くやることでしょ？」みたいな雰囲気になっていたら 「レトロスペクティブで有効なTryが出てこない」と言われたら 「TDDをちゃんとやれば品質を保証できるよね」「TDDってどこまでやるの？」と言われたら 「品質保証って、最後にテストすることなんでしょ？」と言われたら 「元々書いていたドキュメントと違うからバグチケットを起票する」とQAメンバーから言われたら 「進捗に遅れが出ています」という発言が出てきたら 入社直後の人が「進捗

はじめに 本記事はテスト駆動開発 Advent Calendar 2020 最終日の記事です。このアドベントカレンダーはスカスカなので、今からでもテスト駆動開発の経験談などをエントリーしてもらえると嬉しいです！ 目次 はじめに 目次 レガシーコードのリファクタリング 今回の題材 最初のテストコード 仕様を理解してテストを作る 別のテストケースを作る 依存関係を見つける 依存関係を削除する 作業前の状態 現在作成済みのテストケースが今回の狙いである依存関係部分の実装ロジックを通っているのか確認する テスト実行に影響があるロジックを切り出す テスト実行に影響があるメソッドにアクセスできる範囲を広げる テスト実行に影響があるメソッドをテストクラス内でOverrideする テストメソッド内で日付指定できるようにする 別のテストケースでもテスト実行ができるようにする おわりに：今回のレガシーコードの

はじめに 本記事はソフトウェアテスト Advent Calendar 2020 20日目の記事です。 TL;DR PICT/ペアワイズ/直交表で作成するテストケースは、特定条件下の元で網羅したテストである 「PICT/ペアワイズ/直交表によって全網羅したテストを作っている」と言うのは誤解を与えるのでやめておいた方が良い PICT/ペアワイズ/直交表を使う最適なタイミングが存在するので、PICT/ペアワイズ/直交表を毎回使うのではなく別の組み合わせテスト技法や単体テストの活用も検討しよう 目次 はじめに TL;DR 目次 「全網羅してます」 今回の例 今回の組み合わせテストのやり方 PICTを使用する PICTに設定する値 PICTで作成されたテストケース 今回の例の検証 作成したテストケースを考える 気になる内容 全網羅の落とし穴その1：網羅基準 全網羅の落とし穴その2：設定値 落とし穴に

目次 目次 はじめに TDD: 目的と実践 TDDとは何ですか？ TDDの意図 TDDはTestingですか？ TDDはユニットテストを書くことですか？ TDDだけで良いのでしょうか？ TDDは良い設計を強要しません 悪いテストはリファクタリングを妨げます なぜ悪評が多いのですか？ はじめに 今回は著者本人の許可をもらった上で、TDD: 目的と実践（原題は「TDD: Purposes and Practices」）を翻訳したので紹介します。 www.industriallogic.com この記事はIndustrial Logic社のTim Ottingerが書いた記事です。Tim OttingerはClean Codeの執筆にも関わっています。 Clean Code　アジャイルソフトウェア達人の技 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,花井 志生発売日: 2017/

一昨年から始まりましたJaSST Reviewを今年も開催します。3回目の開催です！ 本記事では今回の発表内容をざっと紹介していきます。読んだ上で興味がある発表がありましたら、ぜひイベントに参加登録をお願いします！ www.jasst.jp 目次 目次 JaSST Reviewとは何か 今回のJaSST Reviewのテーマ 講演1 : 専門書が出版されるまでの編集者の思考と行動　～編集者はどのように校正・校閲しているか～ 講演2 : ソフトウェア設計における意思決定とそのレビューの秘訣 事例紹介1 : 刺激語カードを用いたソフトウェアレビューの実践について ～アイデアを刺激し意識外から観点を得る 事例紹介2 : レビューイの力を引き出すフィードバックのチューニング～チーム外からの支援で見えてきた、成熟度に応じた「問いかけ」の調整方法と各種レビューへの適用可能性 おわりに JaSST Re

先日、社内のSlackでこんなことを言われました。 TDDとかのdrivenを駆動って訳すの誤訳じゃないのかと思うんですけど、どう思いますか？ 意味合いは駆動より操縦とか運転なんだと思うんですが そこで「駆動」の意味を改めて考えてみました。 辞書で調べてみる goo辞書では以下のように書かれています。 ［名］(スル)動力を伝えて動かすこと。「四輪駆動」「駆動輪」 書籍から考える 書籍『エクストリームプログラミング』の第2章には以下のように書かれています。 「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」 これがXPのパラダイムだ。注意して、適応して、変更する。 なぜ「駆動」が誤訳だと感じてしまったのか テスト駆動開発(TDD)は「test-driven developme

最近、周りで銀の弾丸を提供しようとしている人が散見されたので、思ったことをつらつらと。 「銀の弾丸を求めるな」というのは、「どんな場合でも活用できる万能なプラクティスなんて無いんだよ」という話だけではないと思ってます。 普段から同じプラクティスを使っている場合に、「本当にそのプラクティスが適切か常に見つめ直す必要があるんだよ」ということを伝えてるような気もしてます。つまり、「昔も今も未来も同じプラクティスを当てはめている＝銀の弾丸」となっていないかと見つめ直すことも大事なのでは？という主張です。 『人月の神話』より 書籍『人月の神話』の第16章「銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項」の一節 現代のソフトウェアシステムでこれ以上還元することができない基本的要素に含まれる固有の性質 の1つとして、可変性が挙げられています。 ソフトウェア実体は、つねに変更という圧力に