テストフェーズがなくなるのが未来だろうっていう話
「じゃ、どういうプラクティスがあればいいのだろう？」と考えはじめたのが、メルカリに入る少し前の頃。そこで今ためしにAutomation & QA チーム（通称：AQA）でがんばっているのが //speakerdeck.com/assets/embed.js ↑の部署紹介資料にもある「Continuous E2E Testing」です。現在は夜間ビルド＆手動でいつでも実行。そして、最終目標はコミットごとの実行（でもすごくそれは難しい）。 だって、アジャイル開発、DevOps時代だともう、ずっとテストするしか「はやく」ならないんですもの。 CodeZineさんの「アジャイル開発におけるテストとは？ その未来とは何か？【Agile 2018】」でも、AQA POP TALKの「探索テスターの未来？ テスト戦略モデル「INFORMATION」とは何か？ via ebayのセッションより」でも登場す
ふりかえりのファシリテーションが劇的に楽になる「MeetingSift」がすごい
MeetingSiftの操作は簡単。アジェンダに話したいことを書いていくだけで、それぞれのアジェンダには、普通のスライドだけでなく、ブレインストーミング、投票、ランキング、評価、Q&Aなどなど、さまざまなアクティビティを追加可能です。 特によかったのが「ブレインストーミング」のアクティビティ。おもいついたキーワードをスマホから記入してもらい、キーワードクラウドになって画面に表示されます。 たとえば、ふりかえりでよくやっていた「みんな付箋におもったことかいてねー」とかがオンラインでできますね。複数回でてきたキーワードは大きくなっていくので、大きい言葉を選んでディスカッションするとかもできそう。 MeetingSiftのプランをみると、25人までなら無料で使えるので、小さなチームであれば十分だとおもいます。大人数になってくるとTEAMやPROアカウントを使えばよさそうです。 リンク： Meet
テストを育てるためにテスト管理ツール「TestRail」を使ってみた
テストケースの管理は、テスト自動化云々の前になんとかしておきたいところ。テストケースはExcel管理することが経験上多いですが、世の中にはもっと便利なものがあるだろうと思い、ブラウザベースでテスト管理できる「TestRail」を試してみました。さてさて、Excelを超えるのでしょうか？ 超えてみろ！ なぜテスト管理が重要なのか テストケースの管理について、以下のような課題を多く経験しました。 テストケースの追加や更新、その後の整理が難しい。行のコピペミスやマージ漏れ、同時更新でおかしくなったりファイルが壊れたり。マスタとなるテストケースをバージョン管理しながら育てていきたい。 トラッキング情報を書き込みにくい。Excelのセルには表示限界がある。「5/31 藤原 XXXXX追加」とか書くのがとても面倒くさい。 過去のケースを検索しにくい。ファイル・フォルダに行って、過去の日付のケースを開い
アジャイルなレビューをサポートするツールを5つ
Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました（資料はこちら）。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review（CCBR）という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと（Changesetベース）のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie
直感的に受け入れテスト仕様書を記述できるConcordionを試してみた
Concordionという、受け入れテスト自動化向けフレームワークを知ったので、ちょっと動かしてみた。Screenshotsを見るとイメージしやすいかもしれないが、ユーザーストーリの書式や、テスト仕様書の書式で、受け入れテストを記述できるらしい。 インストールしてみる Tutorialとしてサンプルコードが公開されている（Instrationを参考のこと）ので、それを元に動かしてみる。今回使ったバージョンは、1.4.2でJavaのfixtureを使った。Ruby、.NET、Scala、Pythonのfixtureもあるらしい。ダウンロードしたファイルをEclipseにImportするとこんな感じ。 Greeter.java・・・テスト対象のクラス specsフォルダ・・・受け入れテストのソースフォルダ。JUnitだと「test」とかだけど、Concordionでは「specs」を使う co
アジャイル開発導入時に知っておきたい成果と効果測定のポイントとは？
cambiodefractal via Frickr アジャイルムーブメントの影響もあり、アジャイル開発を最近はじめた。またははじめようとしている方も多いと思います。私は2003年に社会人になり、第一次アジャイルブーム？か何かでXPを知り、少しだけ学んだ世代なのですが、去年の1月からアジャイル開発を勉強・実践するようになりました。 そんな中、アジャイルコーチを仕事としている方を間近で見たり、新人研修にアジャイル開発の手法を取り入れたり、実際に自分のチームで実践したりする経験を得ることができました。今年は、まったく自分に関係ないチームのプロジェクトリーダー/マネージャをしながら、アジャイルコーチのような役割を果たしているところなのですが、そこでのコーチング時にふと疑問が浮かびました。 「自分の成果はなんなのだろう？」 その疑問について、Twitterでいろいろと教えてくださった方からのアドバ
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
Redmineプラグイン開発 – 史上最高のチームプラグインリリース
DBにPostgreSQLを使っていると、いくつかエラーが起きましたので、一部ソースを変更してエラーが起きないようにしました。 変更したのは、以下の3ファイルです。 lib/common_logic.rb lib/overwork_ranking_logic.rb lib/passed_hours_logic.rb 以下、ずらずらと長くなってしまいましたが、差分です。 *** ./lib/common_logic.rb.org 2009-05-23 17:31:18.000000000 +0900 — ./lib/common_logic.rb 2009-10-06 14:01:08.000000000 +0900 *************** *** 3,14 **** class CommonLogic def self.get_members(project_id) return
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
