はじめに この記事は ソフトウェアテスト Advent Calendar 2019 の2日目の記事（代打）です。 目次 はじめに 目次 Agile Testing Daysとは何か？ Agile Testing Daysで印象に残ったセッションの紹介スライド テスト戦略ハンドブック おわりに Agile Testing Daysとは何か？ 11/3〜8にAgile Testing Daysが行われました。 agiletestingdays.com Agile Testing Daysとは、ドイツのポツダムで毎年11月に行われているAgileとテストがメインのカンファレンスです。 私は今年のAgile Testing Days2019に参加してきました。 Agile Testing Daysで印象に残ったセッションの紹介スライド 会期中に行われるセッションの数は100を超えます。当然、すべて

はじめに この記事は ソフトウェアテスト Advent Calendar 2019 の16日目の記事です。 目次 はじめに 目次 WACATE2019冬 私の担当セッション なぜ私が「ソフトウェアテストの7原則」のセッションを行ったのか きっかけ1：私がWACATE参加し始めた頃の思い出から きっかけ2：ソフトウェアテストの7原則のことを書いたら、意外とニーズがありそうだと思えたから セッション資料 おわりに WACATE2019冬 12/14,15にWACATE2019冬が行われました。 wacate.jp WACATEとは、1泊2日で行うテストに関するワークショップです。 私はこのWACATEの実行委員をしています。 今回はほぼ満員の参加者とともに、走り抜けることができました。 私の担当セッション 今回、私は「業務でも活用できるソフトウェアテストの7原則」と「Agile Testing

最近、もやもやが多く書きました。 会社や個人や立場(役職)によって意見が違うと思うのですが、 ひとりで考えても答えがでないため、 コメントもらえると嬉しいです。 みなさん、どうしているのですか？ 私が、所属していた、所属している、これから所属する組織をディスる意図はありません。 たんに、不安でもやもやという話です。 もやもやがおさまりません。だからこそ吐き出します。 追記： いろんなひとがコメントをくれました。ありがとうございます！ ブコメへのリンクを載せておきます。 b.hatena.ne.jp 前提 私は、会社の費用でカンファレンスや研修に参加したことがほとんどありません。 （昔いた会社で過去一度だけある。当時は行きたかったわけでなく、えらい人に「xxさんに行ってもらうことなったから」と言われた経緯） 「認定スクラムマスター研修（CSM）」も自費で受けました。 ふりかえると2019年は

はじめに あなたのふりかえりを拡張するふりかえりチートシートを公開いたします！ この記事では、技術書典7以降配布している「ふりかえりチートシート」の説明を行います。 ふりかえりチートシートは、ふりかえりの手法84個とその特徴を網羅した一覧表です。下記画像はイメージです。 pdfはBoothで無料DLできます。 DLはコチラ => （DL版）ふりかえりチートシート ふりかえりチートシートとは ふりかえりの様々なシチュエーション（ひとり、チーム、プロジェクト、組織）で利用可能なふりかえりの手法をまとめたチートシートです。 ふりかえりの各手法を「ふりかえりの5つの流れ」と「ふりかえりの8つの型」に沿って分類しています。 B5の2ページ分のpdfファイルで、両面印刷したものをイベント等で配っています。 DLしていただいたものは、ご自由に印刷＆ご利用ください。 ふりかえりチートシートの想定利用対象者

はじめに この記事は ソフトウェアテストの小ネタ Advent Calendar 2019 の3日目の記事です。 もはや、「小ネタ」という文量を遥かに超えてしまっている気もしますが、「機能テスト」という1つの単語に対しての小ネタということで…。*1 目次 はじめに 目次 この記事のきっかけ こんな記事がありました テストレベル テストタイプ 素朴な質問 「機能テスト」がテストレベルに入っていることによる弊害 理由1. 複数人の間で認識齟齬が発生してしまうため 理由2. 不足や重複が確認しづらいため 理由3. テストできるはずの粒度・タイミングでのテストができるように見えなくなってしまうため さらに発展した話 テストコンテナ テスト計画 テスコンチュートリアル（OPENクラス）にて… おわりに QA歴の浅い人の感想(Slackのスクショ) 開発者の感想 この記事のきっかけ こんな記事がありま

この記事は？ qiita.com ソフトウェアテスト Advent Calendar 2019の1日目の記事です。 この記事では私が最近体験した「とある不具合報告から調査（テスト）をしてみた話」です。 自分ならどんなテストするかなぁ〜？どこを狙うかなぁ〜と思いながら、読んでもらえると嬉しいです。 「『パスワード変更ページでパスワードを変更したら、他のブラウザでそのパスワードでログインできない』ということがある」 先日こんな報告がありました。 「『パスワード変更ページでパスワードを変更したら、他のブラウザでそのパスワードでログインできない』ということがある」 ■ パスワード変更ページとは？ パスワード変更を行うためのページです。 このシステムでは、システムログインページにある「パスワードをお忘れの方はこちら」の「こちら」部分をクリックするとパスワード変更メール送信ページに遷移します。 このペ

