先日、接触確認アプリがリリースされました。これは正直日本のソフトウェアの進歩に画期的なことだったと思います。私も衝撃を受けました。 www.mhlw.go.jp その後起こったことに関して正直は私の感想はこの通りです。 日本で起こっている地獄を見て、アプリ開発者は海外に流出してしまうわって思う。あの流れは最低最悪。みんな自分が気持ちよくなるためだけに、自分の国の未来を破壊してるんやで。— TsuyoshiUshio (@sandayuu) June 21, 2020 このような展開は、私が今住んでいるアメリカでは発生しない事案だと思います。じゃあ、日米でどういう違いがあって、日本人の自分が小さな一歩を踏み出して、日本がよりよい国になるようにできるとしたらどんなことだろうということを考えてみましたので、あまりソフトウェアの専門用語を使わない形で書いてみようと思います。 接触確認アプリが生まれ

簡単なお題で18分弱におさめていて、ところどころ字幕を入れています。モブプログラミングの進め方や雰囲気をつかんでもらうのにお手頃なサイズ感です。 モブプログラミングに興味がある人やチームに見ていただいたり、ワークショップや勉強会での紹介に使いやすいように編集しています。 以下の資料と合わせてご自由にお使い下さい。

Dan Ashby氏による「Continuous Testing in DevOps…」を、本人の了承を頂いてざっくり意訳させていただいたきました。彼のアイデアを知ったのはAgile 2019というカンファレンスでしたが（DanさんはTesting系セッションのオーナーだった）、記事は2016年のもので、今になっても全然色褪せない本質をついた内容です。彼の書いた手書きの図が、さまざまな場所で引用されているのをみても、彼の視点がとても高いレベルにあるのだとおもいます。 Continuous Testing in DevOps… 最近、いくつかのカンファレンスに参加しました。テストやアジャイル開発や開発に関係するイベントです。新しい人達に出会えたり、色んな人の物語を聞けるた点では全体的にとてもよいイベントだったと思いますが、いくつかの講演はなかなか辛いものでした。その理由は、自動化、アジャイル

通常の大喜利では出されたお題から回答を考えるが、逆に「回答」だけを見て「お題」を当てることはできるのか？ 超高難易度の検証に、あの方がチャレンジしてくれました。 こんにちは、ライターの店長です。趣味で大喜利をしています。 このように大喜利は、出された「お題」に対して「回答」を考えるゲームです。 それだけでも結構難しいのですが、 逆に「回答」から「お題」を当てるのは、さらにやりがいがあるのではないでしょうか？ 盛り上がれば新しいゲームになるかもしれません。当てられるかどうか、さっそく検証してみたいと思います。 検証開始 というわけで早速、オモコロライターのみくのしんをzoomで呼んで趣旨を説明してみました。お笑いは好きで、今回かなり自信があるらしいです。 答えを見て大喜利のお題を当てればいいんだよね？ 悪いけど俺、マジで当てちゃうよ？ 自信満々ですね。 当てたらそれで説立証なんだよね、大丈夫

年明けからリモートワークの流れが進み、緊急事態宣言解除を受けて揺り戻しが起こっている頃かなと思います。 なお、本稿に結論はありません。なんとなく思っていることを、なんとなくのまま書いてますのでご注意ください。いつも通りといえばいつも通りなんだけど、いつも以上にそんな感じ。 オンラインツールやリモートワークをオフラインの劣化かのようなのには反発したいんだけど、うまく挙げられなくて悶々としてる。何か見つけていいとこ取りしたい気持ちがずっとあります。 https://twitter.com/irof/status/1266001682011320320 さて、掲題の「劣化」ですが、 リモートでもXXX（オフラインでやっている何か）を再現できる に違和感を持っています。このような言葉は最近出てきたものではなく、数年前から「再現できるからリモートワークできる」みたいな表現で使われている印象があります

長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に

