チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン

チケット駆動開発の適用範囲について考えたことをメモ。

【元ネタ】
チケット駆動開発の適用範囲: プログラマの思索

Twitter / @akipii: チケット駆動開発にはいくつかのパターンがある。タスクカードのように扱うタスク駆動が一番やりやすい。システム運用保守やコールセンターはインシデント駆動。システム提案や要件定義なら課題駆動。

Twitter / @akipii: チケット駆動開発では僕は課題駆動が一番難しいかもと最近思う。SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探す。設計書は課題の回答をパッチのように更新して出来上がる。ソースと同じだ

Twitter / @akipii: チケット駆動開発はバグ管理からアジャイル開発へ発展した手法だ。チケット駆動開発をうまく運用できてないチームはバグ管理の基本から見直した方がいい。BTSの一つ一つの機能には今までの世界中の開発者の経験と知恵が込められているのを感じ取って欲しい。

Twitter / @akipii: 影舞、Bugzilla、Mantis、Trac、Redmineに至る歴史を辿れば先人の知恵が分かってくる。BTSの一つ一つの機能には過去の開発者がバグ解決に苦労した形跡がうかがえる。WF型開発でもAgile開発でもSW開発の基本はバグ管理だ。バグ管理を見ればチームのレベルが分かる

Twitter / @akipii: WF型開発とAgile開発ではバグ管理の入り方が違う。WF型開発は信頼性を高めてMTBF(バグが出ない時間)を長くする手法を取る。Agile開発は保守性を高めてMTTR(バグ修正時間)を短くする手法を取る。システムの稼働率を高めるためにAgileとWFは考え方が全く違うのが面白い

Twitter / @akipii: @cointoss1973 Redmineの使い方を他の人はどのように説明しているのか興味があります。Agile開発を重視するのか、厳格なワークフロー管理を重視するのか、GTDのようなタスク管理なのか、課題管理に使うのか。100人分のRedmineの使い方が知りたい。

【1】チケット駆動開発にはいくつかのパターンがある。
一つの観点は、補完チケット方式か完全チケット方式。
もう一つの観点は、トラッカーの観点。

補完チケット方式は特定の工程や特定の作業にチケット駆動開発を適用するやり方。
よくある例は、テスト工程のバグ管理、設計・開発工程のレビュー管理があるだろう。
@machuさんがチケット駆動開発を提唱された時も、テスト工程における細かな作業の管理に使われていた。
その考え方については下記に書いた。

補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索

障害管理からチケット駆動開発へ発展した歴史から見れば、補完チケット方式は先祖返りの開発スタイル。
高機能化したBTSの機能(レポート、ワークフロー、Wiki、SCM連携など)を使えば、より効果的に作業を管理しやすくなるのは当たり前だ。

完全チケット方式はソフトウェア開発で発生する全ての作業をチケット化して管理していく。
以下、完全チケット方式を前提に話を進める。

【2】トラッカーの観点とは、チケットの発生源が何であるか、によって変わってくる。
随分前にも色々考えた。
Redmineを使って気付いたことpart6～チケットの発生源: プログラマの思索

タスクカードのように扱うタスク駆動が一番やりやすい。
GTDのようなタスク管理もできるし、作業指示書として厳格なワークフロー管理の配下に置くこともできる。
僕がアジャイル開発へ適用した時も、タスクカードのように扱うやり方で行った。
要件や仕様の粒度を小さくすることができれば、ストーリーカードのようにチケットを扱ってもっとアジャイルに開発することもできるだろう。

タスクカードのように扱う場合、チケットはすぐに溢れるので、チケットの取捨選択が重要になってくる。
基本は、バージョンをイテレーションに同一視する(「Version is Iteration」)ことによって、アジャイルっぽい開発スタイルになる。
イテレーション単位にタスクを区切っていくタイムボックス的なタスク管理が一番やりやすい。

【3】営業マンや社内の事務の人がITSでタスク管理を行う場合、チケット入力のユーザインタフェースの改良が重要になってくるだろうと思う。
元々チケットは障害報告票が起源なので、入力項目が多すぎたり、複雑な操作になりがち。
それほどITに慣れていない人達にチケット駆動開発に慣れてもらうためには、デスクトップアプリのように使いやすいUIにすることが重要になってくる。
WebならAjaxなりJQueryなりCSSなり、クライアントサイドの技術が必要になってくるだろう。

Redmineのユーザインターフェイスは使いやすい: プログラマの思索

また、WebのUIは一時保存や自動保存の機能が弱いので、せっかく入力した内容が消えてしまってガッカリする時も多い。
そんな場合は、RedmineならDrafts pluginを導入して、自動保存する機能を追加すればいいだろう。

作成途中のチケットを自動保存するDrafts plugin #redmine: プログラマの思索

RedmineでUI改善に可能性を感じる機能は、REST機能だ。
RESTの使い道としては、例えばiPhoneやAndroidなどのスマートフォンからURLを叩けば欲しい情報を取得したり更新したりすることがあげられるだろう。
つまり、スマートフォンやタブレット、TV、携帯ゲーム機などの各種デバイスからサーバーにあるRedmineへアクセスすれば、ブラウザの画面と同じように操作できるUIを作ればいい。
そうすれば、各種デバイス向けにITSの機能を逐一作る必要もない。

RedmineのRESTful APIを使う: プログラマの思索

SOAPからRESTへ: プログラマの思索

RedmineのREST機能は@yohshiyさんの下記のWikiがとても参考になる。

Redmine REST API - r-labs

スマートフォンからRedmineを操作できるならば、外出先で営業マンがタスクを検索したり更新することも楽になる。
あるいは、CIツールJenkinsやテスト管理ツールTestLink、他の外部システムからRedmineへアクセスして欲しい情報を取得したり連携することもできるだろう。
REST機能によるUI改善は大きな可能性を秘めていると思う。

【4】システム運用保守やコールセンターで障害や問合せの管理を行う場合はインシデント駆動になる。
例えば、ネットワーク障害やハード障害が検知されたら、その障害をまず管理票として起票した後、暫定対応を実施したり、影響範囲や根本原因を調査して根本対策を実施したりする。
ITILの概念に慣れていれば、適用しやすいだろうと思う。

ITILのプロセス関連図: プログラマの思索

その場合、技術的に面白い点は、他システムのチケット発行をトリガーとしてチケットを自動登録する機能だ。
よくある例は、障害検知したら普通は障害ログのメールが発行されるタイミングでチケット登録すること。
Redmineにはメールを送付すればチケット登録できる機能があるので、この機能を簡単に実装することができる。