前回の記事（「プロジェクト＆プログラム・アナリシス研究部会」（12月2日）開催のお知らせ）でも少しふれたが、なぜPMBOK Guide(R)には「設計論」がないのか、不思議に思われている方も多いと思う。米PMI (Project Management Institute)が'90年代に作成し、現在は改定第６版になっているPM界の標準ガイドブックは、10個のマネジメント領域を定義している（最初は9個だったが、途中からStakeholder Engagementが加わって、10個になった）。その10のエリアには、「調達」や「品質」があるのに、肝心の設計マネジメントがない。 プロジェクトにおいて、もしも設計がまずかったら、実装段階でどんなに頑張っても、良いプロダクトは生まれない。つまりプロジェクトの価値は上がらない訳だ。プロジェクト・マネージャーの任務は、プロジェクトの価値を最大化することのはず

地方こそサーバーレス、その意義に迫るサーバーレスPHP / Serverless PHP: The Rural Areas, and Why Serverless PHP Matters

少し前になるが、JaSST Review19 に参加した。 わたしが拝聴したのは3番目のふかやみわさんのお話のみだったが、非常に感銘を受けた。 speakerdeck.com 発表を聞きながら考えていたことをそのまま記しているので、微妙にズレたこといってるかも的な感想メモ 他人がどのような思考に基づいて行動しているかは普段あまりわからない 一つ一つの判断にも前提となる考え方や視野の広げ方/狭め方がある それは生きていくなかで自然と身につくと思うが... とはいえ自然と身につくのをまっていると時間がかかりすぎる 思考の伝承 メソッド的なものだけ伝えても意味がない その結論にいたった思考の流れを共有する 常になぜそうしたかを解説しながらいっしょに進めていく テストだってペア作業が重要 スライドおよび登壇者の話から垣間見えること 1つのチームである感 自社製品のマニア/オタクであること 画面描画

【JaSST Review'19 レポート】【セッション3】『違和感のつかまえかた』 ～組み込みシステムの開発者（テスター）としてやっていること～ 公演概要スピーカー：深谷 美和さん（toRuby（とちぎRubyの勉強会）） セッションの内容： みなさんは「なんとなくだるい」「寒気がする」「熱っぽい」というような違和感を感じた時、どうしますか？症状がひどくならないよう行動を変える方が多いのではないでしょうか。 開発の現場で感じる違和感も同じです。違和感は『注目すべきシグナル』です。より良い製品を作るため、みなさんは行動を起こさなくてはなりません。 本セッションでは、私がいつ、どこで、何を見て違和感を感じているのかを紹介します。また違和感をつかまえるために大事なこと、違和感をつかまえやすくするコツや工夫についてもお伝えする予定です。 今よりももっと違和感に敏感になりたい、違和感をもっと製品開

公演概要スピーカー：岡野 麻子さん（三菱スペース・ソフトウエア） セッションの内容： ソフトウェア開発の中で、レビューは多くのプロジェクトで実施されます。ツールを利用される方もいらっしゃるのではないでしょうか。「なんでこのツールなんだっけ？」のような疑問を持ちながら利用していることはありませんか？ その疑問・違和感は、なぜおきているのでしょう？ 利用したいシーン・動機（問題・課題）に合致した目的・用途ごとにレビューツールの強み・弱点をしり、選択・利用する必要があります。 私が所属するSEPGでは、ツール利用の推進も行っております。 その際にどのような点を考慮しているか、現場ではどのような課題が多いのか、についてお話させていただきます。 レビューだけではなく、他のプロセスでも共通する考えでもありますが、レビュープロセスに照らし合わせて、一緒に考えていきましょう！ 最初に持っていた疑問 そもそ

【JaSST Review'19 レポート】【セッション1】文書校正におけるReviewと活用するための分類およびルール化 公演概要スピーカー：津田 和彦さん（筑波大学大学院） セッションの内容： ソフトウェアは多種多様であるため，各工程の成果物は組織やプロジェクトによって様々に表現されている．また，レビューするソフトウェア関係者の背景知識やスキルもばらばらなため、指摘事項も一定ではない．そのため，ソフトウェアレビューに関するノウハウには規則性が乏しく，ルール化が困難であり，多くは個人の経験と勘という暗黙知として蓄積されている． そこで本講演では，規則性に乏しくルール化が困難な人間の文章作成における"間違い"をルール化することで，文書校正支援システムを実現したプロセスを紹介する．このプロセスで実現した仕組みは，Microsoft Wordなどの中でスペルチェックシステムのベースとなっている

