blogこの広告は、90日以上更新していないブログに表示しています。去年は2日間参加したけど、今年は初日の30日のみだけど、チュートリアルを受講してみました(会社の金で)。それも含めて、個人的なメモを残しておきます(あくまで、僕視点のまとめです)。2008」、幅広すぎ。不具合の原因となるのは、コーディングだけじゃない要件定義、設計、ドキュメントなどでも不具合は混入するむしろ、高級言語のプロジェクトほど、コーディング以外に起因する不具合が多いたとえば、Y2K問題では、年が2桁で定義されていること自体が仕様バグ。Jones氏のチュートリアル。内容はけっこう基調講演ともかぶる部分もあって、それは残念。基調講演の最後で、「これからの課題」みたいな項目に「自動テスト」とか「アジャイルプロジェクトのデータ」とか、個人的にキーワードになりそうなところが入ってて、へこーッとなりました。全体的にウォーターフォールモデルを前提とした話のようで、そのあたりはかなりビミョウ。チュートリアルの終わりで、質問者が「たとえばユニットテストのテストケース内容を修正して再度テストを実施した場合、それぞれでひとつのテストステージとカウントするのか、それとも合わせてひとつなのか?」といった質問をしたら、「なぜ同じテストを繰り返すのか理解できない」といったようなことを言っていたので、完全にウォーターフォール脳のような印象を受けました。(単純に、質問を誤解していたのかもしれませんが。)あと、テスト以外の、インスペクションやレビューでの不具合検出率をはかるためには、そこで見つかった不具合を個別に記録しなければいけないけれど、そのコストがけっこう高そう。テストによるバグの検出率は今のうちのサイクルでも算出できるはず。あとは、本番バグの原因分析(仕様バグなのか、テストでの見落としなのかなど)や、メジャーリリース後のバグFixリリースでどういった項目を今まで対応してきたのかの確認などは、もうちょっとちゃんとやろうと思いました。残りの時間は、D4の小セッション3つを聞く。仕様書から、機能的なカットだけでHAYST法のテストケース作るのではなく、マインドマップを使って顧客視点を盛り込むと、リスクも捉えた充実したテストケースが組めるよ、という話。顧客視点で見たときに現れる内容は暗黙知であり、経験であるが、マインドマップの各枝を知識ベースとして蓄積することで共有できる。それによって、これまでは障害として報告されてはじめて分かっていたことが、予測的にケースとして捉えることができるようになる。いうような内容と理解しました。HAYST法でテスト作ったことがないのでアレですが、今後、機能によっては参考にするといい部分があるかも。テスト完了判断に使うのは微妙。テスト観点(テストの種類)ごとにテスト件数と検出されるバグ数の見積もりをたてておいて、実際に検出されるバグ数とつき合わせてフェーズごとに見ていくとより精度の高い曲線を得られるよ、という話。うちも今は、実装する項目×平均検出バグ数という大雑把なかたちでしか見積もりたてていないので、このあたりの精度を上げることを考えるときに参考になるかも。少なくとも、実際に見つかったバグが、意図したタイミングに、意図したテストで出たものなのかどうか?という点はもう少し注意してみていくべきかと思いました。「不具合に関する知識の抽出に関する研究」バグの分析をする際、間違ったナレッジを抽出してしまわないようにしたい。そのため、誤解を招くような仕様や設計はアフォーダンスの観点から悪設計だとして、適切な原因分析のレベルに到達できるようにするべき、といった話。理解できた気がしていません。プレゼンで紹介されていた例だと、「すでにメニューが表示されているときだけ、メニューボタンを押したときはメニューを表示するのではなく、メイン画面を表示する」こと、開発の際に間違いやすい(常にメニュー画面を表示するように作ってしまう)、といったことを言っていたが、この例だと、ユーザー視点からの仕様として求められているのでは?といった疑問を持ったので、いまいち納得感がありませんでした。書籍「実践アジャイルテスト」について、実際に読んだのはだい...2009-10-24楽天テクノロジーカンファレンス2009行ってきました。日本Seleniumユーザーコミュニティ勉強会」参加メモ第8回Jenkins勉強会に参加してみたのでメモ月別アーカイブはてなブログをはじめよう!somatさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。