10/28/2009

How to measure tester's performance

I found some interesting articles from Software QA forum (It is really useful).

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=6838
http://blogs.msdn.com/larryosterman/archive/2004/04/20/116998.aspx
http://www.sqablogs.com/jstrazzere/267/Misuse+and+Abuse+of+Bug+Counts.html

Every articles mentioned that using bug count as a metrics is risky. But people (especially upper management) tends to use bug count to measure performance of testers. We need to consider what is the purpose of our testing job. Testing is required to release the high quality product for our customers. Bug count tells nothing to customers.
We may need a concrete metrics to measure our performance, but I'm sure bug count is not that metrics.

11/05/2007

HAYST method - Orthogonal Array


直交表に関する入門の本です。直交表はまったくわかりませんでしたが、これを読んで概要がつかめました。
概要がつかめたのですが、実際に使うのはなかなか難しいなあと思いました。直交表の肝は因子と水準をいかに見つけ出す (洗い出す) かにつきると思います。

This book is about how to apply orthogonal array to software testing, named HAYST method. HAYST method gives flexibility to orthogonal array approach. However, the most difficult thing to use this approach is to figure out every factors and levels before you plan your tests. If you can list up all factors and levels of your product, I believe this approach is effective.

7/25/2007

Globalization

Red Herring が京都でカンファレンスを開いているそうです。日本に必要なのは国際化 という記事を見つけました。日本に足りない 3 点について語られていますが、いずれも「国際化」の一言です。
英語については痛いですが、昨今のグローバル化の波にのりおくれないためにもがんばろうと思いました。中国、台湾、タイのエンジニアの知り合いは、技術書が翻訳されないことが多いので、直接英語の本を読んで情報を仕入れています。日本語訳をまっていると、彼らとのスピードの差もついてしまいます。

Blogger にブログしていると、まちがえて外国の人もたまに来るので練習がてらつたない英語でも書いてみます。

Read Herring held a conference in Kyoto. I found an article about the conference; it mentioned that Globalization is required for Japanese companies. Japanese companies are likely to do their business within Japan. There are 3 suggestions from the conference, all of them are about globalization. One of them is that Japanese have to use English. We cannot survive globalized world without using English. I know some engineers working in China, Taiwan and Thailand. Many techinical books won't be translated into their languages. So they always try to lean new technologies in English. It means they can learn the new technologies directly. On the other hand, most of all major technical books have been translated into Japanese and we are expecting it. I suppose these Asian engineers can catch up new technologies much faster than people who is waiting for translated books.

5/10/2007

米国企業と日本企業のテスト

私は米国企業と日本企業を行ったり来たりしています。アメリカと日本ではすこし視点が違うのかなと思うときがあります。一概には言えないと思いますが、あくまで私の私感です。

日本企業では、テストはカバレッジを中心にすべての場合を網羅するように行われます。リリースまでにすべての不具合を見つける事を目標としているように思います。サービスの仕事が中心という事も理由のひとつと思われます。
米国企業では、どちらかというとユーザーが使用する手順を中心にテストが行われます。バグはゼロにはならないという概念が根底にあるように思われます。バグを発見しても発生頻度が低い、ユーザーが通常使用しないケースのバグは次のリリースに持ち越される場合が多くなります。ユーザーから問題が報告されたときの対応は早いです。アフターケアーがよければお客様は満足していただけるようです。

4/21/2007

Google Testing Blog より: WW Test Engineering

Google Testing Blog に Test Engineering around the worldという記事が掲載されています。

Google はなぜ World Wide にテストチームを展開しているのか知りたいところです。プログラマからすればすぐ隣にテストエンジニアがいた方が仕事は楽だと思います。そこをあえて世界中に分散させているのはなにか訳があるのだと思います。

勝手に推測してみました。
  1. Google のお客様は世界中にいるので、世界中の拠点でテストしておのおのの文化からみたフィードバックを期待している。
  2. シリコンバレーだけではテストエンジニアを十分に雇う事が出来ない
  3. 24 時間テストを実行したい (時差があるので世界を一周するまで 24 時間テストできます)
  4. 開発もバーチャルに世界中に分散して行われているので、同様にテストも分散して行われている (かなり憶測です)
などがあげられると思います。

すでにスイスの拠点の紹介記事が掲載されています。これによると、スイスで開発しているサービスのテストもしているようですが、Google Mpas のように別のオフィスで開発しているソフトもスイスでテストしているようです。


もっとも住みやすい都市チューリッヒテストエンジニアを募集しているようですよ。

4/11/2007

テストオートメーション (自動化)

テストのオートメーション (自動化) はどの程度可能なのでしょうか?

私は、通常テスターが実行しているテストを自動化するのに反対で す。人間の感覚やカンにはなかなか鋭い物があり、コンピュータでは見つけきれない問題や課題もたくさんあります。また、ソフトウェアは最後はお客様 (人間) が使用するものですから、人間が操作したときにどうなるか確認しないといけないと思っています。また、自動テストの開発工数や、機能仕様が変わった時などのメンテナンスを考えるとすべてのテストを自動化する事はできません。

