はてなブックマーク

「アジャイルテストの4象限」についてのやりとりをTwitterでみていて、James Bach、Michael Boltonの両氏が何年か前に公開していた『The New Agile Testing Quadrants』という資料を読み直してみました。 The New Agile Testing Quadrants: Bringing Skilled Testers and Developers Together - James Bach from Ho Chi Minh City Software Testing Club www.slideshare.net 今Twitterで話題になっているのは全然違う文脈ですが、この記事では彼らの批判と提案について紹介します。 作者について JamesとMichaelのお二人は、『Exploratory Testing 3.0』（探索的テスト3.0

ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されて

『土台からしっかり学ぶ ソフトウェアテストのセオリー』を、著者のお一人経由でリックテレコムさんからご恵投いただきました。 土台からしっかり学ぶーーソフトウェアテストのセオリー 作者:小川秀人,佐藤陽春,森 拓郎,加賀洋渡リックテレコムAmazon ここまで書いたらNotion.AIが勝手に以下のように書いてくれた。。 もう自分いらんな*1。。 本書は、ソフトウェアテストに関する基礎的な理論から実践的なテスト手法まで、幅広くカバーしています。特に、UTPの紹介や非機能テスト、自動化テスト、CI/CDの広義的な捉え方など、現代のソフトウェア開発に必要不可欠な内容が詳しく解説されています。また、著者による豊富な実務経験を踏まえ、実際のツールの使い方にも触れています。 感想の前に 本書の著者の方の何人かは、会社やコミュニティでのお付き合いがあります。また書籍自体も、レビュー用に出版社からいただいた

ChatGPTでテスト設計してみた記事と、そのアンサーソングを見つつ、また色んな人が色んなことをやってみた記事をみてChatGPTのすごさがあらためて伝わってきました。両方ともとても面白い記事です。 zenn.dev nihonbuson.hatenadiary.jp 一方、わたしのは埋め草で、特に難しいことはしていません。 仕様についてChatGPTに質問してみて、その回答と自分の期待値を比較してみようという実験です。 曖昧な仕様についての質問 初めに、とてもシンプルな質問をしてみました。 「曖昧」とは何か、「バス」とは何か、みたいなことはまったく配慮してあげなくていいはずなのですが、なぜか「機械でも読み取れるように」ちょっと気遣っている自分がいます。 以下の仕様に曖昧な点があるか、教えてください。 「バスの料金は、10歳以下が無料です」 この質問の意図は、「自然言語で書かれたスペックの

Developers Summit (デブサミ) 2023で、「テストを学んでみたい開発者のためのソフトウェアテスト読書マップ」という発表*1をしてきました。 event.shoeisha.jp 資料はこちらです。 speakerdeck.com これまで、ソフトウェアテストとかQAの世界でばかり聴講やら発表やらをしておりまして、その外に出る機会があまりありませんでした。 今回、イベント主催者の翔泳社様から発表の打診をいただき、かなり腰が引けていたのですが、「これを機に、もうちょっと外に目を向けよう」という無理やりな動機付けで場を借りることにしました。 といっても結局発表はテストに関することですし、全然外に出ていないのですが・・・まあそれはこれからってことで。 今回は、ソフトウェアQAエンジニアの有志が一気呵成に作り上げた『ソフトウェアテスト読書マップ』を借りた発表であり、みなさんの成果を

2022年9月9日にこんなツイートをしたところ、 ソフトウェアテストの書籍・資料について、こういうマップを作ってみたい。「QA関連」でできるといいんだけど、縦軸が定まらない。 一番繰り返し読んでいるドリル本をサンプルにしてみたけど、テスト分析自体がすでに初級じゃない気もするから、色付けも難しい。うーん。 誰か一緒にやりません？ｗ pic.twitter.com/R0lVJhcpkD— Kazu SUZUKI (@kz_suzuki) 2022年9月9日 「一緒にやってもいいよ～」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました！ みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。 ということで、以下に公開します！ docs.google.com 「閲覧者（コメント可）」というアクセス権を設定しています

"Sanity check" by foreverdigital is licensed under CC BY-NC-ND 2.0 「サニティテスト」（sanity test）という言葉を聴くことがちょいちょいあったので、意味を捉えておきたいなと思っての記事です。なお、「本当の」「正しい」定義を見つけることが目的ではなく、「こんな風に捉えられていることが多そう」を理解することを意図しています。 また、調べる過程で、自分がかつてまとめた以下のtogetterも見つけてしまったので、「テストタイプなのか、テストレベルなのか、テストフェーズなのか」 という議論も、ここではしません。 togetter.com I/JSTQBでは まずはいつものここからですね。 結論からいうと、サニティテストはスモークテストの類語とされています。 スモークテスト（smoke test） 定義・計画した全テストケー