Redmineのチケット登録をITILへ応用する: プログラマの思索

Redmine for ITIL: プログラマの思索

@haru_iidaさんは、Hudson(Jenkins)から発行されるビルドエラーメールをRedmineに投げて、チケットを自動登録する事例を紹介されていた。

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

チケットを自動登録できる利点は、障害の検知から調査、暫定対応、対応完了に到るまでの作業履歴をチケットに集約しやすいこと。
チケットに作業履歴が一元化されれば、その後の運用保守で過去の事例として参考になるし、障害別にレポート出力すれば障害の傾向分析にも使える。

そして、インシデント駆動の場合はタスク駆動以上にレポート機能が重要だ。
普通は障害の発生原因は特定のパターンがあるし、障害が発生しやすい環境を是正する対策作りにレポートがとても役立つからだ。

【5】システム提案や要件定義でチケット駆動開発を運用するなら課題駆動になる。
僕は課題駆動が一番難しいかもと最近思っている。
何故なら、SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探すからだ。
そして、提案書や設計書は課題の回答をパッチのように更新して出来上がる。

課題管理のチケット駆動開発: プログラマの思索

顧客の曖昧な要望、作れたらいいなという希望から実際に使えるシステムへ変換する作業はとても難しい。
アジャイル開発はその作業の一つの手法だが、多分それだけでは足りない。

もっと基本的な手法が必要な気がしている。
つまり、要望をシステム要件に落とす時、フィージビリティスタディ(実現可能性)をどこまで深く考えているか、という能力に大きく左右される気がしている。
その技術はよりソフトウェア設計の基本的なものだ。
この辺りはもう一度まとめ直す。

クラウド時代のソフトウェア品質管理。それは健康管理と同じ

Googleのソフトウェア品質管理、テスト管理の記事があったのでリンクしておく。
感想をラフなメモ書き。

【元ネタ】
クラウド時代のソフトウェア品質管理。それは健康管理と同じだとグーグルのテスト担当者 － Publickey

開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

(引用1)
かつてのようにソフトウェアは単に、開発してリリース、とはならない。ソフトウェアは成長するように構築されるものではなく、出荷されるものでもない…それは単に利用可能になるのだ、文字通り、スイッチを入れるように。

組込製品やパッケージ製品、公共インフラのような高信頼性を要求される製品の場合、WF型で開発してテストした後にリリースの儀式がある。
しかし、Web2.0のようなソフトウェア開発は永遠のベータ版と言われるように、頻繁なリリースは当たり前であり、リリースとは大げさなものではなくシステムが利用可能になるだけ、と主張している。

(引用2)
品質管理と品質保証について、父親の時代のソフトウェア、デミング博士のモデルでは、私たち（テスト担当）の役割は検査官（Inspector）にあたる。しかしそれとは対照的に、いまの私の仕事は内科医のようなものだ。
実際のところ、医療の例えはソフトウェアテストについて考えるとき興味深い類似点がある。内科医にとっての病院は、私たちにとってのデータセンターだ。つねに活動があり、多くのことが並行して起きている。
(中略)
さあ、テスターが診ることができるように、生体活動をモニタするための機器を取り付けよう。人間の患者のように、アプリケーションには脈拍があり、データは血液の流れのようにコードのあいだを流れていく。

品質管理や品質保証を内科医に例えているのが面白い。
ソフトウェアテストは健康診断みたいなもの。
その喩えから類推すれば、システムの品質を数多くのメトリクスで出力することが大切になるし、どのコンテキストでどんなメトリクスが有効なのか、という問題に発展するだろう。
特に最近はプログラミング言語がとても強力なので、コードの静的解析だけでなく、ソフトウェアの動的な構造やアーキテクチャを検証する技術をプログラムで自動化する方向へ発展しているように思える。

(引用3)
プロジェクトとレポートラインを分けることは1つのチャレンジだ。これまでは、テスターは（製品チームにとって）外部のリソースだった。製品チームにとってテストとはあまりに多くのリソースを必要とするため、それを適切に維持することができなかったのだ。
そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストのインフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。テスターはデベロッパーがテストできるようにするのだ。

(引用4)
品質とはどのように実現するものなのか？ という問いに対して、Whittaker氏は次のように書いています。
(中略)
この難問に対するシンプルな答えは、開発とテストを分けて考えるのを止めることだ。（略）品質を確保することとは、テストを行うことと同じではない。それは開発とテストをそれぞれの区別が付かなくなるまで融合させていくことなのだ。
そして、開発とテストの融合こそ、グーグルのゴールであると。
実際にコードを書いている人たち以上にうまくテストできる人がどこにいる？ コードを書いている人以上にうまくバグを見つける人は？ バグのないコードを書きたいと思っている人は？ グーグルがわずかな専門テスターだけで済んでいる理由は、デベロッパーが品質に責任を持っているからなのだ。
品質とは開発の問題であって、テストの問題ではない。これを推し進めて、私たちは開発の中にテストを組み込んでいる。ハイパーインクリメンタルなプロセスを作り、だれかがバグを組み込んでしまったらそれ以前の状態にまでロールバックできるのだ。

品質保証部門やテスト部隊の必要性は分かっていても、その人達はコストセンターになりやすい。
テスト前の工程ではテスターは暇だからだ。
むしろ、プログラマが自身の成果物に関する品質の最終責任者であるし、テスト技術を持ってもいい。

(引用5)
ほかの多くの企業よりも少ない人数のテスターでグーグルはよい結果を得られているが、その鍵となっているのが、多くの機能をいちどに提供することをほとんどしない点にある。
もし実際の利用でバグが発見されたら、テスターはそれのためのテストを作り、それぞれのチャンネルのビルドに対して修正がちゃんと実装されたかどうか実行してみる。
(中略)
強調しておくと、グーグルではスクリプトによるもの、もしくは探索的なマニュアルテストのどちらも重要なものとして扱っている。
先進的なレコーディング技術によってマニュアルテストは自動テストへと変換され、ビルドの後再実行することでレグレッションを確認できるようになる。そしてこれが、マニュアルテスターがつねに新しい問題にフォーカスすることを可能にしてくれる。私たちはマニュアルテストの繰り返しとバグレポートの提出も自動化している。

ソフトウェアテストの技法で探索的テストは頻出されるが、実際の運用はとても難しい。
テストケースも関係なく、テスターの経験値を信頼して、自身で作業ログを取りながらバグを見つけて探っていく。
だから、新人のテスターやシステムの仕様が分からないテスターは探索的テストに向かない。
又、探索的テストはテスト工数を見積りにくいため、テストに際限がないリスクもある。
しかしながら、最近はPC上で操作ログを動画で記録したりできるので、バグの再現性を保証しやすくなってきた現実はある。

