maemukiのブックマーク - はてなブックマーク

maemuki id:maemuki

ブックマーク / labs.unoh.net (4)

ウノウラボ Unoh Labs: 見ないと損するソフトウェアテスト関連サイト色々
こんにちは！やまもと＠テスト番長です。今回は自分が普段チェックしている、ソフトウェアテスト系のサイトを色々ご紹介してみようと思います。既にご存知のサイトもあるかと思いますが、宜しくお付き合いください。 swtest.jp/wiki http://www.swtest.jp/wiki/index.php?swtest.jp/wiki 最近wiki化され、情報更新が活発になっています。必見です。 StickyMinds.com http://www.stickyminds.com/ コラムなどの読み物が充実しています。 Google Testing Blog http://googletesting.blogspot.com/ グーグルのテストチームのブログです。面白くないはずがありません。 Open source software testing tools http://www.
maemuki 2008/09/10
QA
リンク
ウノウラボ Unoh Labs: イマドキのベンチャーがテストにかけるコスト
こんにちは！　やまもと＠テスト番長です。今回はテストにかけるコストのお話をしましょう。コストといっても色々ですが、例えば時間。果たしてどれくらいの時間をかけるのがいいでしょうか？有名な「人月の神話」の中に、こんな指標が出てきます。 [ 設計1/3 コーディング1/6 単体テスト1/4 システムテスト1/4 ] 実に工程の1/2がテストに充てられています。実際バグをほぼ完全に消すにはこれくらいの時間が必要です。70年代のメインフレーム中心の時代であることも考慮すれば、かなりうなずける数字だと思います。ただし、著者のブルックスが後に言っているようにこれはウォーターフォールモデルでの指標です。現代流のXPやV字モデルとなると話は違ってきますね。その場合コーディングが反復する度に、テストも反復されるはずです。そうすると話は複雑になってきます。更にイマドキのベンチャーの場合ですと、
maemuki 2006/08/30
QA
リンク
ウノウラボ Unoh Labs: バグの状態でプロジェクトの状態を知る
こんにちは！やまもと＠テスト番長です。以前バグのステータスというのを書いたのですが、その最後の方で続きがあるようなことを申したら、気になるから教えろという奇特な方がいらっしゃいましたので今回は続きを書いてみましょう。 BTSはバグを管理するだけの道具ではありません。バグを追いながら適切に記録をつけて統計を取ることで、プロジェクトやチームの状態を知ることが出来ます。例えば、以下のような事象です。︵なお、WEBアプリが前提︶・バグの報告数が増えず、結果がVERIFIEDになることが多い。 →まだデバッグが始まったばかりのプロダクトか、慎重過ぎるテスターがアサインされています。・バグの報告数が少なくなり、VERIFIED以外の結果が目立つ。 →デバッグは最終段階を迎えています。もしもまだ納期前ならば、それなりに上手く行ったプロジェクトでしょう。・NEWが発生してからRESOLVEDに
maemuki 2006/08/30
QA
リンク
ウノウラボ Unoh Labs: 「２流のテスター」は要らない！(1)
こんにちは！　やまもと＠テスト番長です。 Johanna Rothmanさんというコンサルティング・サービスの会社をやっていらっしゃる方がいるのですが、　No More Second Class Testers!　という面白いコラムを書かれているので、ご紹介しましょう。﹁私達の開発者は世界レベルだけれど、テスターは2流だ﹂私はこういう台詞を聞くのは嫌いである。大体においてそれはテスターの落ち度ではない。～～～開発工程にテスターを参加させずに、不具合探しだけやらせるのではあなたはテスターの働きの恩恵を十分に引き出しているとは言えません。序文はこんな感じ。そしてこんなチェックリストが書いてあります。あなたのテスターは2流ですか？
maemuki 2006/08/30
QA
リンク
1