Other Sellers on Amazon
+ $3.99 shipping
+ $3.99 shipping
+ Free Shipping
Fifty Quick Ideas To Improve Your Tests Paperback – May 15, 2015
|New from||Used from|
Enhance your purchase
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
- Publisher : Neuri Consulting LLP; Illustrated edition (May 15, 2015)
- Language : English
- Paperback : 124 pages
- ISBN-10 : 0993088112
- ISBN-13 : 978-0993088117
- Item Weight : 11 ounces
- Dimensions : 8.5 x 0.34 x 8.5 inches
- Best Sellers Rank: #924,587 in Books (See Top 100 in Books)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
This book probably will be helpful if you have a year of experience in QA and you have never learned basics. It doesn't give principles it really just give some ideas. And these ideas , from my point of view, can often lead to other problems
If you at least know that team should not touch code until they really Understand Why they are implementing this - then you probably can just ignore around 15 'ideas' from this book.
If you are not skipping planning phase you probably can skip another 5 'ideas'.
Even more, if you don't have 5+ years of experience it's better to just not read some ideas. And if you have - you will probably waste your time.
For example 'writing assertion first'. Yes idea looks nice. You are covering all results and after that you are covering all inputs which lead to these results. Do you see a problem in my statement? Most of the newer testers will not see it. Most of newer testers will only try bunch of inputs which would lead to expected results. They will not try to send broken or large file, or file with different encoding. Why? Because they don't know what will be the output!
Or there was some idea about partitioning. I don't think that it was mentioned that you should talk to dev team (or check code). As author is saying similar inputs can lead to different results. But to be frank sitting in groups and discussing partitions (keep in mind you need at least 4 testers for this) wastes quite a lot of time. If you ask about data flow and checks in code you will not only understand better edge cases but also what was already covered on unit level. And again - I was taught about this in my first month. Just work as a team. Work with developers and BAs. They are your friends
Also some ideas like 'one test one topic' are just covering some super basic rules in roundabout way. Just test one thing in one test. It's one of the main rules when creating TC
I really like the approach of these short, focus, one-topic books, starting with Gojoks book on impact mapping. They don’t promise to be deep dives and total coverage but rather to give you ideas (well… that’s in the title even), be challenged and investigate further.
In this book, on testing, they have divided the ideas into 4 groups, brushing on different aspects of testing:
- Generating test ideas
- Designing good checks
- Improving testability
- Managing large test suites
One of the things that struck me is how far (agile) testing have progress during my relative short period interested in the field. This is a very sober and concrete look at the new breed of testers that want to be part in design, that takes failed tests as an opportunity to learn. We have sections on measuring test half times (how often do test change) in order to focus our testing efforts, there’s suggestions for how to involve and inform business users directly in creation of key examples etc. This is not your fathers testing and I like it!
I have a confession to make: I’m not really into testing. I’m a developer and very fascinated by agile testing but the early parts of this book touch more on organizations of test efforts and exploratory testing planning etc. That’s not my thing really. I read those parts faster. There’s a lot of good things in there, let there be no mistake about that, but it’s not my area of expertise and interest.
The two last parts I found extremely interesting and packed with battled-harden experiences that I sometimes found myself nodding in agreement too. Sometimes I heard myself going “Aaaaaah - I’ve never thought about that”. And sometimes I had to reread paragraphs a few times because it was really a new take on a situation I’ve been in.
And that’s typically how you get the experiences from experts served. Somethings you have experienced yourself and other things is things that helps your knowledge to take a jump ahead.
The only real complaint you could have on this book is around the format. Yes I know. That’s what I said that I loved. I’m an enigma, what can I say?
Everything that I didn’t know about before left me feeling that I wanted some pages more on the topic. Or examples on how to implement this, although every Idea has a “How to make it work”-section that gives you a starter.
This is by design.
The book is not meant to be a complete overview. You should, as they point out in the intro, not read this as your first book. I might add: you should not read the entire book in one go. This is what I did. It left me hugely inspired to try things out, but also a little bit overwhelmed and scared that I will forget everything I read.
Instead I would suggest that you browse this book for overview and knowledge and then use it as a tool, hands-on, in your team. Keep it next to your team and look problems you run into up in the book. There’s a lot of pointers and ideas that can help you to get many, if not all, of the testing problems I’ve seen team run into under control.
I could not recommend the book more. Any serious agile tester should have this handy and get inspiration to move even further.