RedmineやTestLinkを使った経験から、テスト管理や品質管理の技法はかなり研究されているものの、タスク管理に比べると全くIT化されていないと思う。
ソフトウェアテストでは今でもExcelが幅を効かせていて、テスト結果の記録も手間がかかるし、集計するのは更に面倒だ。
だから、せっかくテストしても有効な知見が蓄積されないので、同じようなミスを何度も繰り返す時も多い。
アジャイル開発ではWF型開発よりも、はるかに高度な品質管理が要求されているのに、実際の現場ではIT化されてないためにボトルネックになっている時も多い。
色々試してみる。

FV表とFL表

テスト仕様書を作る一つの方法として、直交表を用いたHAYST法がある。
HAYST法で重要な概念は、FV表とFL表の二つ。
考えたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
ソフトウエアテスト分析の方法

テスト分析 テスト設計

受入テストのテストケースを作る場合、要求に対してテストケースを作る。
そのテストケースのレベルは、プログラムレベルではなく、顧客の観点になる。
だから、いきなりテストケースを作ったとしても、粒度や網羅性が不十分になりやすい。

「ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」にも書いてあるように、テスト設計で最も重要な観点は、テスト対象の因子・水準を漏らさず抽出することにある。
因子とは、テスト対象のパラメータ。
水準は、パラメータが取りうる値。

例えば、MSのOffice製品をテストする場合、OSやCPU、HDDなどは因子であり、因子OSの取りうる値であるWindows XP, Vista, 7は水準になる。

実際のテスト設計では、因子そのものを漏らしてしまう時も多く、そこから必ずテスト漏れになって、バグが出る。
更に、水準を全て抽出しきれなければ、バグの温床になる。
特に、因子同士の組合せで特別な処理が発生する場合も多いので、それら全てを網羅したテストケースを作るのは実際は非常に大変。

HAYST法では、まずFV表(機能検証表：Function Verification Table)を作る。
FV表とは、機能単位の検証内容の一覧表。
僕のイメージでは、FV表は、テストの観点であり、テストケースを作る元ネタ。
ソフトウエアテスト分析の方法にFV表の例が書かれている。
FV表がしっかり書けていれば、実際のテストケースは1日で500ケースぐらいは簡単に作れる。

次に、FL表(因子水準表：Factor Level Table)を作る。
FL表とは、テスト対象の因子と水準の一覧表。
僕のイメージでは、テスト対象のパラメータの組合せを作る元ネタ。
特にデシジョンテーブルの入力条件を洗い出す時に使っている。
ソフトウエアテスト分析の方法にFL表の例も書かれている。
FL表がしっかり書けていれば、テストに必要なデータパターンを機械的に洗い出すことができる。

ソフトウエアテスト分析の方法では、FV表とFL表から作られたテストケースをTestLinkにインポートした画面で終わっているのが印象的。

FV表とFL表という言葉は今まで知らなかったけれど、それに似たような作業はやっていたので腑に落ちる。
実際のテストケースレビューでは、テストの観点に相当するFV表を何度もレビューして、漏れが無いかチェックしていた。

FV表やFL表を作る元ネタは実際は、画面遷移図だったり、システムの状態遷移図だったりする。
つまり、要件定義や外部設計、内部設計の成果物の品質が悪ければ、FV表もFL表の質も悪くなる。
逆に言えば、FV表を作りながら設計書を作れば、自分の設計を自分で検証しながら作っているのだから、機能設計書の品質は良くなるはず。
又、FL表を意識しながら状態遷移図を作れば、システムの状態や状態遷移の漏れをチェックできるので、システムの状態遷移図の品質も良くなるはず。

「ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」によれば、FV表に出てくる機能は「名詞＋肯定形の動詞」で表現でき、その否定形である故障モードは「名詞＋否定形の動詞」で書けるらしい。
すなわち、その故障モードに影響度を追記した表はFMEA(意味：故障モードとその影響の解析）になるので、トラブルの予測に使える、とのこと。
確かに、FMEAがあれば、業務システムの運用保守や組込製品の故障分析で威力を発揮するように思う。

テストケース作成技法を持っていれば、テスト駆動開発と組み合わせることもできるはず。
テストケースが分かっていれば、それに基づいて実装すれば、自然にテスト駆動開発になるからだ。
つまり、Agile開発にテストケース作成技法を組み合わせれば、品質をより強化できるはず。

テストケース作成技法は日本の品質管理技法の中でかなり研究されてきた分野なので、奥も深い。
色々調べてみる。

TestLinkを運用して気付いたことpart12～スモークテストはお試しテスト

SEA関西プロセス分科会で講演後、宿口さんとNakaさんから、ブロッキングバグが多発するならスモークテストをあらかじめやってレビューで潰しておけばいいのでは、という指摘を受けて、なるほどと思ったのでメモ。

【元ネタ】
【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」: プログラマの思索

TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト: プログラマの思索

Software Testing - Columns: スモークテスト

スモーク テストのガイドライン

＠IT：The Rational Edge　オープンソース時代のテスト手法（2）

スモークテストの定義は下記の通り。

(引用開始)
最初に実施するテストは「スモークテスト」だ。
これは元来「ハードウェアコンポーネント」テストと呼ばれていたもので、エンジニアが慎重に部品に電源を投入し、これから実施する大規模テストに向けて十分それが安定していることを確認するものだ。
もし、部品から煙が出たり発火したりするようなことがあれば、この最初のテストは失敗ということになる。
一方、ソフトウェアのスモークテストは、基本テストをいくつか実行し、そのソフトウェアが大規模テストに耐えられるかどうか確認する。

つまり、スモークテストとはお試しテストと同義だ。
スモークテスト(お試しテスト)が必要な理由は、本来のテストの観点でテストするために、ブロッキングバグが出る回数を減らして、テスト効率を高めるためにある。

テストを実施してバグが多発した場合、失敗したテストケースに依存するテストケースはブロックになる。
ブロッキングバグがたくさん見つかるほど、ブロッキングバグ数が少なくても、ほとんどのテストケースがブロックになってしまい、テスト不能の状態に陥りやすい。
すると、本来、テストで確認したかったテストの観点の検証ができなくなり、テストの意味がなくなってしまう。

例えば、複雑な業務シナリオに基づいて、本番の業務を想定した受入テストを行っている時に、単体テストレベルの不具合がたくさん見つかり、本来のテストを進められない状況が相当するだろう。

Software Testing - Columns: スモークテストで西さんが書かれているように、スモークテスト(お試しテスト)は、開発プロセスがしっかりしていて、単純なバグが出ないぐらいの品質を確保されているなら、実施する必要はない。

スモークテスト(お試しテスト)が有効な場面は、プロジェクトが混乱していて、たくさんの仕様変更に対応したためにデグレードが頻発していたり、ブロッキングバグを全て潰しきれていないのに機能追加を進めている状況だ。
そんな状況では、いくら大量のテストケースを準備しても、すぐにブロッキングバグが多発して、テスト不能になってしまい、テストしても無意味な状況になる。
だから、基本的なテストケースを少数用意しておき、それをスモークテスト(お試しテスト)として実施して、ビルドモジュールの品質をあらかじめ味見しておくわけだ。

スモークテストでバグが多発するようでは本番を想定した受入テストを実施しても無意味なので、まずはスモークテストが通るレベルの品質は保証してもらえるようにあらかじめチェックしておく。
つまり、スモークテストのテストケースを品質保証部門があらかじめ作っておき、それを開発チームに渡して、開発チームはスモークテストをクリアしておくように運用する。
そうすれば、品質保証部門に渡されるビルドモジュールは最低限の品質は保証されているので、受入テストなどの複雑なテストケースを実施して、テスト効率を高めることができる。

Software Testing - Columns: スモークテストで西さんが書かれているように、スモークテスト(お試しテスト)は回帰テストで自動化できるようにしておくと、より効率がよくなる。
スモークテストのテストケースはあらかじめ決まっているのだから、Seleniumなどのツールを使って自動化しておけばいいだろう。

スモークテスト(お試しテスト)は全て成功するのが当たり前のテストであり、そこでNGになるようでは先が思いやられる。
特に大規模プロジェクトでは、複数チーム間でライブラリのやり取りが多くなるので、スモークテスト(お試しテスト)で品質を味見しておくようにすれば、スムーズに作業できるようになるだろう。

テストはまだまだ奥が深い技術だ。

【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」

本日、SEA関西プロセス分科会にて講演した「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」をCC Attributionライセンスで公開します。

SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」

View more presentations from akipii .

チケット駆動開発に関する内容はさかばさんにお任せして、本講演ではTestLinkによるテスト管理のプラクティスについて話しました。
僕が過去3年間TestLinkを通じて経験したこと、理解したこと、考えたことは全て話したつもりです。

TestLinkを通じて経験したことは、テストはプログラミングとは異なる技術だということ。
テストはやはり計画駆動であり、Agile化は難しい。
そして、テストの特徴として、回帰テストが多いこと、同類バグ調査が重要な点があります。
だからこそ、継続的インテグレーションによる回帰テストの自動化は、XPのプラクティスの中でも最も重要な指摘事項になります。
そして、バグの周辺には必ず同じ原因のバグ(同類バグ)や関連するバグが残っているので、どれだけ残存バグを見つけられるかが重要になってきます。

テスト技術はまだまだ未知の世界なので、ノウハウを少しずつ貯めていきたいと思います。

TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト

Nakaさんからテスト手法について聞いたのでメモ。
以下メモ書き。

【参考】
TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkのベストプラクティス集: プログラマの思索

TestLinkのアンチパターン: プログラマの思索

TestLinkのFAQ: プログラマの思索

TestLinkを受入テストで運用する方法: プログラマの思索

【1】お試しテスト

お試しテストとは、テスト対象モジュール・テストケース・テスト実施者などを対象として、本格的なテストを実施する前に味見するテスト。

例えば、携帯電話の実機とそのプログラムをテストする場合、本格的なテストをする前に、いくつかの基本的なテストを実施して、発見されるバグが多すぎるなら、テストしても無意味だから開発チームへ送り返す。
業務システム開発ならば、要件定義や詳細設計などの上流工程が穴だらけのまま何とか開発して動作できるようにしたものの、異常系のテストがボロボロみたいな状況の場合、テスト不能として送り返す。

これらの状況の場合、テストケースをきちんと準備してテストを開始すると、いきなり重大なバグが出て、後続の依存するテストケースが殆どブロックになってしまって、テスト不能に陥った状態があげられるだろう。
つまり、テストを続行しても、テストに耐えれる品質でない場合が多いだろう。

あるいは、テストケースをお試しテストの対象とした場合、テストで殆ど潜在的なバグを見つけられないなら、テストケースの品質が良くないと評価して、テスト仕様書を作り直す。
この状況の場合、テストケースの品質が良くないため、バグ出しできていないので、テストケースが要件や仕様を網羅しているか、漏れている仕様はないか、などの観点で作り直す時が多いだろう。

あるいは、テスト実施者(テスター)をお試しテストの対象の場合、テスターがテスト作業に向いているかどうかを判定するために使う。
実際のテスト作業は、仕様を理解して、テストの事前条件のためのテストデータを揃えて、エビデンスをきちんと採取して、細かい部分まで検証する作業が多い。
そういうテスト作業に向いていない人もやはりいる。
だから、お試しテストでふるいにかける。

いずれの場合にしても、本格的なテストを行う前に、モジュール・テストケース・テスト実施者の品質がクリアされているかどうかを早めに検知して、開発チームへフィードバックすることを目的とするわけだ。

【2】フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト(ストレステスト or 負荷テスト)

フールプルーフテストとは、フールプルーフの機能をシステムが満たしているかどうかのテスト。
つまり、ポカよけできているかどうかのテスト。

信頼性設計 - Wikipedia

よくある例は、電子レンジのふたを開けたら発熱を止める機能があるだろう。
例えば、医療機器や家電製品の場合、ユーザが誤動作しても安全に動作しないと、人体や社会に大きな影響を与えるから重要なテストになる。
開発者がテスターになるよりも、開発に携わっていない人がテストすると、マニュアル通りの操作をしないので、ポカよけできているかどうか判断しやすい。
多分、結合テストやシステムテストの一部として含まれる時が多いだろうと思う。

似たようなテストとして、モンキーテスト、探索的テスト、フェイルセーフテストもある。
モンキーテストとは、特に目的を定めず、猿のように操作を行うテスト。
Webシステムなら、テストの最後に、実際にユーザが初めてシステムに触れることを想定して、何も考えずにテストする時が多いだろう。

探索的テストとは、経験者がテスト仕様書から離れて、特定の機能を深堀してテストしていくこと。
テストの例としてよくあげられるが、実際のテスト作業としては難易度が高いと思う。
理由は、バグが出たとしても再現させるのが難しかったり、仕様を深く理解していなければテスト工数の無駄になりがちだからだ。
前者の対策としては、バグを再現させるために、作業ログが重要。
昔は紙に作業ログを書きながら、少しずつテストしていくしか無かったけれど、今は操作を動画で採取するのが非常に簡単になった現状もある。

フェイルセーフテストは、フェイルセーフの機能をシステムが満たしているかどうかのテスト。
つまり、故障が発生したとしてもシステムが安全に稼働しているかどうかを検証する。
実際は、ある部品や機能が壊れたとしても安全に動作するように冗長化されているか、などの観点が含まれるだろう。
最近は、組込製品の安全性が品質要件として重要になってきた傾向があるので、フールプルーフテストやフェイルセーフテストもテスト工程に含める時が多くなっているだろう。

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索

ラッシュテスト(ストレステスト)は、特にWebシステムの負荷テストのこと。
下記の記事のように、システムが大量のアクセスに耐えれるかどうかを検証する。
最近は、JMeterなどのツールを使って、性能要件を満たさないボトルネックを見つけて、サーバーの設定を変えたり、メモリを増やしたり、RAIDにして冗長化するなどの対策を取る時が多いだろう。

負荷テストとは 「ストレステスト, ラッシュテスト」 (stress test)： - IT用語辞典バイナリ

Webシステムのリリース作業とフォールトトレランス: プログラマの思索

TestLinkで上記の観点のテストを含める場合は、テスト計画単位にアサインする手法が良いと思う。
つまり、お試しテスト、フールプルーフテスト、フェイルセーフテスト、ラッシュテストのテスト計画を作って、それぞれのテストケースを割り付けて、五月雨式にテストしていくやり方。
テスト計画をイテレーションに紐付けて、イテレーション単位にアジャイルにテストしていく手法が良いと思う。

理由は、プロジェクト後半という限られたテスト工数しか確保できない状況では、テストの目的を明確化してテストした方が効率が良いからだ。
但し、モンキーテストや探索的テストは特にテストケースが無いため、除いている。

テストはやればやるほど奥が深いと思う。

ITの地殻変動はどこで起きているのか？～チケット駆動開発が進むべき道

2011年になって、ITの地殻変動がどこに起こっているのか？を改めて考えてみる。
ラフなメモ書き。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

現代のAgile開発が抱える課題: プログラマの思索

Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索

【ソフトウェア開発の課題】
ソフトウェアは変化するのが宿命。
ハードがこれだけ日進月歩で進化しているのに、VerUpしないソフトウェアは価値がない。

しかし、SW開発はとても繊細。
たった1行のソース修正でシステムはすぐに動かなくなる。
ハードやOS、ブラウザを安易にバージョンアップすると、システムは不安定になる。
ソフトウェア開発は製造業よりもはるかに繊細だ。

だから、変更管理が重要。
どのコンポーネント、どのソースをどのように直したのか、どのモジュールをリリースしたのか、をきちんと記録して、あらかじめ作業手順をレビューして承認していくフローが必要になる。
だが、そのワークフローは大量のドキュメントとたくさんの承認フローによって、すぐに重厚長大となり、ソフトウェア開発の速度を落とす。

開発案件が大規模になるほど、承認フローや意思決定が複雑になる。
サブシステム間の課題や作業のやりとりをチームレベルではなく、もう一つ上の層で意思決定する場が必要になってくる。
従来の課題管理会議では、開発チームのリーダークラスが集まって、チーム間の課題やプロジェクトの方向性について議論して、組織としての方針を決定する。
しかし、大規模化するほど、会議は長引き、決まるのが遅くなり、組織そのものの進捗も遅くなる。

だが、ソフトウェア開発の本質から生じる上記の諸問題に対し、アジャイル開発は過激な主張を持って解決しようとしている。
「変化を抱擁せよ」のキャッチフレーズ通り、アジャイル開発の最大の特徴は変化に強いこと。
XPが提唱するソースの共同所有、テスト駆動開発、継続的インテグレーション、小規模リリースなどのプラクティスによって、開発者が作業するインフラが整う。
そして、Scrumが提唱するバックログ、スプリントなどの諸概念によって、アジャイル開発のプロジェクト管理のフレームワークも整った。

しかし、アジャイル開発の最大の弱点は、従来の環境のままでは変化が激しいタスク管理やイテレーション管理を制御するのが難しいこと。
そして、アジャイル開発の事例は小規模プロジェクトが多かったため、つい最近まで、大規模プロジェクトではアジャイル開発は適用しにくい、アジャイル開発は設計や品質の作り込みが弱い、と言われ続けてきた。

【チケット駆動開発の意義】
チケット駆動開発はTracのチケット管理から生まれた。
発端はまちゅさんが提唱されている。

チケット駆動開発の特徴は、BTS(バグ管理システム)のチケットを障害だけでなく、仕様変更やリリース作業などあらゆるタスクを管理する方向へ拡張した点にある。
これがいわゆるIssue Trackingと呼ばれる特徴だ。
だから、TracやRedmineはBTS(Bug Tracking System)ではなく、ITS(Issue Tracking System)と呼ばれている。

そして、チケット駆動開発の最大の意義は「BTSチケットをXPのタスクカードのように扱う」ことによって、アジャイル開発のプロジェクト管理に応用できる点にある。
＃この発想はさかばさんが提唱された。

TracやRedmineでは、単にチケットを障害管理に使えるだけでなく、ガントチャートやカレンダーなどの進捗管理機能、ロードマップやリリース履歴などのリリース計画機能、チケットの種類(トラッカー)に応じた柔軟なワークフロー管理、構成管理との連携によるトレーサビリティ、チケットの集計機能を使った品質管理機能など、各種の機能が豊富にある。

BTS(ITS)の優れたプロジェクト管理機能を使って、アジャイル開発のプロジェクト管理を容易に構築して、更にブラッシュアップすることも可能になった。

この発想は、生物進化の前適応の話を連想させる。
前適応とは、ある適応された形質が形作られる場合に、以前から存在した別の機能を持つ形質が用いられたことを指す。

前適応 - Wikipedia

大量絶滅 - Wikipedia

前適応の例は、恐竜から鳥へ進化した経緯が分かりやすい。
恐竜は、数億年前、生物の大絶滅で酸素が急激に減った環境から生まれた。
そのため、恐竜は低酸素の環境でも生存できるように、気嚢と呼ばれる優れた酸素ガス交換機能を持つようになり、その機能が鳥にも引き継がれた。
実際、鳥を解剖してみると、気嚢とよばれる器官が肺から体中に伸びていて、新鮮な酸素を体中に行き渡らせることができているらしい。
その機能のおかげで鳥は、ヒマラヤの高山の空という低酸素の空間でも飛ぶことができる。

更に、小型化した恐竜は体温を維持するために、羽毛を持つようになった。
その羽毛が翼に進化して、鳥は飛べるようになったという説がある。

つまり、鳥が持つ気嚢や羽毛は、本来恐竜が生存していくために作り出した機能だったが、鳥はそれらの機能の目的を変えて、自分たちの都合の良い機能へ意味を変えたわけだ。
だから、鳥は生きた恐竜の化石とも呼ばれているらしい。

前適応の話を聞いて、障害管理からチケット駆動開発へ発展した話と全く同じ構造を持っているような印象を持った。
チケット駆動開発の特徴であるプロジェクト管理機能(チケット管理、進捗管理、構成管理やビルド管理との連携によるトレーサビリティ機能、強力なワークフロー管理など)は、本来は障害管理に必要な機能として発展してきたのだが、目的を変えるだけで、アジャイル開発のプロジェクト管理にも使える、と世界中の人達が気付いたわけだ。
そして、世界中の開発者が、アジャイル開発のプロジェクト管理を実現するツールをどんどん作り出している。
その可能性はとてつもなく大きいと思っている。

【チケット駆動開発の可能性】
僕が今後試してみたいのは、Redmine上でチケット駆動開発を行う事によって、アジャイル開発の運用のハードルを下げるだけでなく、アジャイル開発の新しい運用方法も提唱してみたいことだ。
チケット駆動開発にXP・Scrum・CMMI・PMBOK・ITIL・SW工学・原価計算・PFなどの知識を詰め込んで、チケット駆動開発を理論として強化していきたい。
Redmineを単なるプロジェクト管理ツールだけでなく、SW開発の全ての業務を支援するツールへ高めたいのだ。

つまり、XP・Scrum・CMMI・PMBOK・ITIL・SW工学・原価計算・PFなどの理論や概念は本来それぞれの目的があるだろうが、チケット駆動開発を支援するための手段や道具とみなして、チケット駆動開発をソフトウェア開発の体系的な理論として骨付して肉付けしていきたいのだ。

ラフなイメージは下記の通り。
以下は書きかけ。
少しずつ考えていきたいと思っている。

【1】ロードマップによるリリース計画作り
　小規模リリース
　イテレーションとリリース予定バージョンを同一視する
　タイムボックス的な開発
　漸進型開発と反復型開発の違い

【2】バックログによる要件管理
　要件のイテレーション管理
　　チケットの親子関係
　　　RedmineのSubstasking
　　期限の無いリリース予定バージョンで管理する方法もある
　　チケットをイテレーション間で移動する
　サスペンドリンク
　　要件変更の影響範囲
　　仕様変更の工数を予測可能になる

【3】SCM連携によるトレーサビリティ
　レコメンドエンジンの実装
　　ソース修正時に過去に修正した関係ソースやチケットを表示する
　　同類バグの調査
　　設計漏れをなくす
　分散バージョン管理との連携
　　構成管理パターン
　　　ブランチ管理
　　　マージ機能
　　イテレーションとコードラインの関係性

【4】テスト管理ツールとの連携、ビルド管理ツール、コードレビュー管理ツールとの連携
　メトリクスの使い方
　　信頼度成長曲線
　　　SRATS
　　テスト消化曲線
　　　TestLinkCnvMacro
　品質管理の考え方
　　ブロックやみなしバグの影響範囲を示唆する
　　同類バグの範囲を自動的に示唆する
　移植性
　　再利用性
　　ソフトウェアプロダクトライン
　　派生開発
　　XDDP
　保守性
　　リファクタリング
　　変更容易性
　コードレビュー
　ビルド管理
　　並行ビルド
　　本番環境の仮想化
　RestfulAPI
　　外部ツールと連携
　　エンドユーザコンピューティングのためのクライアントツールと連携

【5】ワークフロー管理
　変更管理の考え方
　　自然なペア作業
　　チケットをCloseする時は必ず二人の目を通す
　ITILの考え方
　　サーバー監視ツールが障害を検知したら、メール送信する時にチケットも自動登録
　　Hudsonがビルドエラーを検知したら、メール送信する時にチケットも自動登録
　　トラッカー単位に集計してプロセス改善
　　オペレータが対処できないチケットは、上位管理職へエスカレーションする
　ワークフローの可視化

【6】大規模アジャイルの運用方法
　アジャイルリリーストレイン
　スクラムオブスクラム　
　アーキテクチャ助走路
　分散開発は？
　　プロジェクトファシリテーションを分散開発のチームビルディングへ拡張する

【7】PMBOKのEVM、活動基準原価計算(ABC)
　予定・実績工数の管理から原価管理
　プロジェクトの製造原価、コスト、利益をシミュレーションする

【8】PMBOKの応用
　クリティカルパスの計算
　ボトルネックの探索
　PMIS
　アジャイル開発のプロジェクト管理の概念をPMBOKで支援する

【9】PF(プロジェクトファシリテーション)のプラクティスと連携
　朝会
　KPTによるふりかえり
　　プロセス資産
　ニコニコカレンダー、かんばんをデジタル化
　オフショア開発のように場所が離れた場合のチームビルディング方法
　　オープンソースでは当たり前

【10】Excelをエンドユーザコンピューティングとして使う
　マネージャや顧客が欲しいデータはCSVで渡せばいい
　　好きなようにカスタマイズしてくれればいい
　　何も全ての機能をRedmineで実現する必要は無い
　　　業務システムが全帳票を作る必要はなく、CSVでデータ提供する機能を実装しておくのと同じ

TestLink plugin for Redmine

SundayWalkerさんがRedmineの画面上にTestLinkの画面を表示できるプラグインを公開されていたのでメモ。

【元ネタ】
チケット #23961: TestLink plugin for Redmine - TestLink日本語化 - SourceForge.JP

Twitter / なかむら　かおる: [redmine][TestLink]RedmineからTestLinkの機能を利用するプラグイン。TestLinkの画面そのまま、すごい！ / チケット #23961: TestLink plugin for Redmine

TestLink plugin for Redmineのイメージは、Readme-01.pngを見ればすぐに分かるだろう。

(引用開始)
こんにちは、SundayWalkerです。
TestLink1.9が公開されて、不具合の対応もかなり進んでいるようです。
以前からTestLinkとRedmineは、非常に良いツールと思っており、２つのツールの連携がより強化できると良いと考えておりました。
両者の連携強化の第1弾として、先に公開したTestLink1.9beta6用のCASのパッチは、TestLink1.9でも利用できると思います。
＜注釈：TestLink1.9beta6用のCASのパッチとは、TestLink1.9b6 CAS (SSO) パッチ (Testlinkjp-users) - TestLink日本語化 - SourceForge.JPを指していると思われる＞
両者の連携強化の第2弾として、RedmineでTestLinkの機能を利用するためのプラグインを作成してみました。 RubyとJavaScriptの初心者が作成しましたので、あまりできは良くありませんが何かの参考になれば幸いです。
以下に概要を示します。以下の内容はプラグインの中のReadme-jp.htmlファイルとほぼ同じです。
【TestLink plugin for Redmine】
1. はじめに
これは、RedmineでTestLinkの機能を利用するためのプラグインです。
2. 前提条件
本プラグインを使用するには、Redmineと同じWebサーバ （もしくはJavaScriptのAjax通信が可能なサーバ）に TestLinkを事前にインストールしておく必要があります。 また、Redmineのプロジェクト名と同一のTestLinkのプロジェクトをあらかじめ 作成しておく必要があります。
RedmineとTestLink共にCAS対応に設定しておくことを推奨します。 CASを使用しない場合は事前にTestLinkにログインしておく必要があります。
3. インストール
以下の手順でプラグインをインストールします。
* 本プラグインをRedmineの'vendor/plugins'フォルダにコピーします。
* Redmineを再起動します。
* Redmineの'Administration'の'Plugins'の画面にて、 'TestLink plugin for Redmine'の'Configure'を選択し、 'TestLink base path'に適切な値を設定します。
* Redmineの'Administration'の'Roles and permissions'の画面にて、 'Testlink'の機能を利用するRoleを選択し、 'TestLink'にチェックを付けます。
* Redmineの各プロジェクトの'Settings'のModulesにて'Testlink'にチェックを付けます。
4. ライセンス
GPL v2
5. 作者のテスト環境
* Redmine 1.0.3 + Apache + Mongrel + CASプラグイン
* TestLink 1.9 + CASパッチ
* Windows XP SP3
注意：RedmineのCASプラグインはMongreでは動作しますが、FastCGIでは動作しないようです。
6. 機能
6.1 TestLinkタブ
Redmineのプロジェクト名と同一のTestLinkのプロジェクトの画面を表示します。
[Plugin Load Denied: embed]
6.2 WiKi - linkto_testlinkマクロ
TestLinkタブの画面へのリンクを設定するマクロです。
6.3 WiKi - include_testlinkマクロ
TestLinkの画面をインラインフレームとして表示するマクロです。
TestLinkの'workframe'（右下のフレーム）を指定した場合は'workframe'を、 そのほかの場合は'mainframe'（下のフレーム）の画面を表示します。
'height'を指定しない場合は、表示内容に高さを合わせます。
6.4 WiKi - iframe_testlinkマクロ
TestLinkの画面をインラインフレームとして表示するマクロです。
TestLinkの'mainframe'の画面を表示します。 'workframe'がある場合は、'treeframe'（左下のフレーム）と'workframe'（右下のフレーム）を表示します。
7. 既知の問題点等
* 本プラグインの問題ではなく、CASプラグインとCASパッチの問題として、 RedmineにCASを使用してログインした場合、 CASセッションがタイムアウトすると TestLinkが Redmineより先に検知し、ログアウトの状態になることがある。 この場合、一旦Redmineにてログアウトし、 Redmineにてログインを実施する必要がある。 Single Sign Outなどに対応すると良いのではないかと思われるが、 具体的な変更方法がわかっていない。
* TestLinkを直接使用する場合に比べ、本プラグインでTestLinkの画面を表示する場合、 TestLinkの3つのフレームがコンカレントではなくシリアルに読み込まれるため、 表示が完了するまでに時間がかかる。
(引用終り)

上記のプラグインは、Redmineに入れたプラグイン一覧: プログラマの思索や「Redmineによるタスクマネジメント実践技法」にも書いたr-labs - Hudson - RedmineというHudsonプラグインに似ている。
Redmineの機能の一部にビルド管理Hudsonやテスト管理TestLinkが含まれていれば、開発者はRedmineを意識するだけで、欲しい情報を自分で検索するようになるので、無駄な質問が減って、コミュニケーションの質も向上する。

SundayWalkerさんはRedmineとTestLink連携を色々試されているようで、下記のようなTipsも公開されている。

TestLinkとRedmineでシングルサインオン認証の連携: プログラマの思索

TestLinkはRedmineやTracに比べるとUIが使いづらく、テスト管理という機能に特化しているため理解しづらいが、使いこなせれば、テスト管理や品質管理に大きく貢献するだろう。

Hudson、TestLink、Redmineの間を相互にリンクするプラグインは、最近になって日本人の有志が下記のようにたくさん作ってくれている。
以前に比べるとプロジェクト管理やビルド管理、テスト管理が格段にスムーズになってきている。

HudsonのTestLink Plugin: プログラマの思索
RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索

BTS、CI、SCM、テスト管理、品質管理の各種ツールをプラグインで連携するやり方は、最終的にはプロジェクト管理サーバーを目指している点に落ち着くと思う。
つまり、現場リーダーや開発者の意思決定をサポートするソフトウェア開発のインフラを整えて、もっとAgileに開発できるスタイルに進化していくはずだと思っている。

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索
プロジェクト管理サーバーとは: プログラマの思索

プロジェクト管理サーバーという概念からPMBOKのPMISにつながるアイデアは「Redmineによるタスクマネジメント実践技法」の8.3節「Redmineと外部ツールを連携」で詳しく書いたので是非読んでみて、色々試して欲しいと思う。

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart7 #tidd

日経ITProの新刊・近刊で、「Redmineによるタスクマネジメント実践技法」の書評が公開されたようです。

Redmineによるタスクマネジメント実践技法 - 新刊・近刊：ITpro

(引用)
バグの発生から除去までを管理する手法を、プロジェクトマネジメントのタスク管理にまで広げて使う新手法を著した一冊。バグの管理票をチケットと呼ぶことにちなんで「チケット駆動開発（TiDD）」と名付けている。前半はTiDDの概要やメリットを、後半はバグ管理ツールの「Redmine」を使った実践手法を詳解。主にアジャイル開発での適用を解説する。

TiDDの発端がBTSからITSへの拡張にあること、さらにAgile開発に適用可能である点を端的に説明してくれてます。
ただ、テスト管理ツールTestLinkの説明がなかったのが残念。

【告知】SEA関西プロセス分科会で「TestLinkのベストプラクティス」を講演します

第43回　SEA関西プロセス分科会のご案内

--------------------------------------------------------
～～　第43回　SEA関西プロセス分科会のご案内　～～

テーマ１：チケット駆動開発による現場力の向上
講師　　：阪井 誠 氏（株式会社SRA）
(「Redmineによるタスクマネジメント実践技法」著者)

テーマ２：TestLinkのベストプラクティス
講師　　：小川 明彦 氏（XPJUG関西）
(「Redmineによるタスクマネジメント実践技法」著者)

テーマ３：なぜなぜ分析は、なんでうまくいかへんねん
講師　　　てふかん(テスト技術者交流会 関西勉強会)
角口 勝隆 氏
新美 崇宏 氏
渡辺 亮 氏

主催　：ソフトウェア技術者協会 関西支部 プロセス分科会

日時　：2011年01月15日(土) 13:00～17:00

会場　：大阪市立大学文化交流センター
〒530-0001　大阪市北区梅田1-2-2-600
大阪駅前第２ビル６階　ホール
Tel　06-6344-5425　/　Fax　06-6344-5524
大阪市立大学 - 文化交流センター
周辺略地図
大阪市立大学 - 文化交流センター

内容　：

前回の第42回「セーフウェア」から久々の開催となる今回は、土曜日の午後いっぱいを使っての、テーマ３本立てとなります。
前半は、先ごろ出版された書籍「Redmineによるタスクマネジメント実践技法」の著者お二人による、Redmineによるチケット駆動開発とTestLinkによるテスト改善に関する実践体験に基づいた講演です。
後半は、今年の ETWestコミュニティセッションに登場して好評を博したTEF（テスト技術者交流会）関西勉強会のみなさんによる「なぜなぜ分析は、なんでうまくいかへんねん」の続編として、さらに発展したセッションをお届けします。
様々な手法に関する情報が飛び交う中で、地に足のついた現場での実践に向けての貴重な情報共有と意見交換の場となることを期待しています。

13:00 ～ 13:10
開会挨拶と講演者紹介

13:10 ～ 13:55　講演１
チケット駆動開発による現場力の向上
講演者：阪井誠氏（SRA)

