TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 - プログラマの思索
TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」 - プログラマの思索
ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。 CC Attribution ライセンスとします。 上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。 一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。 テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合～受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。 その問題の本質は、二つある。 一つは、受入テストの自動化は難しいこと。 もう一つは、手動の受入テストの生産性が悪いこと。 TestLinkの導入によって、手動の受入テストを効率化できると確信している。 だが最終的な目標である受入テストの自動化は、Te
SKIP - Redmine
Redmine本サイトは、オープンソースの社内SNSであるSKIPの開発用Redmineです。 SKIPについては、以下をご覧ください。 http://www.openskip.org/ 最新ニュース SKIP: SKIP v1.1 および v1.0.3 をリリースしました maedanaが90日前に追加しました SKIP: SKIP ver1.1 RC2 をリリースします matsumuraが104日前に追加しました SKIP: SKIP ver1.1RC1とver1.0.2をリリース matsumuraが119日前に追加しました SKIP: SKIP正式公開版(ver.1.0.0)をリリースしました。 RCではなく、正式公開版になります。 ver.1.0では、技術者でない方でも運用できるように改善した正式版になります。 fukudaが245日前に追加しました SKIP:
プログラマの思索: TestlinkがExcelのテスト仕様書よりも素晴らしい点
TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて
チケット駆動開発でXPの計画ゲームを実施する - プログラマの思索
昔、XPlannerというXPのアイデアを実現したWebアプリがあった。 そのソフトは、XPのタスクカード単位で進捗管理できるのがウリだった。 でも、正直使い勝手は良くなかった。 そして、最近、Redmineを触って初めて、XPを実現できそうなプロジェクト管理ツールだと直感した。 Redmineによるチケット駆動開発のアイデアをまとめてみる。 【1】Redmineの特徴は、プロジェクトの進捗の可視化 Redmineの最大の特徴は、ガントチャート。 チケットに作業内容と開始日、終了日を入れると、すぐにガントチャートが出来上がる。 これを初めて見た時は感動した。 プロジェクトリーダーは、ガントチャートを作って保守するために、殆どの時間を費やしている。 WBSさえ作って入力すれば、ガントチャートを自動生成してくれるのだ！ 他に、カレンダーもある。 開発時だけでなく、運用保守時にリリースする日やD
大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
要件定義はトリアージが鍵を握る - プログラマの思索
「成功する要求仕様 失敗する要求仕様」ではトリアージの概念が説明されている。 つまり、システムを実現する要求は、納期やコスト、リソースの観点から優先順位付けして、高い優先順位から要求をまとめていくというもの。 ヨードンの「デスマーチ」でも、デスマーチプロジェクトから脱出する唯一の方法はトリアージを行うことだ、と書かれていた。 そもそもトリアージとは、救急医療の用語。 災害医療等において、有限のリソース(医師や医薬品など)を最大限に活用して、より多くの傷病者を治療するために、治療の優先順位を決定することを意味する。 Wikipediaによると、下記4個の色のついた診断書を傷病者の右手首に取り付ける。 ここでは、治療の優先順位は、赤→黄→緑→黒 の順番になる。 【黒 (Black Tag)】 死亡、もしくは救命に現況以上の救命資機材・人員を必要とし救命不可能なもの。 【赤 (Red Tag)
プログラマの思索: Webベースのプロジェクト管理
最近、プロジェクト管理の手法が急激に変化しつつあるのを感じる。 以前は、ExcelやMS Projectで進捗管理や要件管理をプロジェクトリーダーが取り仕切り、メンバーに節目ごとに展開していた。 そこでよく出る症状として、プロジェクト全体の進捗や各メンバーの役割がメンバーに見えにくいことがあった。 だから、「見える化」と称して、XPやPFの手法が使われた。 最近は、Trac(Python)やRedmine(Ruby on Rails)のようにWikiベースのFreeのプロジェクト管理ツールを導入するケースが多くなった。 その特徴や感想について書いてみる。 【1】TracやRedmineの特徴は下記があるように思う。 １・Wikiに、技術上のアイデア、開発環境の構築方法、リリース作業手順、日報などを書き込み、皆で情報共有する ２・カレンダーにプロジェクトのマイルストーン、各自の作業納期を書き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
