はじめに本記事は「ソフトウェアテストの教科書 [増補改訂 第2版]」という本について、ひとりのDirty Tester目線で批判する記事です。 本書はソフトウェアテストを勉強する上で入門書として紹介されることが多いですが、私の観測範囲内では批判的な意見を持っている人をよく見ます。 私もそのうちの一人です。 本シリーズでは具体的にどこが、どのように疑問を持つかを明らかにします。 それによって以下の効果を望みます。 初学者の人が批判的な視点でこの本を読み、テストエンジニアとして成長する この批判によって、より有益な第3版となって世に出る 本当に「ソフトウェアテストの教科書」に相応しい書籍になる 2章 ソフトウェア開発の流れとテスト工程とはへのクダウォーターフォール型開発モデル ソフトウェアテストの教科書 [増補改訂 第2版]p15僕は説明としていいとは思いますが、「ウォーターフォール」という言

今とりかかってる案件で、郵便番号から自治体を特定して云々という処理をやっているんですが、いくつかはまりポイントがあったので備忘録的にポストしときます 自治体コードは6桁のものと5桁のものがある これはすごく単純なお話で6桁のものは最後の1桁はチェックディジット 残りの上5桁から機械的に計算できます 郵便番号は必ず1つの町名に紐づいているわけではない 郵便番号→住所入力というフォームを作るときにハマる 例）郵便番号 807-0042 福岡県 遠賀郡水巻町 吉田 福岡県 遠賀郡水巻町 吉田団地 私の住んでいる宮城県にも 例）郵便番号 981-2114 宮城県 伊具郡丸森町 赤堀 宮城県 伊具郡丸森町 泉 宮城県 伊具郡丸森町 泉下 宮城県 伊具郡丸森町 大目 宮城県 伊具郡丸森町 北前 宮城県 伊具郡丸森町 天王 合併で旧・西春日井郡春日町を編入した愛知県清須市にこういうすさまじいデータがあり

※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20：UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/

書籍には、特定領域の専門家たちが習得してきた知識のエッセンスが詰まっています。だからこそ「本を読むこと」は、ITエンジニアがスキルを向上させるうえで効果的な取り組みと言えます。では、著名エンジニアたちはこれまでどのような書籍を読み、そこから何を学んできたのでしょうか。今回は7人の著名なエンジニアのキャリアに影響を与えた“珠玉の書籍”を、ご本人にまつわるエピソードとともに紹介してもらいました。 *…人名の50音順に掲載。回答者は敬称略。 あらたまが紹介『なぜ人と組織は変われないのか――ハーバード流 自己変革の理論と実践』 小田中育生が紹介『Measure What Matters: 伝説のベンチャー投資家がGoogleに教えた成功手法OKR』 風間裕也が紹介『ソフトウェアプロセス改善手法SaPID入門－現場力を引き出すシステムズアプローチ－』 小林謙太（kobaken）が紹介『組織開発の探究

以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。 上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。 その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。1 今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。 前提の確認 本題に入る前に、レビューとテスト分析とは何かという確認から行います。 「レビュー

はじめに 本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、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文字嵩んでしまっ