ソフトウェア環境が進化するにつれて高機能なシステムを短期間に構築することが可能になりました。その反面、その開発作業はより複雑で大変なものになり、気合、根性、規律が必要な場面が増えてきました。
チケット駆動開発では、
(1) 障害管理ツールのチケットでタスク管理する
(2) 構成管理ツールなどのツール連携によって自動化と履歴管理をする
(3)ワークフローで手順もれをなくす
ことが可能です。
今回は、このようなチケット駆動開発の概要と、チケット駆動開発の導入によって、プロジェクトが混乱を脱して、元気になった事例を報告します。

14:05 ～ 14:50　講演２
TestLinkのベストプラクティス
講演者：小川明彦氏（XPJUG関西）

昨今のソフトウェア開発では、設計やプログラミングなどの上流工程の技術革新が著しい一方、テスト管理や品質管理が軽視されている傾向が見受けられます。
この状況に対し、XPを代表とするアジャイル開発手法は単体テスト工程にテスト駆動開発や継続的インテグレーションという新しい概念を導入しましたが、結合テスト以降のテスト工程には適用しづらく、品質保証に不十分な面があります。
本講演ではこれらの問題に対し、アジャイル開発とテスト管理ツールTestLinkを組み合わせて効果的に運用した経験を踏まえて、テスト管理に関するベストプラクティスについて解説します。