テスターのくせに Janet Gregory さんと Lisa Crispin さんの書籍『Agile Testing』『More Agile Testing』を読まずに今日まできてしまったのですが、この二冊を凝縮（Condensed）した『Agile Testing Condensed』（日本語訳）くらいは目を通しておかないとね！ということで読みはじめました。 leanpub.com この記事は本書に書かれていたある問題を取り出し、それに対してわたしたちのチームが普段やっていることをわたしの目線で紹介したものです。ツイートするには長いのでこちらに書きました。 チームが「サイロ化」する問題 複数のチームがすべて同じプロダクトで作業している大規模な組織でよく見られる問題の1つは、チームが「サイロ化」する傾向があることです。依存関係を解決するために他のチームと話すことを忘れています。（第3章：

","naka5":"<!-- BFF501 PC記事下（中⑤企画）パーツ＝1541 -->","naka6":"<!-- BFF486 PC記事下（中⑥デジ編）パーツ＝8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下（中⑥デジ編）パーツ＝8826 -->","adcreative72":"<!-- BFF920 広告枠）ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag ＰＣ誘導枠５行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">\n <div class=\"

Kristin Jackvonyさんのブログ「Think Like a Tester」に掲載されたポスト『Six Testing Personas to Avoid』を、許可を得て翻訳してみました。 thethinkingtester.blogspot.com 「ダメエンジニアの類型」みたいな記事って、バーナム効果的に「どれも自分に当てはまるかも・・・」となって面白いので、反省のために読んでしまいますね。 テストにおいて避けるべき、6つのペルソナ (翻訳) エンドユーザ向けのソフトウェアを作っている会社で働いていれば、「ユーザペルソナ」について聞いたことがあるでしょう。ユーザペルソナとは、アプリケーションのエンドユーザの一つの側面を表現したものです。 たとえば、自宅を改善するための製品のウェブサイトを作っている会社で働いているとしましょう。この場合、最初の家を購入したてで、自宅のこまごまと

はじめに（実例マッピングを紹介するに至った背景） このブログで何回かお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 leanpub.com この書籍の中で、実例マッピング（Example Mapping）が紹介されています。 このプラクティスは大変素晴らしいものだと感じているのですが、残念ながら日本ではあまり知られていません。*1また、書籍の中では軽く紹介している状態です。 そこで、プラクティスの詳細の説明をするべきだと感じ、実例マッピングの記事の著者であるMattにも許可をもらい、英文を翻訳する形で紹介します。 なお、原文のページはこちらです。 cucumber.io 2020年11月20日追記：実例マッピングの事例および、どのように会話して実例マッピングを作っていくのかについてスライドにしました。 speakerdeck.com

はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。

2019年9月に出版された『Agile Testing Condensed』を日本語に翻訳してLeanpubにて出版しました！ 表紙はこんな感じ。*1 書籍紹介および購入はこちらから。 leanpub.com 現在は電子版のみ提供する形になっています。形式はpdf,epub,mobiの3種類です。 今回の記事では、この本がどんな内容なのか、そしてどんな想いで翻訳・出版に至ったかを書きます。 この本について 出版ページにも書いている紹介文を引用して紹介します。 『Agile Testing Condensed』は、アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています。JanetとLisaは、読者が理解できるように、20年間のアジャイルテストの経験から知識を抽出して表現しました。 テストとQAの専門家がアジャイルチームでどのように貢献するか アジャイルサイクルにテスト活

この度、Developers Summit（デブサミ） 2020で話題賞を受賞しました！ 私を含めた各賞の受賞コメントについては、記事をご覧ください。 codezine.jp t_wadaさん、安田さん、ryuzeeさん、川口さんという、そうそうたるメンバーと一緒に受賞という、ちょっと恐れ多い感じもありますが、大変嬉しいです。 上記の記事にある受賞コメントに書ききれなかった想いを書きます。 公募に当選 今回、私は公募で申し込んだ結果、発表が決まりました。 懇親会の時にそーだいさんから聞いたのですが、それなりの倍率で、選ぶ方もその中から全体のバランスなども考慮していたとお聞きしました。 今回の発表、そして話題賞の受賞は、そもそも公募の中から選ばれなければ実現しなかったことなので、選考委員の方には本当に感謝しかないです。 開催の判断 今回の発表はCOVID-19の影響で、運営の方々としては開催