同僚に紹介してもらった「Modern Testing Principles」、わかりやすくていいなと思ったので、許可を得て翻訳してみました。原文のブログ「AB Testing」は、ABテストとは関係なくって、PodcastとSlackを主宰しているAlanさんとBrentさんの名前からですね。 www.angryweasel.com なお、Work in Progressということで今後も変更されていくようなので、現時点での原文を引用しておきます。 Our priority is improving the business. We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bot

これすごい面白い。「ソフトウェアプロジェクトでのめんどくさい人の扱い方」 https://t.co/v6POEoWLSB— 加藤公一（はむかず） (@hamukazu) November 30, 2018 こちらのツイート*1を見て、さっそく見に行ってきました。 美しい色使いで構成されたこのサイト、そこにあるスタイリッシュな動物アイコン群はそれぞれ、「めんどくさい人」の象徴でもあります。 「めんどくさい人」はまず以下のロールに分けられています。 プロダクトマネジャー デザイナー プロジェクトマネジャー 開発マネジャー 開発者 品質保証（部門） アイコンをクリックすると、「めんどくさい人」が以下の構成で説明されています。 定義と特徴 修正の見込み プロジェクトへの弊害 問題点 対処法 アンチパターン集と、ソフトウェアバグのアナロジーを混ぜたような感じですね。 それぞれのロールにカテゴリーがあ

『実践アジャイルテスト』の著者である、Janet Gregory、Lisa Crispinの両氏による『Our Definition of “Agile Testing”』という記事を、許可をいただいて翻訳してみました。 agiletester.ca この本、勢いで買って店晒しにしておったのですが、最近やっと読み始めまして、とても気に入っています。あらゆる経験、知識、エピソードをとにかくぶっこんでみた！という勢いと厚さが好きです。つまみ食いでも得られるものがあると思いますので、未読の方はぜひ。 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践) 作者: Janet Gregory,Lisa Crispin,榊原彰,増田聡,山腰直樹,石橋正章出版社/メーカー: 翔泳社発売日: 2009/11/28メディア

「日本の製品は過剰品質なのでコストが高くなり、グローバルで売るのが難しい」といった主張を聞いたことはないでしょうか。 このような主張がなされるとき、本当に現状を憂えている場合もあれば、「日本製品の品質の高さ」をどこか誇っているようなこともあります。 それでは、「過剰品質」とは何を指すのでしょうか。 品質特性と顧客価値 JaSST'24 北海道の発表資料*1で、当日言及できなかったスライドを、Twitterに放流してみました。 JaSST北海道では言及する時間のなかった、「過剰品質」についてのスライドの供養。 日本企業が過剰品質を自嘲する時、「当たり前品質」を頑張り過ぎる➋を言っているつもりが、実は「当たり前品質」も上がっていない➊になっていないか？というのが言いたかったことでした。 過剰品質とは？ かけた労力に対して、品質*2や顧客価値がどう変化するかでマトリクスを作ってみましょう。 価値

今年の4月に『Mythical Unit Test Coverage』（ユニットテストカバレッジの神話）という論文が出ました。ソースコードの品質指標として言及されることの多いコードカバレッジについて、先行研究を整理したうえで、商用の大規模ソフトウェアにおける追加検証をしたものです。IEEEのサイトでも全文公開されています。 Mythical Unit Test Coverage - IEEE Journals & Magazine 長い論文ではないのですが、わたしには論理展開のわかりづらい部分があったので、整理してみました。 アブストのアブスト 「リリース前にどれだけのテストをすべきか」というのはずっと問題。 テストの十分性の指針として、Ericssonで長年使ってきたユニットテストのカバレッジのクライテリアを検証した。 結果として、ユニットテストカバレッジは、欠陥のないソフトウェアを作る

