FC2ブログ

クリプキクローネ日記帳

ある種の音楽と数学とランニングはミニマルなところが似ていると思う。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

ソフトウェアテスト293の鉄則 [Cem Kaner, 他 (著)]

鉄則が293個もあって大変でしたが、
結局のところテストに王道なしということがわかりました。



ざっと読み返して気になったのをいくつか。

明文化されていない仕様がある前提でテストせよ。
これは現実的な意見。
仕様書に書けることは書くべきだし、記載漏れの言い訳にしてはいけないけど、
一方で「完璧な仕様書はすなわちソースコードである」という言葉もあるとおり、
100%漏れなく完璧に振る舞いを記述するのはムリなので、仕様書だけに基づいてテストしてはいけない。

テストのコンセプトと直接関係ない特定の数字を書くべきではない。
これは意外。
テスターがその数字に特別な意味があると誤解するため、っていう理由とのこと。
テスト手順の書き方は
「誰がテストを実施しても同じテストになるように、また、後から読んで何をやったか正確に分かるように、
テスト手順は出来る限り具体的に書け」というのがセオリーだと思っていたので意外。
どちらも正しい。

障害レポートをテスターの評価やプログラマの評価に使ってはいけない。
確かに。
考えたことなかったけど。

手動テストと自動テストを同格に扱うな。
今まで手動でやっていたテストを全て自動化しようという試みは誤り。
巷でよく言うような、「自動テストのテストケース1000件は手動でやっていたら何ヶ月もかかるから
自動化することによってテストを効率化しました」、みたいな発想もおかしい。
これは常々思っていたので明確に書いてあってほっとしました。

自動化によって埋もれてしまうバグもある。
これはあるなー。
「なんかちょっと変な気がする」みたいな人間の感覚は大事。

テスト記録の再生は思うようには機能してくれない。
GUIの操作を記録して再生するツールを使うと、
レイアウトが変わったときにそのテストが使い物にならなくなる。
これもあるある。

テストの自動化はソフトウェア開発そのものである。
まさに!

反復コードを避けるためだけにテストライブラリを構築するな。
管理できなくなるから、とのこと。賛成。
「テストの自動化は必然的に多くの反復処理を有している。」
テスト側でもモジュール化とかやりだすと何をテストしてるのか分からなくなると思う。

テストの自動化計画はプロジェクトの早い段階で立てる。
まさに!

プログラマの考え方を理解せよ。
「テストから得られたシステムの全体像はシステムを作るプログラマにとっても役に立つに違いない」
まさに。
開発者は視野狭くなりがち。
あと、
「バグを報告したときに「そんなバグは起こりえない」というのは、自分が絶対に正しいという意味ではない。
報告されたバグは、自分が正しいと思っている論理とは合致しないということを言っているのである」
まさに(笑)。

バグ総数によるプロジェクト進捗測定はするな。
「しろ」っていう世の中かなと思ってたけど。

プロジェクトの終盤に初心者を投入するな。
人月の神話来た(笑)。

というわけで鉄則がたくさんでした。
  1. 2018/01/06(土) 01:19:36|
  2. | トラックバック:0
  3. | コメント:0
<<3分間ネットワーク基礎講座 [網野衛二(著)] | ホーム | ソフトウェアプロジェクトの救済入門 [E.M.Bennatan(著), 富野壽,‎ 荒木貞雄(訳)]>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/392-d110653c
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。