15:00 ～ 16:20　講演３
ウワサの３人が登場！
なぜなぜ分析は、なんでうまくいかへんねん？　リターンズ
講演者：TEF関西 角口勝隆氏、新美崇宏氏、渡辺亮氏

ソフトウェア開発の現場では、些細なミスがきっかけで大きな損失を被ることもある。
失敗を繰り返さないために、「なぜ？」を５回繰り返して原因分析をすれば良いと言われるが、案外簡単なようで、時にはとんでもない分析結果を導き出すこともあり、実際に行ってみると難しいものである。
当セッションは、「なぜなぜ分析」のアンチパターンから学ぶ、最低限失敗をしないためのポイント解説と、失敗分析理論について考察をする。
Part1：アンチパターン
Part2：分析理論

16:30 - 17:00　質疑応答・ディスカッション

※講演者の都合により、講演の順序が変更となる場合があります。
ご了承ください。

参加費用：
(参加費のみ)
SEA正会員：1,500円，SEA賛助会員：1,500円，
学生：1,000円，一般：3,000円
(書籍付：申し込みは1月8日まで)
SEA正会員：4,000円，SEA賛助会員：4,000円，
学生：3,500円，一般：5,500円

定員　：120名

申込方法：
以下のペ‐ジからお申し込みの受付を行っております．
Application - Kikuno Laboratory
### 01/13(木)までにお申し込みください(書籍付は1/8まで) ###

