Mark Ward @mkwrd 流行っているから元のスライドもご紹介します。ITエンジニアの分類の一つ「テスター（テスト・品質の専門家）」の仕事と自己研鑽についての資料で、ぼくが2020年6月に書いて登壇したものです。 speakerdeck.com/mkwrd/200610-t… 2024-02-14 20:09:41
Q. 妹は何歳でしょうか？ プログラマー「44 - 2 = 42だよね」テスター「これは容易には答えられないな」テスターに求められるスキルとは
Mark Ward @mkwrd 流行っているから元のスライドもご紹介します。ITエンジニアの分類の一つ「テスター（テスト・品質の専門家）」の仕事と自己研鑽についての資料で、ぼくが2020年6月に書いて登壇したものです。 speakerdeck.com/mkwrd/200610-t… 2024-02-14 20:09:41
テストコードにはテストの意図を込めよう #vstat
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート（過去のJaSSTの講演資料などが載っています） ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
ソフトウェアの品質を学びまくる
2024年5月、デジタル庁から『テキスト生成 AI 利活用におけるリスクへの対策ガイドブック（α版）』が公開されました。 www.digital.go.jp 本書自身が「α版」として以下のように注記している通り、生成AIについて特に詳しいわけではもないわたしから見ても、記述に不十分と感じられましたが、「叩き台を作る人はえらい」派の人間なので、このようなものを公開してくれたことに感謝したいです。 実践的なフレームワークやチェックリストによるガイドブックを作成できるまでの知見が蓄積されていないため、留意点の紹介にとどめる。 この記事では、本書の中の特にテスト・品質保証について感じたことを書きたいと思います。本書の概要や構成などについてはすっ飛ばします。 「４ 調達実施前時のテキスト生成AI固有の留意点」について 「４ 調達実施前時のテキスト生成AI固有の留意点」*1では、 AIの利活用を計画し
書籍『インフフラ/ネットワークエンジニアのためのネットワーク「動作試験」入門』がもはや「先輩」だった - てくなべ (tekunabe)
はじめに 『インフフラ/ネットワークエンジニアのためのネットワーク「動作試験」入門』を読みました。とても良い本でした。 www.sbcr.jp Amazon.co.jp はこちら （電子版が試し読みできます） なかなか扱われることの少ない動作試験に絞った書籍であることと、「インフラ／ネットワークエンジニアのためのネットワーク技術＆設計入門 第2版」や「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン」など素晴らしい書籍の著者である、みやたひろしさんの書籍であるという点で、とてもたのしみにしていました。 ポートの状態などを確認する単体試験、機器を接続してルーティングなどを確認する結合試験、冗長機能が正常か確認する障害試験、ほか性能試験や長期安定試験について、考え方や手順などが書かれています。 初学者の頃に、現場の先輩に試験の方法を教えてもらい「こういうのありがたいなぁ。
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
Qbookアカデミー | Qbook
「Qbook アカデミー」 サービス終了のお知らせ 平素よりQbookをご愛顧賜りまして誠にありがとうございます。 この度「Qbookアカデミー」は、新規サービス開発のための改修に伴い、2023年7月3日をもちまして、サービス終了とさせていただきます。 ■サービス終了日：2023年7月3日（月） ■終了対象サービス：Qbookアカデミー ご利用のお客様には、大変ご迷惑をおかけいたしますが、何卒ご理解いただきますようお願い申し上げます。 長らくのご利用、誠にありがとうございました。 「Qbookアカデミー」にて公開していた内容につきましては、一部 「記事一覧」 よりご覧いただけます。 また、ソフトウェア品質のスキルアップ・教育コンテンツとして以下もご活用ください。 ・eラーニング講座 ・ソフトウェア品質教育サービス「バルカレ」 今後とも皆様に上質なコンテンツを提供できるよう努めてまいりますの
コードは2回書きたい - Mitsuyuki.Shiiba
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
和田卓人さん（t-wadaさん）をお招きし、「質とスピード」の社内講演会を開催しました - STORES Product Blog
2022年6月7日に、テスト駆動開発者の和田卓人さんをお招きし、社内講演会をオンラインで開催しました！ 経緯 弊社では、2022年3月にテクノロジー部門のマニフェストとバリューができました。CTO 藤村が「和田さんの「質とスピード」のお話はテックバリューにも通じるところがあるのでは？」と思い、和田さんのお話をみんなに聞いてもらおうとお招きすることになりました。 結論：めっちゃ盛り上がりました 和田さんの講演会をアナウンスした時の盛り上がり 事前アナウンスでも盛り上がったのですが、当日はもっと盛り上がりました！ 和田さんのアドバイスを受けて、講演会専用のSlackチャンネルを作成したのですが、講演当日の投稿数は1,223！リアクション数は1,540でした！月に一度開催される全社レビュー会での投稿数が数百なので、桁違いの盛り上がりです。同時視聴数も200人を超え、エンジニアだけでなく、色んな職
肥大化し続けるソフトウェアをどうテストする？ アジャイル時代のソフトウェアテストに必要な考え方
肥大化し続けるソフトウェアをどうテストする？ アジャイル時代のソフトウェアテストに必要な考え方：海外企業に学ぶテスト自動化（終） 海外の先進的企業の事例を基にテスト自動化に使われる手法を解説する本連載。最終回は、アジャイル開発におけるテスト自動化において重要な考え方とは何かを解説する。 これまでの連載でミューテーションテストとカオスエンジニアリングを紹介しました。先進企業においては「時間はお金で買うもの、特に品質担保の時間はなるべく少ない方がいい」「テストの時間がゼロになるならお金はいくらでもつぎ込みたい」というのが本音だと思います。GAFAM（Google、Amazon.com、Facebook、Apple、Microsoft）は十分な利益があるのでお金で時間を買って先行者利益を得たいはずだと筆者は考えています。Googleのあるテスト担当者は「私たちはマニュアルテストをしている時間がな
和田卓人さん（t-wadaさん）によるオンライン講演「質とスピード」を社内で開催しました！ - Chatwork Creator's Note
みなさん、テストしてますか？ プロダクト本部 副本部長の田中（Twitter：@tan_yuki）です。DevHRチームにも所属しています。 DevHRではチーム活動のひとつとして、社内勉強会の企画をしています。最近、あのTDDで有名な和田卓人さん（Twitter：@t_wada）に依頼し、「質とスピード」という内容の社内講演（オンライン）をしていただきました！ DevHRってなに？という方はこちらの記事を参照してください。 creators-note.chatwork.com 今回は、開催した「質とスピード」の社内講演に関する詳細についてまとめていきます。 社内講演のきっかけ もともと、弊社のテックリードであるかとじゅん（Twitter：@j5ik2o）が、和田卓人さんのTDD講習を受けたことをきっかけに「社内でt-wadaさんの講演を依頼してはどうか？」という話になりました。 社内チャ
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる - やっとむでぽん
「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。 「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。 」 テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用 セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、本当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。 絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15 ※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています P17 概説テスト分析 http://www.slideshare.net/takashiyamasaki378/ss-55384920 P29 システム/
ソフトウェアテストはなぜやるのか誰がやるのかについて考えてみる / why who testing
アジャイル開発研修の中で、ソフトウェアテストってなぜやるの？誰がやるの？って話をしたときの資料です。
「仕様通りだけど使いづらい」を解消する、探索的テストの考え方
「仕様通りだけど使いづらい」を解消する、探索的テストの考え方：アジャイル開発における品質管理（4） 少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。前回から、スプリント内でのテストと品質保証について、2回に分けて解説している。後編となる今回は、探索的テストとアジャイル開発における品質改善事例について。 前回は、アジャイル開発におけるスプリント内のテストと品質保証について「完成の定義」や「受け入れ条件」の設定、テストの考え方の一つである「V&V」について解説しました。 前回の内容と重複しますが、V&VとはVerification（検証：以下、ベリフィケーション）とValidation（妥当性確認：以下、バリデーション）の頭文字を取ったものです。ベリフィケーションとは、「仕様通りに作
工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは
工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは：アジャイル開発における品質管理（3） 少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。今回は、スプリント内でのテストと品質保証について、2回に分けて解説する。前編となる今回は要件設定とV&Vについて。 アジャイル開発において、テストをどのように実施するかは難しい問題です。短い開発周期で、設計、実装にしっかり時間をかけようとすると、それに伴ってテストを実施する時間は少なくなります。結果として、テストがスプリント（※）内で収まらず、テストのタスクを次のスプリントに持ち越してしまいます。結果として本来のタスクに着手できず、プロジェクトが停滞してしまうことも考えられます。 （※）アジャイル開発におけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストプロセスを用いて、テストケース作成の思考を整理しよう / test process