しかし、いくつかの分野では自動化が有効なことも事実です。
テストの自動化を実装するには、人間が同じテストを実行する工数の 10 〜 40 倍かかるとも言われています。よって、同じテストスクリプトを数十回実行するようなテストは自動化にむいています。
た とえば、ビルドごとに行うビルド受入れテストなどは自動化の対象となります。最近のソフトウェア開発では毎日ビルドをするのが 普通です。ビルド受入れテストはあまり時間がかからないとはいえ毎日同じ作業を繰り返すので、テスターのモチベーションも下がってしまいます。このような 作業は自動化した方が良いと思います。

逆に人間ではできないような作業も自動化します。たとえば、ストレステストやパフォーマンステストなどです。数十の同時アクセスを実現したり、ファイルを大量に送受信したりするなど人の手ではできない作業を自動化します。

テ スターが行うテストとは異なりますが、デベロッパーが行う単体テストも最近は自動化が進んでいます。単体テストはプログラムの一部分だけをテストするた め、テスターがテストをするほどのインターフェイスがありません。ですので、単体テスト用のテストプログラムが必要です。単体テストのフレームワークとし ては Junit などが有名です。

4/01/2007

Google Testing Blog ネタ

Google Testing Blog より: Robot testers invade Portland
コメントの中にプレゼンテーションへのリンクがあるのでダウンロードできます。

やはりオートメーションも少しはしないとかなあという気になりました。

興味深いのが:
Some testers get so involved in creating robots that they forget to test: Don’t fall in love with your robot!
たまにありますね。テストツールはテストをしている人が必要なものを作るのが良いと思いますが、テストを忘れてしまってはいけません。

Web アプリ専門ですが、Watir というツールも面白そうですね。(私はマカーなので動きませんが。。。)

3/13/2007

顧客満足度

顧客満足度はいくつかの観点に分割できると思っています。ひとつは、お客様が製品をいかに好きかという観点、もうひとつは、お客様がいかに製品をつかってくださっているかという観点です。勝手に、前者をポジティブ満足度、後者をネガティブ満足度と呼びます。ポジティブ満足度は、お客様が次の製品を買ってくれるか、他のお客様に薦めるかなど、満足度は加算される一方です。逆にネガティブ満足度は、買っていただいた製品が要望に合わなかった場合や、品質が悪くなかなか運用できないなど、満足度を減点する方向に働きます。ネガティブ満足度は常に 0 以下の値になります。
よって、トータルの顧客満足度は:
顧客満足度 = ポジティブ満足度 (正数) + ネガティブ満足度 (負数)
という計算式がなりたっている気がします。

ポジティブ満足度を加算していくのは、ブランディングや製品企画などプロダクトマネージメントの仕事です。ネガティブ満足度を上げる (減点しない) のは QA の仕事です。ネガティブ満足度は 0 以上になりません。しかし、製品に問題があるとどんどん減点されていきます。いくら魅力的な製品でも、ネガティブ満足度が大幅なマイナスでは、顧客満足度は下がる一方です。QA の仕事では、運用中に問題を発生させない、また、期待されるであろう機能、性能が実装されていることをきちんと確認しないと、0 点はもらえません。地道な努力ですが、トータルでの顧客満足度を上げるためにも、QA/テストは重要な役割をになっていると思います。

3/08/2007

テスト工数について

テスト工数の見積もりはどのようにやってますか?
まだ出来ていないソフトウェアの開発 (コーディング) 工数ですら見積もりが難しいのに、さらにそのテストの工数なんてと思います。実際には、過去の統計に基づいて見積もるのが精一杯だと思います。
ただ、テスト作業には「予期しない問題を見つける」という側面があります。テストをしていると予期しない問題を発見するのです。予期できないことは見積れませんから、テスト工数の見積もりはあまり意味をなさないというのが私の持論です。ただ、それではプロジェクトの計画が立てられませんから、計画時には問題を発見しない前提でのテスト工数を過去の統計から見積もります。問題が発生した場合に、逐次プロジェクトと相談して問題の修正、再テスト工数を見直します。問題の規模や優先度によっては、リリース日が延びることもあります。
サービスの案件では、お客様のサービスインの日が決まっていたりするので、この方法は使えないかもしれません。

2/28/2007

欠員

またしばらく体調をくずしていました。みなさんもお体はお大事に。

都合がいいので、体調をネタにします。病気や退職など予定していたテスターが仕事ができなくなってしまうことは多々あります。このような場合、予定していたテストにどう対応すればよいのでしょうか?
これは、プロジェクトマネジメントの手法ですが、プロジェクト計画時に病気など突然の欠員をリスクとして認識しておきます。また、プロジェクトの進捗中も、そのリスクの発生する確率と、発生した場合のインパクト、それと発生してしまった場合の回避方法を常に考えておきます。以前のプロジェクトでは、毎週のプロジェクトミーティングの時に関係者でリスクのレビューをしていました。
結局、病気やけがなどは発生する確率を予測することは不可能ですから、回避方法を十分考えておく必要があります。そのときには次のような回避方法を考えていました。
  • のこりのテスターで作業を分散する
  • コーディングの終わったプログラマにテストしてもらう
  • 外注先のテスターを増員してもらう
(結局はだれか代わりの人をお願いするアイデアしかありませんでした。。。)
いずれにせよ、事前にリスクとして認識しておく事で、関係者にそれなりの心構えができます。心構えがあるので、突然の事態になるべくスムーズに対応することができるとおもいます。