Scrumが難しいのは幻想-情熱の再定義- を講演してきました。 #RSGT2018 - うさぎ組
私が所属しているチームは2017年にいろんなプラクティスを実践してきました。その内容をRegional Scrum Gathering Tokyo 2018で発表しました。 2018.scrumgatheringtokyo.org confengine.com 発表内容の概要 私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。 このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。 チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、 なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。
RE:統計的品質管理の功罪 - うさぎ組
概要 SNSで『統計的品質管理の功罪』というスライドについての意見を多数みかけたので、僕も読んでみたので感想を書きます。 ゆえに発表場所では多くのコンテキストが語られているかもしれませんが、スライドからはこう読めるよっていう感じです。 僕の感想は一言でいえば「タイトルは違うほうがいいし、SQCの勉強してないですよね？よく言えますね。」って感じです。 お酒飲みながらのLTだったらありかもーくらい。 もしSQCに村を焼き払われたという事情があるのであれば、SQCを徹底的につぶすくらいの非難なり、手法なりもってくるほうがよいのではないでしょうか。 つまり、マサカリ投げるなら徹底的に投げろ。 発端や背景 SNSで下記のスライドに対する言及が多数ありました。 統計的品質管理の功罪 from 工 久納 "辛いよねー"と共感するか、"コンテキスト広く言いすぎじゃないか？"と批判するかの2つが多かったよう
リスクベースドなテスト戦略を始める最初の一歩 #swtest_jp - うさぎ組
概要 テストの戦略を考えるのは大変（手抜きしている事が多い）ですし、なんとかしたいけど、どうしたらいいかわからないという時に取れそうな手段について考えてみました。 ちなみに、テスト戦略を立て始めるのは早ければ早いほどいいです。つまり、プロジェクトスタート時から考え始めるくらいでもいい。 リスクベースドなテスト戦略 リスクベースドなテスト戦略とは、ざっくりと言うと、いろんなテストのアプローチを考えた上で、リスクの重み付けをして、優先度の高いものからうまく回避するようにテストを組み立てる。という感じです。 これにおいて僕の感覚で大雑把に「最低限テスト戦略で組み込みたいこと」は次の4つです。 出来る人をチームに入れる。 データの明示的、暗黙的変換部分に着目してテストする。 エンドユーザーが苦情を言うシーンをテストする。 システム運用が面倒になるシーンをテストする。 逆に言うと、「なんでたかだかこ
OOじゃないDDDについて - うさぎ組
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。（言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを
テストの抜け漏れを定量化する実験 - うさぎ組
最近テストの抜け漏れをどうやってなくすか実験しています。これ、もっといい感じに取り組めたら、論文とかにしたいんですけど、まだいい塩梅にならないので、まぁブログでもいいかなぁとか思ってやっています。 やっていること ざっくりと言えば 仕様書とテスト仕様書(テストコード)を形態要素解析して名詞の重複有無や頻出の傾向を比較する。 こうすると、「仕様書にある単語がテスト仕様書に出てきていないけど、テストないの？」とか「仕様書でちょっとしか出てきていない単語が、テスト仕様書にいっぱい出てきているけどそのテスト無駄じゃない？」とか。言えるのかな？って試している感じです。 ところでテストケースは不足しているものが多い で、まぁ概ね使えないんですけど、もうちょっと工夫すればいい感じになりそうだなぁと思っています。これによって変わったのは、「やらないテストも実装する」ということですね。どんな理由でもいいので
テスト戦略のたった3つのチェックリスト - うさぎ組
本稿はSoftware Testing ManiaX vol.9に寄稿したものになります。ご興味ある方はJaSST、WACATE、コミックマーケットに参加して買ってみてください。 さーくるWACATE ちなみにkyon_mmの心情的にはだいぶ押さえて書いています。本音を言えば「なんですかそのテスト計画？昼寝しながらでももっといいの書けますよ」「訓練をしないで戦地に向かうことに恐怖を覚えないなら、いますぐこのマサカリを首にかけてやる」って気持ちを必死におさえて書きました。偉いです。自分をほめたいです。 そういう雰囲気で書いているのであまり整理されていない内容ですが、皆様の何かのご参考になればと思います。突っ込み歓迎ですが、こういった文章ですのでface2faceだとコンテキスト共有しやすいと思われます！ はじめに ソフトウェアを開発していくなかで、品質を考えるということは非常に重要なことです
技術書を買ったけどなかなか読了できない理由 - うさぎ組
読みたいと思った技術書を買ったけれど、半年たっても読了できていないとか、最初の10ページだけ読んであとは読んでいない。読み終わったけど最初の方は忘れていて書籍の内容が自分の中で体系化できていない。そしてそれを後悔しているという人がいると度々聞きます。 自分もそういうことがあるのでなんでそうなってしまうのか振り返ってみました。みんなどうせこうだろ？とかではなくって、僕はこうだったわーっていう感じ。 基本的には次の3つかなぁと思います。 先送りにしてしまう 前回読んでから今回読むまでの期間が長過ぎる 書いてあることを復唱するだけになっている つまり 先送りにしない 出来るだけ短い期間で読み切る 要約と応用事例を考える を徹底すればだいたい読めます。これを出来ないときは買わない方がいい。と僕は割り切って書籍を買ったり借りたりするようになりました。（課される場合は別です。） 先送りにしてしまう 皆
Spockのテストレポートが想像以上に凄い件について - うさぎ組
タイトルはホッテントリメーカーを使いました。http://pha22.net/hotentry/tb/r?word=Spock%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88&phrase=9 全国49万のSpockユーザのみなさま。SpockのMLを見ていると思うので、ご存知かもしれませんがSpockのテストレポートをご存知でない方もいると思うので紹介します。 Spockのテスト結果はだいたいみんなGradleで見ている Spockは言わずと知れたUnitTestingFramework界最強といわれるテスティングフレームワークですが、これのテストレポートは通常はJUnitのテストレポートXMLであり、多くのSpockユーザはGradleでビルドをしてGradleが生成するテストレポートを見て
テストと開発の違いをわかりやすく教えてやんよ！ - うさぎ組
タイトルは釣りです。むしろ、教えてほしいです。とは言いつつも自分で比喩が思い浮かんだので書いてみました。 テストはQAでもいいんだけど、まぁロールとか立場とか視座とかが違うとはこういうことであるというのをなんかいい比喩を考えついたので。 このエントリでは「プログラミングする」と「テストする」はどう違うのか？ということを説明します。なので、プログラマーが「うーん。テストしているんだけど、あんまり意味がないかもー」って感じるときはこの例に出てくるような「テストする」になっていないかもしれないし、ただただ品質が高いのかもしれません。 ソフトウェア開発を塗り絵として考える ソフトウェア開発はある形の塗り絵として考えてみます。複雑なものはちょっと考えにくいので、まずは大きな長方形を赤色に塗ることとしましょう。 まず開発する（塗る） で、例えばプログラミングするときに左から右に筆で赤く塗ったとしましょ
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
テストをするモチベーション - うさぎ組
注意 本稿は@kyon_mmの頭がおかしいのか、テストエンジニアの頭がおかしいのかは不明です。経験談です。 モチベーション テストをしているときのモチベーションはいくつかある。それによってやっていることもずいぶんと違う。 基本的に僕がテストをしているときは「対象をぶっこわす」か「対象を楽しもうとする」か「対象を知ろうとする」くらいの3つです。どれかに偏っているテスト戦略は偏った製品を出したいということに他ならないので、POに確認する必要があるか、自分のテスト戦略がダメな場合がおおいかな。 ぶっこわす 基本的にその対象をクラッシュさせることに集中します。どうやったらこのソフトウェアは例外をはいて終了するのか。どうやったら正常起動しなくなるのか。どうやったら正常に終了しないのか。どうやったらレスポンスがかえってこなくなるのか。 で、こういうのは意外に時間がかかったりします。ということで普段から
コードカバレッジで見落とされがちだと思う事 - うさぎ組
はじめに みなさんがいろいろ言いたい事はあるだろうから、むしろみなさんの意見を聞きたい。はてなブックマークのコメントとかではなく、直接このブログのコメントか引用した自身のブログで書いてくれれば幸いだ。 コードカバレッジ 日本語で20冊くらい書籍がでているようなプログラミング言語で、しかもテスティングフレームワークについても紹介されているような言語であれば、最近ではだいたいは「テストコードの実行によって実行されたプロダクトコードのパスカバレッジを計測するツール」であるところのコードカバレッジツールはあるでしょう。 JavaであればJaCoCoというツールがありますし、最近だとCoverallsというサービスもありますね。 どれくらいだといいのか？ コードカバレッジがバグ検出と強い因果関係にはなさそうであるというのが、自分の周りで聞く事が多くなりました。また、先日そういった論文も発表されたよう
仕様書にないものをどうやって思いつくか？ #CafeTesting - うさぎ組
先日、 Cafe.Testing で ソフトウェアテスト実践ワークブック の演習2をやりました。そこで話題になったのですが、「どうやって仕様書にないものを思いつくか？」ということです。他にもたくさんあって不十分な部分はあるのですが、そこで話した内容をメモがてら書いておきます。また、こういったことに興味があったり聞いたり話したりしたい人はきてもらえるとうれしいです！ Cafe.Testing - connpass ソフトウェアテスト実践ワークブック 作者: レックス・ブラック,成田光彰出版社/メーカー: 日経BP社発売日: 2007/01/18メディア: 大型本 クリック: 1回この商品を含むブログ (4件) を見る 発端 この書籍を持っている人はわかると思うのですが、演習2の回答例にはミドルウェアやハードウェアが起因でソフトウェアが動かなくなるようなテストケースはなかったりしました。 あと
テスト仕様書がExcelで何が悪い - うさぎ組
僕もExcelでテスト仕様書を書くのは嫌なときがあります。全員OrgMode使えば幸せなのに！！！って何度思い、CucumberのフィーチャファイルはOrgModeから書けないという点をのぞいてすばらしいとか思っています。 でも、Excelのテスト仕様書をすごく嫌う人って、たいていはその人が使っているフォーマットがすごく気に食わないだけな気がしています。 なんでそう思うかって言うと、「さぁテストケースを書いて僕に見せてよ」とか言うと、8割くらいのひとはスプレッドシートをつかっています。（僕の勉強会観測範囲）その人たちがExcelのテストドキュメントをいやがっているかどうかは未だにわかっていませんが、結局使いやすいから使っているんじゃないでしょうか。 なので、「こういったフォーマットがいやだー」っていうのはわかるけど、でもスプレッドシート使いやすいんでしょ？とか、じゃあ、きれいなテストドキュ
ソフトウェア開発では出来るだけ言葉遣いに気をつけよう。さもなくばマサカリを受けろ。 - うさぎ組
はじめに 言いたい事はわかるんですけど、ふわっと言葉を使っていると間違っていることもあります。 ということで、ほとんど自戒なのですが、今や私も気になる部分は多々あるので、私が思う気を付けたらいいよっていう言葉のリストを以下にあげます。気をつけましょう。 なお、本稿では実際の定義は皆様に調べていただく方向ですので、書いておきません。これ調べたらいいよ的なガイドワードくらいです。 証明する 例えば「このテストによって証明されている」これやばいですね。 テスト界隈からも証明プログラミング界隈からも数学界隈からも目を付けられます。 少なくともそれはなごやに囲まれる事を意味します。 基礎 書籍や記事やイベントで「基礎」とみかけますが、結構な割合で入門と勘違いしているケースがあります。それはよくないです。基礎 と 入門は違います。入門向けな予定なのに、基礎と書いたがために、こわい人たちが大挙した勉強会
テストをテストする方法 #1 - うさぎ組
本投稿はずいぶんと前に書いたものですが、せっかくなので公開します。 要求元はたしか@ebc_2in2crcさんだった。 ソフトウェア開発においてテスト自体が正しいかどうかを確認することは非常に困難です。どんなときにテストの正しさを気にするかというと、自分には3つありました。 テストをレビューするとき テストのリファクタリング 知らないプロダクトを触るとき それぞれでどのような施策を打てるかやってみたことを書きます。 テストをレビューするとき 具体的な値を使っているテストは同値内のいずれかの値に変更してみる テストをレビューするときにテストが正しいかどうかを簡単にまず試す方法としては、入力値を同値内のいずれかの値に変更することです。QuickCheckやランダム値生成などを使っていない貧困なテストでは同値分割ができていない事によるテストもしくはプロダクトのバグが発見できていない場合があります
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
