1,800円以上の注文で送料無料

テストプロセス改善 の商品レビュー

4.2

5件のお客様レビュー

  1. 5つ

    2

  2. 4つ

    2

  3. 3つ

    1

  4. 2つ

    0

  5. 1つ

    0

レビューを投稿

2019/02/07

テストプロセス改善モデルの一つ、TPI(Test Process Improvement)の訳書です。 ま現在はこのモデルを発展させたTPI NEXTの訳書もリリースされており、これから新しくアセスメントモデル型のテストプロセス改善をやりたい、学びたいという方は、そちらにあたっ...

テストプロセス改善モデルの一つ、TPI(Test Process Improvement)の訳書です。 ま現在はこのモデルを発展させたTPI NEXTの訳書もリリースされており、これから新しくアセスメントモデル型のテストプロセス改善をやりたい、学びたいという方は、そちらにあたったほうが良いかもしれません。 しかし、シーケンシャルな開発モデル(V字やWモデル)を採用している現場であれば、いまでも様々な示唆を得られると思います。逆に言えば、短期間で開発を繰り返すような反復型開発やアジャイル開発といった文脈には合わないよう感じます。 なお、訳書の宿命として、どうしても日本語にすることによって本来の意味がとりがたくなってしまいがちなため、英語版の書籍も合わせて手元に置いておくと、より理解しやすいと思います。 また、TPIはアセスメントモデルですが、TMapをリファレンスプロセスとしています。この書籍の中だけでは理解が難しいことも、TMapの書籍(こちらは訳書は出版されていません。TPIの付録Aに概要が説明されています)を見ることで、なるほど!と思うことも多いため、こちらの書籍も手元においておくとさらに理解が深まります。

Posted byブクログ

2013/05/16

もう15年くらい前に提案された『テストプロセス改善』モデルであるTPIについて書かれた技術書。 このTPIですが、あまり知名度はないですよね。ソフトウェア品質の仕事に携わっている人くらいしか知らないのではないでしょうか? でも、よく考えられているモデルです。今回、諸事情にて手...

もう15年くらい前に提案された『テストプロセス改善』モデルであるTPIについて書かれた技術書。 このTPIですが、あまり知名度はないですよね。ソフトウェア品質の仕事に携わっている人くらいしか知らないのではないでしょうか? でも、よく考えられているモデルです。今回、諸事情にて手に取ることになって、試してみたのですが、テストプロセスについて色々気づくことがありました。 惜しむらくは、改善を謳っている割に、改善案がプア(っていうか、改善案は自分で考えてねというスタンス)。 あとは、オランダ生まれなので、自分の担当する開発プロジェクトに照らし合わせての読み替えが大変ですね。 それらさえ乗り越えられれば、とても有効なモデルだと思います。

Posted byブクログ

2012/05/01

TPIモデルを使ったテストプロセス改善について書かれています。 私は、SW-TMMよりTPIの方が私は導入しやすいし効果が出ると思っています。 でも、実際使ってみるとレベルの定義が曖昧なんですよねぇ。TPIって。 その時は、確か『体系的ソフトウェアテスト入門』を使って自己...

TPIモデルを使ったテストプロセス改善について書かれています。 私は、SW-TMMよりTPIの方が私は導入しやすいし効果が出ると思っています。 でも、実際使ってみるとレベルの定義が曖昧なんですよねぇ。TPIって。 その時は、確か『体系的ソフトウェアテスト入門』を使って自己アセスメントしてみたのですが、何とでも付けられるという感じでした。ただ、それなりに部門長には受けたしそのおかげで改善のための予算と人が付いたので、まぁ、結果よかったのですが継続してTPIを使って組織評価することはできていません。 今回、TPIに特化した本を読んだわけですが、曖昧さについては、やはり同じでした(まぁ、同じものであるから当然なのですが)。 でも、改善のポイントとか何点か参考になることもあったので、一度目を通しておいても損はないと思います。

Posted byブクログ

2012/01/12

テストのHow-Toについて書いた本は多いが、正面からテストプロセスについて書いた貴重な本です。決して読みやすくはありませんが、内容はよくまとめられていると思います。

Posted byブクログ

2011/12/12
  • ネタバレ

※このレビューにはネタバレを含みます

試験は計画的にやらないと破綻することがあります。 開発よりも、計画が立てやすく、開発のお尻を叩いて、開発段階(フェーズ)ごとに必ず試験をする習慣を身につけてもらうことが大切だと思います。 単なるレビュー(見直し)だけで済ませるのではなく、ありとあらゆるレビューには、なんらかの試験結果をつける習慣が身につくとよいかもしれません。 試験といっても、プログラミング言語によるプログラムを書いた試験、簡単なスクリプト言語による試験(チェック)、形式手法を用いた論理的試験(検証)、試験ツールを用いた試験など、さまざまな道具を使いこなすとよいと思います。 そういう作業をする上での一つの枠組みを示していると思われます。 事業体制(プロジェクト体制)が異なる組織で、異なる開発環境で、異なる開発対象を、異なる期間で、異なる人員で作業している場合、作業手順は全く異なり、用語もかなり異なるように思います。ある特定の開発環境、開発対象、開発期間、開発人員に最適化した用語体系を、他の用語体系に移植するのは並大抵ではないと思います。 それは、日本とアメリカ、日本語と英語という違いだけではないと思います。 CMMも様々な種類が作られ、CMMIになったように、言葉を合わせようとするだけでは、文化の違いが十分反映できないかもしれません。 違うモデルを作ってから飜訳をしはじめるのはどうでしょう。 文化の違いの大きな点として,仕立て(tailoring)と着付け(fitting)があります。そこまで切り込んだ書籍はなかなか見つかりません。

Posted byブクログ