DONE)を顧客と握っているか?→握れてない。現状スタンドアロンアプリのリプレイスなので、基本要件は変わらないけど、アプリ形態が変わるのでその動作などは早期に機能要件確認をとらないと。★テストの4象限でCIできるよ!→単体テスト×やってないGUIテスト○やってる。受け入れテスト△ここはテスト部隊の厳しい人手チェックに頼る。テスト環境へのデプロイ、データ以降、外部I/Fとのデータ連携はある程度自動化)非機能要件テスト×やってない。やらなきゃ!!!★単体テストはやってない→単体(各レイヤごとの)テストは自動化はあきらめている。これはRyuzeeさんもやってないといっていたし、いつか見たt_wadaさんのスライドにも、ある程度粒度の大きいテストがTDDでは有効だとい話もあり、勇気付けられる。GUIのテストは書いている。ここのメンテコストはそれなりにかかるが、頻繁にリファクタしていくときはやはり大きな力となっている。仕様変更にどう対応しやすくするかはいろいろと工夫が必要な感じだが、それも困ったときに一番いい形に変更していきたい。重複テストコードのリファクタ。DBレイアウト変更→テストデータ一括変更ツールなど。→テストケースは日本語名である程度どんなテストをするのかがわかるので、顧客(または顧客に近い立場の人)に網羅性確認してもらうぐらいはすぐにでもできる。AcceptanceTesting入門を解説するよ。顧客と1つのチームになってぐるぐる回すといいものができるヨ。agile的なテストは顧客とのコミュニケーションツールとなる。良いソフトウェアは、顧客とのコミュニケーションとコラボレーションを求める。話し合いなんと昨日講演を聞いたtomohnさんと同じテーブルに。机の上に出された本は何故かtomohnさんのヤンジャンw。印象に残ってるのは、JaSSTのパネルディスカッションでツールベンダの立場で参加した際、「ツールは必要ないです」と話したとのこと。ツールがテストするのではなく、あくまでサポート。チームでテストするのが重要だよねということ。ここでも完了条件というかテストを評価するのはだれかという話がでて、Ryuzeeさんの話と同じく、品証ではなく、チーム、顧客だ、という話に。Webの機能テストをseleniumで書いている人がいたけど、要件が結構変わってテストケースをそのたびに書き直しになるのでとてもメンテナンスコストに合わないとのこと。テストのメンテナンスコストは自分のところでも問題になるところ。コンテキスト毎にどんな対策を採ればいいのかは変わるんだろうけど、対応に当たっての工夫の事例もいろいろ見てみたいな。ちからもOutputできないといけないな。あと自動テストは通っても、見た目あきあらかにありえないようなものがあがってくるのはどうなの?という人が2人もいた。UIテストをしないとこうなる?またテストケース自体に漏れがあるとその後で発覚してしまう。ある程度は仕方ないけど、ペアプロ、レビューなどでテスト側の精度もあげていかないと。DevLOVE、熱くて、いい雰囲気で気付きもあり、とても楽しかった!ありがとうございました。#ああ、もうこんな時間。#そういえば、t_wadaさんがいて、今日たまたまプログラマが知るべき97の・・本を持っていたので思わずサインしてもらった。ありがとうございました。Day「我々は、テストで世界を繋げる。01に参加してきた2/14終日と、2/15の午後、デブサミ2013に行って来ました。VBAテスト勉強会をやってみたあけましておめでとうございます。月別アーカイブはてなブログをはじめよう!masakitkさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。