Impressions of “How to Break Web Software” by Mike Andrews and James A. Whittaker

Everyday testing for me involves Web Software, to be precise, I mainly test a Web Service. At work we have a company book shelf and there were no surprises to encounter  “How to Break Web Software: Functional and Security Testing of Web Applications and Web Services” by Mike Andrews and James A. Whittaker. As it was the only testing related book in the shelf at that point – I decided to read it.

This book was written in 2006 so you can imagine that a lot has changed since! Web Software is bigger than ever. Even a regular website may use multiple web services. I did smirk a lot on some of the terms like Web Bugs (I never heard this term before: it would always be called a tracker or a tracking pixel in my environment). Also, to be honest, some of the tools or examples including IE6 made me cringe a little bit and felt a bit outdated, but…

“How to Break Web Software” gives very good foundation for Security Testing Web Software. I haven’t had much experience with Security Testing except for  one of the days in the 30 Days of Testing where I got to play around with Gruyere.

SQL injection, cross-site scripting, session hijacking and cookie poisoning (web cookies not the ones you brought to work to your colleagues as advised in “Explore It”) are just a few attacks which are in this book. Attacks have very clear structure: when to apply it, how to conduct it and how to protect from it.

Not only that the book describes attacks clearly, but it explains the way Web Software works and introduces its terms and technologies. I realized that the last chapter called Web Services would have been like a gold mine for me from the first day when I started working here. It describes technologies I have to work with daily.

“How to Break Web Software” gave me a better understanding of Web Software and even how to be safer in the Web applying some tips mentioned in the book. The attack descriptions were a great way to learn about the testing techniques heard about before, but the best way to learn them better is to apply them practically.

 

 

Advertisements

Learnings from “Explore It!” by Elisabeth Hendrickson

Exploratory testing is mentioned quite often in the testing world and I believe that the best book to start learning about it is Explore It! Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson.

This book is pretty short (186 pages), written in a wonderfully smooth and easy to read style, and, it is full of practical tips and tricks for testers. I felt that a lot of things I’ve read in the book I always wanted to express myself, but never found the right words.

Elisabeth starts with foundations about exploring and why it is important. What I liked a lot in the first part of the book was the definition of testing which allowed me to finally know how to clearly answer what’s the difference between testing and checking:

Testing = Checking + Exploring

You’re not done testing until you’ve checked that the software meets expextations and you’ve explored whether there are additional risks.

Very often some colleagues may not understand that testing is more than checking the requirements – there are many silent risks which may cause problems and to find them we need to explore. I also loved Elisabeth’s example of a net: you can imagine software covered in a net and the better coverage there is of the checks, the finer the weave is. However, checks may not cover some spots, so we must explore to find areas where we should improve the net weave.

After some foundations, this book provides many practical tips on how to explore. It teaches you how not to get overwhelmed with the areas to explore, how to create charters and lists many helpful methods for exploration. They are explained in a clear manner and their summary is added in an Appendix 2 of the book. You may have heard of same author’s Test Heuristics Cheat Sheet which is pretty similar to the one in the book.

One more thing that I found especially useful and right on point was the last part of the book called “Putting It in Context”. Not only does it have a lot of useful information on testing itself, but also Elisabeth includes several valuable tips on the communication part of the tester’s job (and.. I love this topic!).

What struck me the most was that very often testers end up “creating” new requirements which may cause some tension in a team. This is very common in a life of a tester as the more you use the product – the more areas you uncover and some of them may not have their requirements specified. In this situation, programmers may get a bit hurt that the tester is coming up with never mentioned scenarios. Here Elisabeth gives a great tip for testers: try to get into requirements meetings. Testers must be present when the requirements are being created together with a programmer and a product manager. In this way, risks can be discussed and clarified together avoiding silent requirements popping up in the late stages of the product which may expand the scope. And, Elisabeth gives a brilliant tip on how to get into those meetings:

Bring cookies. The other people involved are less likely to kick you out of the meeting if you come bearing chocolate.

In conclusion, “Explore It!” was a pleasure to read. It is a very helpful book on how to express yourself better and how to do that sometimes overwhelming job of a tester more systematically. I feel like I have gained confidence as a tester after reading this great book. Nevertheless, I recommended it to some of my non-tester colleagues as I am sure that it gives a good and easy to understand insight to testing.