品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
テストにおけるデザインパターン - 現場のためのソフトウェア開発プロセス - たかのり日記
そういえば、今日のJaSSTのパネルディスカッション（ディスカッションの内容は、「テスト技法からテストメソドロジへの進化を目指して」）で、西 康晴 先生が、「テストでもデザインパターンみたいなものがあると良い」という旨の話をしていたのですが、これはその通りだと思います。 設計においては、設計技法だけでなく、「GoFのデザインパターン」「PofEAA」といった、パターンが多く存在します。パターン自体が重要ではないとは思うのですが、パターンはベストプラクティスであり、それを適切に利用することができれば、設計品質も向上するでしょう。 テストについては、いろいろな技法はありますが、設計におけるパターンのようなものがない。私が知っているものは、「xUnit Test patterns」ぐらい。 「同値分割」「境界値」といった基本的な技法を使っている人は多いと思いますが、「直交表」「デシジョンテーブル
Tracチケットのテンプレートを管理するTicketExtPlugin - 現場のためのソフトウェア開発プロセス - たかのり日記
Tracでは、要件やバグ、タスクなどといったチケットの分類を定義することができます。そのような分類を分ける場合、分類毎にチケットの内容を定義できると便利です。 例えば、Tracではカスタムフィールドを定義することが可能ですが、要件やバグの分類でそれぞれ利用するフィールドを変えたり、説明のフィールドに記述する内容を変えたりといったことです。 しかしながら、Tracではそのような指定ができません。 チケットの分類は指定できるのですが、チケットの内容は1パターンだけであり、利用しにくいところ。 そこで、Tracのプラグインを作成し、TracHacksに登録しました。 TicketExtPlugin このプラグインでは、以下のことが可能です。 チケット分類に応じて、説明フィールドにテンプレートを適用 チケット分類に応じて、カスタムフィールドの有効／無効を設定 WebAdminから、テンプレート定義
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