各賞の受賞者は下記の通り。 ベストスピーカー賞 基準：一定の満席率以上のセッションのうち、来場者満足度1～3位 1位：「質とスピード」和田 卓人氏 [タワーズ・クエスト] 受賞コメント ベストスピーカー賞（1位）と話題賞のダブル受賞、とても光栄です。 ‪この講演は、品質（保守性）と開発スピードがトレードオフの関係にあるという誤解に対して一石を投じ、システム開発の議論を前に進める一助になればと考え準備してまいりました。 質とスピードはトレードオフではありません。このメッセージが会場にお越しくださった皆様に届き、高く評価いただけたことを大変嬉しく思います。‬誠にありがとうございました。 1位：「日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡」安田 忠弘氏 [クリエーションライン] 受賞コメント セッションを聴いていただいた皆様へ私自身の経験と学びと

Latest Tech Jobs 🇯🇵Explore the top developer jobs in Japan for foreigners

本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。 湯本氏のnote「テストマネジメント虎の巻」はこちら これまでの連載では、「ビジネスの成功に貢献するソフトウェアを作るためにはトライアルアンドエラーを行うことが大事であること」「トライアルアンドエラーを実現するためには、開発スピードが大事になること」「これらを実現させるために出てきた代表的な４つの開発スタイルはどのようなものか」を説明してきました。 今回からは、これらの開発スタイルに合わせて行うソフトウェアテストはどうあるべきかを説明していきます。 もくじ テストの変わらないことと変わること オープンソースを活用した開発の際にテストで考慮すべきこと アジャイル開発を活用した開発の際にテストで考慮すべきこと クラウドを活用した開発の際にテストで考慮すべきこ

テストで行うおもなプロセス 今回からは4回にわたって、ソフトウェアテストを進めるにあたって考えることを取り上げていきます。ソフトウェアテスト（以下、テスト）は、ソフトウェアの欠陥を見つけ品質を評価する大事な作業です。まず、テストはどのように進めていくかおさらいしてみます。 テストの開始から終了までのおもな活動について、ソフトウェアテストライフサイクル（Software Test Life Cycle：STLC）と呼ぶテストプロセスでは表1のように定義しています。STLCのプロセスはどれもテストを進めるために必要な活動だと思います。テストを実行することはもちろん、何をどのようにテストするか計画を立てなければテストは進められませんし、テスト結果を分析・評価しなければソフトウェアがリリース可能か判断できないからです。ですがこのプロセスどおりにテストを愚直に進めようとすると、筆者には「⁠“⁠要件定

事業開発部の塩谷 (@kwappa) です。 タイトルがすべてなのですが、社内で「登壇勉強会」が開催されたので、「登壇は最強の生存戦略である」というタイトルで登壇しました。 といってもコロナウイルスの感染拡大対策が強化されたばかりですから、勉強会はオンラインで開催されました。登壇者3名はオフィスの会議室で交互にしゃべり、参加者はみんなHangouts meetを通して聞く、というスタイルです。 登壇者はクラスメソッドから先日のデブサミ2020に登壇した、AWS事業本部の濱田孝治とCX事業本部の藤村新、それにぼくの3名です。三者三様の登壇にかける思いやノウハウがぶつかりあう、大変おもしろいイベントになりました。オンラインでの参加者は2時間弱のあいだ常に100人前後をキープしていたので、飽きずに楽しんでもらえたのではないかと思っています。 ぼくはスライドを作り込む余裕がなかったので、テキスト少

以下のイベントの投影資料です。 https://event.shoeisha.jp/devsumi/20200213/session/2364/ 発表時の諸注意など http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000 お問い合…

このブログでの告知が遅れましたが、2/13,14に行われるDevelopers Summit 2020でテストについての発表をします。 event.shoeisha.jp 内容は、いつもの発表内容に少しだけ最新の内容を付け加えたものとなります。 開発系のイベントでの発表は昨年のJJUG 2019 Spring以来で緊張しますが、頑張ります！ 諸注意 テストコードの書き方は話しません セッションタイトル「テストエンジニアが教える　テストコードを書き始める前に考えるべきテスト」で表されているように、私が話す内容はテストコードよりも前の話です。 テストコードの書き方の話はしませんので、そのような話を聞きたいと思っていた人は他のセッションに移ることをお勧めします。 ペアワークがあります 私の発表では、ただ聴講していただくだけではなく、隣の人とのペアワークがあります。 基本的にテストのことを何も知ら