こんにちは、とのの（@tonono2587）です。 引き続き2019/11/01に参加したJaSST Review'19のレポです。 パネルディスカッション：レビュー時の思考などを深掘りする 16:36 各セッションの共通点・相違点・印象 ツールのせいにできるから、ツールはぜひつかいましょう！ セッション1（津田先生のお話）について まずは80点、というのは共通しているお話だった 100件とかで規則性を話すひととはいったい。。（それほど壮大なデータ分析） セッション2（あさこさんのお話）について 意味の取り違えで起こっている ならちゃんとやればいい 文書校正がレビュー分野で役に立ちそうに感じた 書き方を整備すると読み方も楽になる 主体 （なんだろうこのメモ…） セッション3（みわさん）について 感じたことを、次はロジカルに考えられるかどうか 【質問】初見だと違和感をつかまえられないのだろう

こんにちは、とのの（@tonono2587）です。 『違和感のつかまえかた』～組み込みシステムの開発者（テスター）としてやっていること～ 発表スライドを！全！公開されているのでツイートからどうぞ！ #JaSSTReview 登壇の機会をいただきありがとうございました。当日使用したスライドはこちらになります。話した内容は字幕（miwaメソッド）にほぼほぼ書いてあります。書き下ろしエッセイも付いてます！ 何か1つでも参考になるものがありましたらうれしいです。https://t.co/syNboYjCcG— miwa (@miwa719) November 2, 2019 スライドにマーカーひけて、メモもつけられることに気がついたのでいままでとメモりかた変えてみました メモ テスターと開発者のロールの違い：テスターはプログラムを書かない分の工数を集中できるので、深くみることができる そんなに簡単

JaSST Review'19でmiwaさんの『違和感のつかまえかた』という講演をお聞きしたメモ。 最近、自分のやっていることは「違和感をみる」ことではないか？*1という仮説があり、参考にできないかと思いながらお聞きしました。 miwaさんはとてもやわらかくお話する方で印象的でした。 ふだん、なにげなくやっていることの言語化はむずかしいと思いますが、 それを聞けるとても貴重な機会でした。ありがとうございます。 資料 「風邪を引いたかも？」と思った時にどうする？ レビューはいつするのか？ うちのチームは、レビューしてない 毎日そこらじゅうでディスカッションしている これがレビューかもしれない 最良の開発プラクティスを最大限適用する ↓ レビューが良いものなら、常にレビューする これだ！！ 自分達の製品のおかしさ おかしさ＝違和感＝注意すべきシグナル 自分たちの製品。自分が風邪をひく話。誰かが

こんにちは、とのの（@tonono2587）です。 11/1(金)、JaSST Review'19 に参加してきたのでメモをまとめます。 今回のテーマ：JaSST Review'19 に参加しました www.jasst.jp タイムテーブルと開催概要を見て、興味があったので参加させていただきました。 「レビューで指摘するときの思考」、「ルール化」といったテーマやキーワードが特に気になっていました。 いまいる組織ではレビューが明確なプロセスとしてとられているわけではないし、 レビューツールを使っているわけではありませんでした。 考え方や事例を学ぶことは、レビューやレビューツールに限らず自分の困りごとのヒントになりそうだと感じたこと、 個人的には仕事として仕様書のレビューをしていると（わりと勝手に）思っていたこともあり、 そのあたりに活かせそう！と思い申し込みをしました。 オープニングセッショ

はじめに 2019年11月1日(金)にソフトウェアのレビューに関するシンポジウムJaSST Review'19に参加しました。今回は、そのレポートを自分なりの解釈でまとめました。 (まずはじめに) JaSST Reviewとは？ ソフトウェアレビューシンポジウム ソフトウェアレビューシンポジウム ASTERとJaSST Review'19 実行委員会が主催 ソフトウェアレビューに特化したカンファレンスは国内でも少なく、貴重！ (まずはじめに) JaSST Revieｗ’19のポイント？　「レビューで指摘するときの思考」について ポイント「レビューで指摘するときの思考」 どのようなバグを狙って見つけにいっているのか 制作物のどんなところ、レビューイのどんなことを気にして指摘しているのか ＋ 効果的にツール導入をするためのプロセスについて 講演セッション 津田 和彦 氏（筑波大学大学院） 「文

This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their core components. It then provides a table comparing 8 popular open source messaging platforms: Apache Kafka, ActiveMQ, RabbitMQ, NATS, NSQ, Redis, ZeroMQ, and Nanomsg. The document discusses using Apache Kafka for streaming and integration with Google Pub/Sub, Dataflow, and BigQuery

著者／訳者：David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士出版社：オライリージャパン発売日：2019-09-18単行本（ソフトカバー）：300ページISBN-13：9784873118864ASIN：4873118867 本書は、David Scott Bernstein氏の『Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software』の全訳です。 著者のDavidはMicrosoftやIBMを含むさまざまな企業での開発経験をバックグラウンドに持つ、特にアジャイル開発における開発者向けの教育に情熱を注いでいる独立のトレーナー/コンサルタントです。 日本にも、2019年のDevOpsDays Tokyoでの基調講演やScrum Allianc