[ThinkIT] 第6回：BTS（Bug Tracking System）の利用 (1/3)
システム開発を進めるにあたり、バグやタスクなどを管理して、現在発生しているバグの数や担当者といったステータスを把握する必要があります。また、ある程度以上の規模のWebアプリケーションを開発する場合、数人のチームで開発を進めるケースが多く、開発を円滑に進めていくためにスタッフ間での情報共有が重要になってきます。 「Bug Tracking System（以下、BTS）」は、これらの問題を解決するためにプロジェクトのバグを管理し、修正状況を追跡できるよう可視化を行うシステムです。現在、BTSとして様々なソフトウェアが公開されており、ソフトウェアを開発する上での必須アイテムになりつつあります。 BTSの多くはWebブラウザ経由でアクセス可能なソフトウェアで、その中から今回はウノウで採用している「Trac」について説明します。 Tracは、BTSとWiki、Subversionリポジトリビューワー
ウノウラボ Unoh Labs: Tracに QA(testing) のステータスを追加する方法
2次元より3次元のほうが好きな hide です。 昨日のmasatoさんのエントリへのコメントで、Tracの話が盛り上がっていたので引き続きTracネタを続けます。今さらTracについての説明は必要ないと思いますが、どんなものかひと言で説明すると、BTSとWikiとSubversionリポジトリビュアーを合体したようなものです。この組み合わせ具合が絶妙で、Tracは様々なソフトウェア開発現場で使われています。有名なところでは、Ruby on Railsの開発にも使われています。 しかし、ウノウではBTSに影舞を使っています。何故かというと、標準ではTracのワークフローは次のようになっていて、testingのステータスがないからです。 最近は、ベータ・クオリティでもいいから、とにかく早くサービスを公開することが重要だという考え方が一般的になってきています。しかし、バグだらけのシステム
ウノウラボ Unoh Labs: 共同開発を効率よく行う方法
尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット
ウノウラボ Unoh Labs: バグの状態でプロジェクトの状態を知る
こんにちは！やまもと＠テスト番長です。 以前バグのステータスというのを書いたのですが、その最後の方で続きがあるようなことを申したら、気になるから教えろという奇特な方がいらっしゃいましたので今回は続きを書いてみましょう。 BTSはバグを管理するだけの道具ではありません。バグを追いながら適切に記録をつけて統計を取ることで、プロジェクトやチームの状態を知ることが出来ます。例えば、以下のような事象です。（なお、WEBアプリが前提） ・バグの報告数が増えず、結果がVERIFIEDになることが多い。 →まだデバッグが始まったばかりのプロダクトか、慎重過ぎるテスターがアサインされています。 ・バグの報告数が少なくなり、VERIFIED以外の結果が目立つ。 →デバッグは最終段階を迎えています。もしもまだ納期前ならば、それなりに上手く行ったプロジェクトでしょう。 ・NEWが発生してからRESOLVEDに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
