- Taschenbuch: 162 Seiten
- Verlag: O'Reilly UK Ltd.; Auflage: 1 (8. März 2013)
- Sprache: Englisch
- ISBN-10: 1937785025
- ISBN-13: 978-1937785024
- Größe und/oder Gewicht: 19 x 1,3 x 23,5 cm
- Durchschnittliche Kundenbewertung: 1 Kundenrezension
- Amazon Bestseller-Rang: Nr. 30.960 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing (Englisch) Taschenbuch – 8. März 2013
|Neu ab||Gebraucht ab|
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
""Reading this book taught me new skills and heuristics; but even better, it helped me channel my tester "spidey sense" more creatively and usefully. I keep this book handy at all times and occasionally do one of the practice sessions to keep my awareness keen. Explore It! helps me make sure our customers and our company get real value from our software. It'll help you too.""--Lisa Crispin, Coauthor with Janet Gregory, "Agile Testing: A Practical Guide for Testers and Agile Teams"""
""Explore It! starts with a bang. Elisabeth catches your imagination and has filled the book with practical ideas for exploring everything from your typical GUI scenarios to testing ideas (requirements), and she even includes suggestions for programmers on how to explore low-level code. This book should be on every development team member's desk, not only testers. It is the book I carry with me whenever I introduce exploratory testing to development teams.""--Janet Gregory, Coauthor with Lisa Crispin, "Agile Testing: A Practical Guide for Testers and Agile Teams"
Über den Autor und weitere Mitwirkende
Elisabeth Hendrickson is a tester, developer, and Agile enabler. A seasoned veteran, she wrote her first line of code in 1980, and almost immediately found her first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile Alliance. She is best known for her Google Tech Talk on Agile Testing as well as her wildly popular Test Heuristics Cheatsheet. She splits her time between teaching, speaking, writing, programming, and working on Agile teams that value her obsession with testing.
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Die hilfreichsten Kundenrezensionen auf Amazon.com (beta)
So I was thrilled when Elizabeth asked me to review a pre-publication version of her upcoming book on Exploratory Testing titled "Explore It!" I had read other books on the subject, and was less than thrilled with what I had read, so I was eager to see Elizabeth's treatment of the subject.
I wasn't surprised with the results. In her usual informal writing style, Hendrickson has packed the book with real-world, easy to understand examples sprinkled in. I found it both interesting and fun.
The chapter titles will give you an idea of the topics covered in Explore It!:
- On Testing and Exploration
- Charter Your Explorations
- Observe the Details
- Find Interesting Variations
- Evaluate Results
- Vary Sequences and Interactions
- Explore Entities and Their Relationships
- Discover States and Transitions
- Explore the Ecosystem
- Explore When There Is No User Interface
- Explore an Existing System
- Explore Requirements
- Integrate Exploration Throughout
- Interviewing for Exploratory Testing Skills
- Test Heuristics Cheat Sheet
In each chapter, Ms. Hendrickson encourages you to think, to experiment, and to explore the various aspects of your system-under-test. Then, she provides real-world, practical ideas for how to do just that.
Unless you are the kind of unfortunate tester forced to do nothing but follow a pre-written script, you already perform some exploratory testing.
In "Explore It!", Elisabeth Hendrickson teaches you how to think about Exploratory Testing, and how to make it a regular, planned, and effective part of your testing practice.
This is the kind of book I purchase for everyone on my Test Team. Maybe you should get it for team, too?
In my years of working in software development I have noticed to paths testers take. Chaotic, where they initially try to break the system with the most extreme choices they can, and spec testers that work closely to specific test cases. If a person applies the principles in this book to software testing it will lead to respectable feedback to the developers for addressing deficiencies (whether those are bugs or expected functionality that is lacking). The benefits of both the harsh and spec based testing will be made manifests in exploratory testing.
The chapter on chartering is excellent, because it not only proposes a good practice for software testing but for addressing a multitude of problems. It is as follows: Explore ___ with ___ to discover ____. Outside of testing software consider its application to acquiring virtues, trying out new team practices, or making any type of major "trial" to see if a process is in somehow improved.
The Test Heuristics cheat sheet is excellent for beginners, and is worth going over with your newer software testers so that they are providing value above that of just a standard user testing the software.
I would recommend this book and encourage members of my team to read it.
As someone who has been in this business a long time and read almost every tome out there, I would highly recommend this book- especially for teams that are adopting exploratory testing to supplement automation in an agile process or planning for session based testing in a waterfall method.
The beginning of the book starts with an explanation of testing and exploration in which she mentions the debate on testing and checking ([...] and to me this gives a good grounding of where Elizabeth sets the context for what follows in the book. I especially like the point she makes regarding the need to interact with the system:
Until you test--interact with the software or system, observe its actual behaviour, and compare that to our expectations--everything you think you know about it is mere speculation.
Elizabeth brings up the point of how it is difficult to plan for everything and suggest we plan just enough. The rest of the first chapter goes into more details as to what are the essentials of exploratory testing and making use of session based test management.
One part of the book I found useful was the practice sessions at the end of each chapter to help you recap what was being explained within the chapter. If you are the type to normally skip this kind of thing (like myself) on this occasion I would recommend that you give them a go, it really does help to understand what has been written in the chapter.
The next chapter introduces charters to the reader and for me this is the most useful and important chapter of the book. It helped me to clarify some parts of the exploratory testing approach that I was struggling with and simplified my thoughts. Elizabeth explains a rather simple template for creating your own charters
To discover (information)
* Target: Where are you exploring
* Resources: What resources will you bring with you
* Information: What kind of information are you hoping to find?
The rest of the chapter takes this template and using examples provides the reader with a way in which to create charters simply and in some cases quickly. Along the way she introduces rules that one may wish to follow to avoid turning the charters in to bad charters. She also offers advice on how to get information for new charters (joining requirement/design meetings, playing the headline game) .
What, you do not know what the headline game is?
Well you need to buy the book to find out.
I have started to use this template to create charters for my own testing going so far as to add this template into the mind map test plans. This to me was worth paying for the book just for this very useful and simple approach to chartering exploratory testing.
The following chapter takes you on the journey of the importance of being able to observe and notice things. This is a key element of exploratory testing and looking for more things to test is a part of this.
Elizabeth talks about our biases and how easy it is for us to miss things and provides examples of how we may try and avoid some of them. She talks about the need for testers to question and question, again to be able to dig deep and uncover information that could be useful. This chapter is useful for being able to uncover the hidden information and it suggest ways in which you can get more information about what you want to explore without the need for requirement documents. This is important since it is better to have the skills that allow you to be able to ask questions
The next few chapters of the book look at ways in which you change or alter the system to undercover more information by means of exploration. These chapters take the cheat sheet Elizabeth and others produced ([...] and add a lot more detail and practical ways to look at the system with a different perspective. These chapters include titles such as:
* Find Interesting Variations
* Vary Sequence and Interactions
* Explore Entities and their relationships
* Discover states and transitions
A great deal of this is found in part two of the book and this section is something I repeatedly return to for quick inspiration of what I can do to explore the system more. It gives some great techniques on how to find variants in your system and how to model the way the system is working. It provides useful ways to help you find the gaps in your system or even in your knowledge.
In the middle of the book there is a chapter called `evaluate results' whereby Elizabeth asks if you know the rules of your system. If you do not then it would be useful to explore and find them. She explains the meaning of rules using `Never and always'. If you have a rule that saying it always should do this, then explore. The same for `never' you can explore and uncover where these rules are broken. This chapter also looks at outside factors such as standards, external and internal consistency. All these are important when exploring the system and Elizabeth within the book reminds us in this chapter to be aware of such things.
The final section of the book is titled `putting into context'
In the chapter `Explore the ecosystem' expands upon the `evaluate results' chapter and now asks you to think about external factors such as the OS, 3rd party libraries. Elizabeth gives a great tip in this chapter on modeling what is within your system and what is external and how they interface. I have found this extremely useful to work out where I can control the system and where this is outside of my control. Once this has been done, you can then, as Elizabeth suggests as the `What if' questions of these external systems. If you want to know more about these What if questions, again, I recommend reading the book.
Within here, Elizabeth gives advice on how to explore systems with no user interfaces. For someone such as myself where there is very few user interfaces, I found a lot of useful information in this chapter. Especially for making me think of ways in which I could manipulate the interfaces and explore the APIs.
Next Elizabeth talks about how to go about exploring an existing system and gives some great tips on how to do this such as:
* Recon Session
* Sharing observations
* Interviewing to gather questions
This chapter is useful for those who are, or have tested, an existing system and need new ideas to expand their exploration.
Elizabeth then talks about exploring the requirements which is very useful for those who have requirement documentation and within the chapter there are lots of ways offered in which you can explore them. One great suggestion in using a test review meeting and turning it into a requirements review. Elizabeth offers many other suggestions on how to create charters from the requirements and use these during your exploratory testing sessions
The final chapter of the book is to think about exploratory testing throughout the whole of the development of the system and how to make exploratory testing a key part of your test strategy. The key point I got from this chapter was the following:
When your test strategy includes both checking and exploring and the team acts on the information that testing reveals, the result is incredibly high-quality software
Elisabeth gives some real life experiences and stories of how she went about ensuring `exploring' is a key part of testing. This chapter is very useful for those who want to introduce exploratory testing and are not sure how to go about doing this.
At the end of the book there is a bonus section on interviewing for exploratory testing skills and some details about the previously mentioned cheat sheet.
This is now my testing `go to' handbook and to me it is as important as my other `go to' testing reference book by Glenford Myers - The Art of software testing (Art Software Testing Glenford Myers ebook
I recommend that all testers should have a copy of Explore It as well as anyone who works with testers. There is information in this book that can help developers with their unit tests by making them ask `have I thought of this'? It can be used by product owners to put together their own charters which they feel would be important to be investigated or explored.
Would I recommend buying this book? Heck! YES.
Testers at all levels of experience will benefit from this book. Like the best TED talks, Explore It! contains advanced ideas, yet those ideas are presented in way that is both interesting and accessible to a broad audience. Beginning testers will benefit from learning about the fundamentals of Exploratory Testing (an important and incredibly useful approach to software testing that is increasingly getting the respect it deserves). Experienced testers will benefit from practical insights, frameworks for thinking about challenges that bedevil all of us, and Hendrickson’s unmatched ability to clearly explain important aspects of testing (including her superb explanations of test design principles).
Chapter 4 “Find Interesting Variations” in itself is worth far more than the price of the book. It is my favorite chapter in any software testing book I have ever read. A large part of the reason I have so much appreciation for this chapter is that I have personally been teaching software testers how to create interesting variations in their testing efforts for the last six years and know from experience that it can be a challenging topic to explain. I was excited to see how thoroughly Hendrickson covered this important topic because relatively few software testing books address it. I was humbled by how effortlessly Hendrickson seemed to make this complex topic easy to understand.
Buy it. You won’t regret it. I’m buying multiple copies to give to developers and testers at my company as well as multiple copies to give to our clients.