だいぶ進んできましたが、全般的に現在の考えを後押ししたり、参考になるものが多い印象です。もう少し頑張ろう。
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 the same information for different entities
- triggering error messages
- going too fast
などを行うユーザをさしたりします。これらの操作は、Test Heuristics Cheet Sheetなんかが始点として良い例とも述べていました。
Creating test charters
テストチャーターを作成する参考技法として以下の2つがあげられています。
Explore it!を書いたHendricksen氏はチャーターを考えるときのテンプレートとして以下をあげています。
- Explore …
- With …
- To discover …
About Session and Chartersの例の中にも、以下のようにリスクを掘り下げるために使っているチャーターの例をあげていました。
- Test under
- Test with tablets
- Test for failures with
- Test multi-user and race conditions with
- Additional exploratory penetration testing for the new web front end as a system
- Customers see but we are unable to reproduce the problem; can you troubleshoot ?
Generating test chater ideas
テストチャーターを作成するためのアイデアとしていくつか提案がありました。
- ペルソナを知り、ペルソナとして操作して探索する
- 一連の流れのなかで探索していく
など。
Managing Test Charters
ここでは、SBTM、TBTMの説明と、それらにおけるチャーターの管理に焦点をあてて書いていました。
たとえば、SBTMでは
- 製品のリスクのリストを作る
- ホワイトボードなどに載せる
- リスクを参考にソートする。優先度の考慮も。
- かんばんに載せる
- 修正などすすめる
- カードを並べたり、新しいカードを追加する
- 実施時間を終えたらテストをやめる。既知の不具合、テストされていないリスクからリリースを判断する
Adventures in Session-Based Testingなんかもあるそうです。
TBTMは、SBTMよりより厳密なtime-boxingを管理してテストを進めるようです。ここの例ではマインドマップでテスト計画を構築し、実行したものが書かれていました。また、リスクやissueをFractal representationを使っているところも。
Exploring in Groups
探索は個人の活動だとよく言われますが、ここではグループとして探索することに対する価値を書いています。例えば、プログラマー、テスター、BAの3人一組でテストを実施していくことで、素早いフィードバックと合わせながら開発を行うTrinity Testingなんかも書いています。
Recording Results for Exploratory Test Sessions
探索的テストのセッションに対する結果をどのように残すかを書いています。Wikiだったり、スプレッドシート、qTest Platformを使ったやり方を書いています。
私も普段はGHEのissueベースでの進め方であったり、Wikiベースであったり、そのくらいの軽さで書いています。
Where Exploratory Testing Fits into Agile Testing
以降では、それぞれのテストレベルに応じたexploratory testingに役立つテストタイプを書いています。
- Product release level
- 依存関係を伴い、高いリスクのワークフローを探索することに焦点を当てます
- feature
- Doneとなった機能毎に進めます
- stories
- より細かな機能のissue、異なるバリエーションを考えていきます
- tasks
- プログラマとテスターがペアとなって行うような開発の粒度で考えます
ここの粒度もなるほどと納得できそう。
今の職場では、全部に対してある程度絡んでいるし、実施しているし、徐々に良い方向に進んでいそう。
Chapter 13. Other Types of Testing
著者らの過去のXP/agileチームは、機能的なテストに焦点を当てすぎたそうです。その経験からより多くのテストが必要であることを述べています。また、このチャプターではスコープを広げて様々なテストタイプに関して言及しています。
- Concurrency Testing
- Internationalization and Localization
- Regression Testing Challenges
- User Acceptance Testing
- A/B Testing
- User Experience Testing
サービス/製品が若い間は確かに機能的なものに焦点を当てるで十分なことが多いです。一方、サービスが成長したり製品が大きくなると機能的なものだけでは足りなくなります。そのような流れを鑑みると、徐々に広い視野を持って必要な要素を増やしていくことは、正しく成長しているように見えますね。
~ my tech diary ~ 