プロダクトの評価のためのテスト作ってほしいものがどんなものかって、動いてるものを見るまでは分からなかったりするし、こういうのを作って欲しい!ってのが頭の中にあったとしても、それをプログラマーに理解してもらえるように伝えるのって難しい。ソフトウェアを実際に見て「どう改善していけばいいかを知る」ことをゴールにしてレビューをする。新たな要望やテストや例をチームにフィードバックしていく。testがグリーンだとしても、ビジネス側の人が本当に欲しいものであるとは限らない。ビジネス側の人は機能を見落としてたり、例が正しくなかったりしてチームが間違えて受け取ってしまってる場合があるよね。いうことでQ3,4の出番。Q3のテストでは、ソフトウェアを実際に動かして、ちゃんと思ったとおりのものができているか、競合に対抗できるか、というビジネス視点のテストを実施する。testsは、実際のユーザーが使うようにソフトを使うのでマニュアルテストになる。感覚と頭と直感を活用してプロダクトを評価する。Testingは顧客やユーザーが実際に動かしてみるテスト。testingは使いやすさのテスト。testingがこの象限の中心となるテスト。Product)パフォーマンス、ロード、セキュリティのテストとかだね。ツール使ってやることが多い。www.informit.comもうこれは図に書いてある通りで。(1)はてなブログをはじめよう!bufferingsさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。