今回は書籍「Redmineによるタスクマネジメント実践技法」付きのセット価格を用意しました(定価3,444円)。
セット価格をご希望の方は、申込みフォームの最後の「分科会のテーマに関するご要望などをご自由にどうぞ」の欄に「Redmine書籍セット希望」とご記入下さい．
★注意★
出版社との手続きの都合上、書籍セットでの参加申込みは1/8（土）までにお願い致します。
また、欠席で当日お渡しできなかった場合は後日発送させていただきますが、送料はご負担願います。

ご注意）
・受付は先着順で，定員になり次第〆切とさせていただきます．
申込受付後のキャンセルは原則としてお断りします．
・メール，FAXなどWebページ以外からの申し込みは受け付けておりません．
・お申し込みの受付け後，確認メールが自動的に返送されます．
確認メールを印刷し，当日受付時に持参ください．
・申し込み手続きについて不明点などございましたら下記までご連絡ください．
seakansai-req＠sea.jp
・参加費は当日会場受付にて現金でお支払いください
領収書が必要な方は，申し込み時に「領収書要」にチェックしてください．

-------

【談】
「Redmineによるタスクマネジメント実践技法」はRedmineとチケット駆動開発に関するお話がメインではありますが、実はTestLinkによるテスト管理も1/3の頁数を費やして書いてます。
意外にも（？）、テスト管理や品質管理の技法は日本のSIの現場の一部ではよく知られていて、ノウハウが結構たまっています。

僕自身、TestLinkを運用してみて、テスト管理や品質管理の奥深さを随分経験することができました。
今回は、チケット駆動開発のお話はさかばさんにお任せして、TestLinkを過去2年以上運用して経験したこと、理解したこと、思索したことについて語ってみます。