タイトルは釣りです。そして、タイトルを見て「デグレード？ 何？」と感じた人は幸せかもしれません。 先に結論を言うと、「デグレード」という日本語は、「degrade」という英語と対応しないそうです！ デグレードとリグレッション わたしがこれを知ったのはつい先日、以下の記事を読んだ時でした。 itpro.nikkeibp.co.jp DegradationとRegression　ソフトウェアのプログラムコードに手を加えると、それまで正常に動作していた機能がうまく動かなくなることがあります。これをRegressionというのですが、なぜか日本人はほとんど全員が「デグレ」と言う。デグレと言うと、Degradation（劣化）のことを指し、本来は性能劣化という時に使う単語です。 えーーー！ まさにこの記事にもあるように、ぼくもまた、「デグレード」「デグレ」という言葉を、「ソフトウェアが備えていた機能

アジャイル開発において、プロダクトや組織の現状を把握するのに役立つメトリクスを知りたいと思い、「agile kpi」などでググって上位のサイトを読むという丁寧なサーベイを敢行。20個くらい読んでいくとだいぶネタも尽きてきたので、整理してみました*1。参考にしたサイトについては、記事の最後に載せておきます。 なお以下では、アジャイル開発とスクラム開発をほぼ同じ意味で使っていますが、怒らないでいただきたいですね。 メトリクスとKPI メトリクス（metric / metrics*2）とKPIはごちゃごちゃに使われがちです。こちらの資料では、以下のように説明しています。 Agile KPIs from Gaetano Mazzanti www.slideshare.net メトリック: プロセス・プロダクト・チームの定量的な評価・制御・改善のための物差し、またはその組み合わせ KPI: 戦略的な

GoogleのテストマネージャーであるJohn Micco氏の、Flakyなテストについてのチュートリアルの内容は、こちらに書き尽くされています。なので、あらためてその復習記事を書くことはないのだけれど、SQLの勉強も兼ねて、要点を絞って振り返っておきます。 nihonbuson.hatenadiary.jp togetter.com Micco氏のお話の要点は、以下の2つだとわたしは考えています。 自動テストが膨大になると、効率よい順番で実行したり、適切に間引いたりすることが重要である。 シンプルな記録であっても、積み重ねればさまざまな洞察を導くことができる。 この記事では、上述の2つを踏まえてチュートリアルを振り返るとともに、せっかく権限をもらったGoogleさんのログで、少し遊んでみたいと思います。 膨大な自動テストの効率を上げるには Micco氏の資料*1によると、Googleで継

先日のJEITAのイベントで、メタモルフィックテスティング（Metamorphic Testing、MT）というものを知り、「誰かMetamorphic Testingの勉強会やりませんか？」とブログに書いたところ、ソフトウェアテスト・ヒストリアンの辰巳さんが資料をたくさん紹介してくださいました。ちなみに、一緒に勉強してくれる人は誰もいませんでした。 www.kzsuzuki.com その後、自分でいくつかMetamorphic Testingに関する資料を集めましたので必要なら声をかけてください。また、ICSE 2017併設Workshopで MET: 2nd International Workshop on Metamorphic Testinghttps://t.co/Lrb54PufzU が開催されています。基調講演slidesがダウンロードできます。— Keizo Tatsum

NPO法人ソフトウェアテスト技術振興協会（ASTER）の研究事業として、STE（Software Testing for Enterprise systems）という活動があります。エンタープライズ向けシステム開発におけるテストについての議論を行うもので、ぼくはその交流会に参加しています。 STE研究交流会として、広くユーザやベンダ、学術の方を集め、上記課題に対する情報や意見交換を行ないます。また、海外におけるエンタープライズシステム向けのソフトウェアテスト事例などの紹介も行なう予定です。（公式サイトより） 先日、第2回が催されました。 メインとなるトピックは、「シナリオテスト」です。人によって意味合い・位置づけの違うシナリオテストを、JSTQBやISO29119の言葉を借りて定義しつつ、その方法論を考えていこうというものです。 2時間半ほどの時間がありましたが、シナリオテストに対するメン

コロコロコミック vs ボンボン、VHS vs ベータ、Mac vs Windows、Vim vs Emacs、きのこの山 vs たけのこの里、IE vs Netscape、ビックリマンチョコ vs ガムラツイスト、EU残留 vs EU離脱、ビアンカ vs フローラ、高橋名人 vs 毛利名人・・・。 たくさんの対立軸がある中、アジャイル vs ウォーターフォールの争いも、定期的に勃発しています。今回はここから始まったのでしょうか？ www.infoq.com アジャイル vs ウォーターフォールは開発方法論の争いですが、みなさん、ソフトウェアテストの世界にも陣営があることをご存知ですか？ そんな話がこちらで紹介されていました。 Software Testing Schools: All we need is world peace.breakingembeddedsoftware