職場で出会った悲しいテスト仕様書たち｜書き方の反面教師 - Pepsinogen.Blog
ソフトウェアの品質を上げるためにはテスト仕様書の品質が大事です。糞みたいなテスト仕様書だと、多くの不具合を見逃してユーザーに供給されてしまうことになります。どんな天才プログラマーを集めても、テストが糞だと完成品も糞になってしまいます。というわけで、今回は職場で遭遇した悲しいテスト仕様書たちを集めてみました。多くの人が触ったことがあるであろうWindowsのペイントソフトのテスト仕様書を作る場合で考えてみます。 悲しくて残念なテストたち 人によってテスト結果が変わってしまう 基本中の基本です。上図のテスト仕様書はNo.2がダメですね。この仕様書だと人によって結果が変わってしまいます。鉛筆で1本の線を描くだけの人もいれば、たくさん線を書いて塗りつぶす人もいます。また、色を変えて赤で描く人もいれば、太い線を選択して線を描く人もいます。もし、黄色を選択したときに問題が発生する場合、上図のテストでは
継続的システムテスト - Test Automation
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。 【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 from Kotaro Ogino ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。 背景：開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
