皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ

speakerdeck.com 「技術力がある」とか「技術力あげたい」とかそういう話をしているが、技術力とはなにかが曖昧だと最近思っていたので自分の中の定義をプロダクト本部のLT大会で話した。 自分は10xを創る組織とはなにかに興味がありこの会社にいるのだけど、それは個人/組織が成長し続ける組織であるという仮説を自分は持っていて、プロダクト開発・運用という視点で個人の成長に必要なものとはなにかを考えたという話でもある。 もらった質問や感想など 訂正しやすくつくる力、外から中々見えにくい 見るというのはある意味評価するということだと思いますが、自分は人間が客観的に正しく人間の評価を行うのは無理*1だと思っていて、ましてや外(社外やチーム外、別職種)からはほぼ確実に無理でしょと思っています。なので中から外に説明する必要がある。 今回の話は、中*2で見えている評価をどうやって外に説明するかという

https://x.com/HighWiz/status/1817197569099051158 マリーアントワネット「検証機がないなら，本番環境を使えばいいじゃない。」 これに対し，日本のITエンジニアたちは激おこである。 そして大半が本番環境でテストをするのはけからんという話に終始している。これが日本の姿である。 まるでオライリーの「オブザーバビリティエンジニアリング」で書かれていた本番環境をガラスの城として扱っているパターンそのものって感じがある。 https://netflixtechblog.com/tagged/chaos-engineering 一方，Netflixのようなグローバル大企業はすべからく本番環境でテストを行っている。 彼らは惑星規模の計算資源とその上で稼働する大規模なマイクロサービスを運用しているので，事実上，本番環境と同等の検証環境を作ることができない。 さら

こんにちは、教育系のスタートアップでCTOをしていたヒガシ(@suica_versa)と申します。 表題の通り、私は約6年前から教育機関向けのシステム開発を行うスタートアップでCTOとして働いていましたが、7/10付けで破産開始決定が申し渡されました。 破産に伴い、取引先をはじめ関係各所には大変なご迷惑をおかけしていることを経営メンバーの一人として、謝罪いたします。 このnoteでは、なぜ破産に至ったのか？破産の手続きってどういう内容？破産するとどうなる？という、スタートアップではなかなか語られない点について同じ轍を踏まないよう共有いたします。 ただし、まだ本件については進行中ですので、ある程度内容は省いている点をご容赦ください。 【免責】 当記事は私が所属していたDoorkel社の正式な文章ではございません。内容については時系列含め不正確なものも多々ございますので、あくまで1社員の視点か

前年5位から昨シーズン2位、そして今シーズンも2位につけている千葉ロッテマリーンズ。かつて筑波大学大学院でコーチングを学んだ経験もある吉井理人監督のチームマネジメントのひとつが「心理的安全性の担保」だ。野球未経験者の意見を積極的に採用する方針の背景にあるものとは何か――。 【画像】2023 ワールド・ベースボール・クラシック日本代表の吉井理人コーチ。東京ドームにて ※本稿は、吉井理人『機嫌のいいチームをつくる』(ディスカヴァー・トゥエンティワン)の一部を再編集したものです。 ■2位に食い込む千葉ロッテマリーンズ・吉井理人監督の“会議術” 2024年シーズンの春季キャンプに入る前、1月10日にスタッフミーティングを行った。2023年シーズンに入る前に行ったミーティングをバージョンアップさせたものだ。 人数も30人から40人に増やし、2023年には参加していなかった栄養士、カウンセリングのドク

こんにちは、ソフトウェアエンジニアの@futaboooです。 先日スクリーンリーダーへ対応したプレスリリースを配信しました。今日はその裏側について紹介です。 10x.co.jp はじめに とあるパートナーのネットスーパーシステムをStailerへリプレイスして少しすると、お客様から「今まで使えていたのに使えなくなった！」という切実な声が届きました。この問い合わせを通じて、視覚障害者のお客様がスクリーンリーダーを使って買い物をしていたこと、そしてStailerがそのニーズに応えていないことに気づきました。 そこで、我々は視覚障害者のお客様へのヒアリングを開始し、どのような環境でアプリを使っているのか、使用しているデバイスやスクリーンリーダーソフトウェアの種類など、具体的な情報を収集しました。このプロセスを通じて、アプリがより多くの人々にとって使いやすいものになるための重要な改善点を発見しまし

読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ

はじめに本記事は「ソフトウェアテストの教科書 [増補改訂 第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の正