Author Archives: KazuCocoa

最後間で読み切りました。ので、最後を少し。 最後はよく聞くプラクティスなので、なるほどくらいで終わる方も多いかと思いました。 ひとまずAgile More Testingも呼んだので別の本を読もう。 Agile Testing in Practive 最後のこの章では、Agile Testingのいくつかのプラクティスを書いていました。 Chapter 24. Visualize Your Testing Communicating the Importance of Testing 　　　　- かんばんを使ったテストタスクの管理を書いています。目的は進捗を把握することなので、登山のように縦方向にかんばんを管理しているものもありました。 Visualize for Continuous Improvement Vivibility into Tests and Test Results 中には、テスターは良いテストケースを用意するためにプログラマーとアナリスト両方の経験が必要とかいていました。More

ここまでで約60%超えるくらいなのですが、Appendexなど覗くと後少しで読了。実際の経験にそっていることが多かったので、比較的頭に入ってきました。 いくつか役立つことや、考えが整理できること、同じ経験を積んでることを学べたことは個人的に良い収穫でした。 ここに直接関係するわけではないですが、Turnipのようなテスト記述の勉強会したいな。時間見つけよう。 Part6: Test Automation Agile Testingでは、テスト自動化は必須な武器です。そのため、テスト自動化に関してもある程度の幅をとって記述されていました。 Technical debt, Pyramids of Automation, Test Automation Design Pattern and Approaches, Selecting Test Automation Solutionsという構成で記載されています。 Chapter 14: Technical Debt in Testing 技術的負債はテスト自動化や他のテスト活動において、チームの速度を落とさないようにする必要があります。技術的負債を把握して様々な活動へ落とし込むために、見える化はやはり大事だと言います。 ストーリーに対する見積もりにおいて、タスクカードによりデバグ作業や自動化にかかるメンテナンスも可視化する 作り込まれた不具合やブロックされたストーリーは、素早く集中して修正する コードとテスト双方に対してチームは責任を持つ 技術的負債の課題を定め、負債を減らすようにトライする 異なる専門家を集めて、全体として負債を減らすMore

だいぶ進んできましたが、全般的に現在の考えを後押ししたり、参考になるものが多い印象です。もう少し頑張ろう。 Part 5: Investigative Testing ここでは、様々な事象をより深堀りしていくためのTestingの側面の話しをしています。ほぼ、Exploratoty Testingの話しをしています。 Chapter 12. Exploratory Testing Exploratory tester達は、事前に定義されるテストセッションには参加しません。そのかわり、経験的に、人間的に、神のような形で期待される予測と比較しながらテストを進めます。それらの差はわかりにくいですが、非常に有意義なものと書いていました。 例えば、James Lyndsay氏はScript testingとExploratory testingを比較していたり、Bad customerを演じる形のExploratory Testingでその有意義さを示しています。 Bad customerとは、 invalid parts of imputs – characters, values, combinations Time changes Unusual uses Too much – long string, large, nnumbers, many instances stop halfway/jump in halfway wrong assumptions making lots of mistales, compounding mistakes using…More