Good books for new testers

I found recently 3 good books that new testers can use for improving their testing knowledge.

All of them are written by the author of the blog, Ajay Balamurugadas.

He trained with James Bach and is an adept of the context-driven testing school.

These are the links to the books.

They are not free but very cheap ($8 for all 3):

What If

What If - 50 tips for winning testing contests

What If - 50 tips to boost your productivity



James Whittaker - About Google Search

The problem with Internet search is that being stupid about it is profitable. The more ugly blue links you serve up, the more time users have to click on ads. Serve up bad results and the user must search again and this doubles the number of sponsored links you get paid for. Why be part of the solution when being part of the problem pays so damn well? It's 2012 and we are still typing search queries into a text box. Now you know why, a 'find engine' swims in the shallow end of the profit pool. Is it any surprise that technology such as Siri came from a company that doesn't specialize in search? (Where do you place an ad in a Siri use case?)There's no more reason to expect search breakthroughs from Google than there is to expect electric car batteries to be made by Exxon.

Your success at search depends on how good you are at it and how much time you devote to it. Users have noticed and abandoned search in droves, particularly mobile search. They voted with their fingers and installed apps to do the search work for them. Apps are capable of sorting through just the portions of the web you might be interested in. Don't search the web for soccer scores, use an app. Don't search the web for hotel deals, use an app. Apps are better because they cut search out of the equation. Apps succeed in large part because search is so broken.

You want a prediction of the future? The trend of disappearing search will continue. The web will melt into the background and humans will progressively be removed from their labor intensive and frustrating present by automation. In five years the web is likely to be completely invisible. You will simply express your intent and the knowledge you seek will be yours. Users will be seamlessly routed to apps capable of fulfilling their intent. Apps won't need to be installed by a user; they will be able to find opportunities to be useful all by themselves, matching their capabilities with a user's intent. You need driving directions? Travel reservations? Takeout? Tickets to a show? Groceries? Tell your phone, it will spare you the ugly links. It will spare you the landing page. It will spare you the ads. It will simply give you what you asked for. This is already happening today, expect it to accelerate.

Test Ideas

When you run out of ideas of how to test a web application, please consult the Test Heuristics & Data Attacks list of Elisabeth Hendrickson.

You will find there lots of test ideas group by:

  • data type attacks
  • web tests
  • testing wisdom
  • heuristics
  • frameworks


Use Michael Bolton's suggestions of exploratory testing tours.

These are the tours:

- Happy Path
- Variable Tour
- Sample Data Tour
- Input Constraint Attack
- Documentation Tour
- File Tour
- Complexity Tour
- Menu, Window, and Dialog Tour
- Keyboard and Mouse Tour
- Interruptions
- Undermining
- Adjustments
- Dog Piling
- Continuous Use
- Feature Interactions
- Summon Help
- Click Frenzy
- Shoe Test
- Blink Test
- Error Message Hangover
- Resource Starvation
- Multiple Instances
- Crazy Configs

For the tours' details or for the original post, you can find it here.

Manage Yourself And Others (Weinberg)

I've started reading this book yesterday and loved every page of it:

One of my favourite quotes is: Manage yourself if you want to be able to manage others.

This is the book's description from the website:

Becoming an effective manager is the subject of this volume in Gerald M. Weinberg's highly acclaimed series, Quality Software.

To be effective, managers must act congruently. Managers must not only understand the concepts of good software engineering, but also translate them into their own practices. Effective managers need to know what to do, say what they will do, and act accordingly. Their thoughts and feelings need to match their words and behaviors.

Congruence has the sense of "fitting" —in this case, simultaneously fitting your own needs, the needs of the other people involved, and the contextual, or business, needs. Managers themselves must take responsibility for improving the quality of management and for changing their own attitudes and thinking patterns before they attempt to impose changes on everyone else.

As the author advises, "If you cannot manage yourself, you have no business trying to manage others." This book offers practical advice on how to act, and how to manage others congruently. Examples, diagrams, models, practice suggestions, and tools s fortify the author's recommendations.

Topics include:

• learning to manage yourself

• why congruence is essential for managing

• choosing to undertake management

• identifying the various styles of coping, especially under stress

• moving from incongruence to congruence

• managing others

• learning the manager's job

• identifying differences in preferences and temperament

• making use of differences as assets

• spotting patterns of incongruence

• understanding the role of self-esteem

• mastering the technology of human behavior

Software Development Best "Practices"

As opposed to the software development worst "practices" (see this), there are best "practices" as well.

Please check this article for more details.

Everything is about process improvement and things to be done so that the code/product is good from the first time:

1. the product is as good as the plan for the product - very detailed, frequently updated, shared with the team plan is a must for any good product

2. the best teamwork is a healthy rivalry - the dev team should aim at making it very difficult for the test team to find problems; the test team should aim at finding bugs that escaped the dev team's testing; each of these team try to improve as much as possible all the time so the other team has a tougher time in the future getting bugs out (dev) or finding bugs (test)

3. the database is the software base - all possible development/testing data is collected in a database and analysed with the purpose of improving the existing processes, finding the root cause of any problems and correcting them

4. don't just fix the mistakes - fix whatever permitted the mistake in the first place (my favourite item)

Some of my favourite paragraphs are these ones:

"People have to channel their creativity into changing the process," says Keller, "not changing the software."
"The group's most important creation is not the perfect software they write -- it's the process they invented that writes the perfect software.
It's the process that allows them to live normal lives, to set deadlines they actually meet, to stay on budget, to deliver software that does exactly what it promises."
"The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering."
So much common sense, so difficult to do ....

It seems that common sense is possible only for NASA and maybe a few other companies.

What is left then for everybody else?


Making It Big In Software

I learned about the existence of this book a while ago but read a review of it yesterday on Randall Rice's blog.

Here are a few excerpts:

Lightstone lays out all kinds of practical, real-world advice, such as "What to Look for in a Company." I like this list and it reinforces a key idea that you do not have to strike out on your own to make it big.

"1. Is this a company that has experience in building professional, high-quality systems?
2. Are there really talented people here I can learn from?
3. Is the position I’m being offered one that is interesting, with long-term growth potential on something I can believe in?
4. Do they have savvy business executives who really understand the business requirements for success and have a track record for delivering it?
5. Does the company have clarity of vision for the product it produces?
6. Is there an independent research arm?
7. How does the company innovate, and how profound has their innovation been?
8. Is the work environment pleasant and flexible, and does it suit my lifestyle?
9. Does the company seem stable? Do I believe it will still be around in ten years?
10. Is the pay in line with industry standards?"

I just bought it from Amazon for Kindle (book link here) and start reading it :)

Sounds like the type of testing book I like.


Software Development Worst Practices

In my full time jobs, over the last 6 years, I've worked in so many web and mobile projects that I lost track of the total number.

So many of them .... and in most, the same problems occurred again and again about unrealistic time-lines (not supported either by past projects or provided by the dev/qa/db teams), requirements changing until the last minute, testing in the same time with development, no risk analysis, etc.

These things repeated so much in my past experience that after a while, all of them became the norm, so normal.

You get so used to them that you don't see them as wrong after a while.

This is why it is refreshing to find an article like the one from below with the top worst software development mistakes, compiled in many years of experience of the author.

I am still puzzled of why software development projects cannot be better but at least, I know now that what I went through is not an exception but probably the rule.

This is the article on software development worst practices written by Gregory Pope and published, where else, in the Better Software magazine:


Great exploratory testing demonstrations

The following links are taken from Pradeep Soundararajan, author of the Tester Tested blog.

The first one is for a demonstration of exploratory testing for a simple web application:

The second is for exploratory testing of the installation process of an antivirus:

I was thrilled to discover and watch them.

Many things can be learned by just watching.

The antivirus demo is a bit slow in the beginning but after 10-15 minutes, it becomes much more interesting.

In my opinion, these demos should be recommended "reading" for anyone who wants to start learning or improve his testing.



Test idea generation for mobile apps

I received yesterday a reminder by email from the Agile Vancouver group about this year's conference.

They have my email address from the 2011 conference when I attended two tutorials on agile test automation.

So, I checked this year's agenda to see what's going on and noticed a 1 day hands-on training given by Jonathan Kohl.

The name sounded very familiar but could not say from where.

My suspicion was that he had articles published in the Better Software magazine but again, I was not sure.

The next thing was checking a bit of background on Jonathan Kohl to find out more on his mobile apps testing experience.

His website has a section with his publications which showed that I was right, he did publish a lot on Better Software.

One of the articles had an interesting title: Test Mobile Applications with I Sliced Up Fun.

The article is about all different ways of testing any mobile app and with details on how to explore them.

It covers everything important as follows:

I: Inputs into the device

S: Store (requirements for submitting the app to the mobile app store; this is mostly important for IOS apps where there are guides that the IOS developers should follow)

L: Location (test at home using wifi, test at home using 3g, test in a bus using 3g, etc)

I: Interactions/Interruptions(calendar reminders, using the contact list, switching to a different app and resuming, etc)

C: Communication (receiving sms, receiving a phone call)

E: Ergonomics

D: Data

U: Usability

P: Platform (test it for different versions of the operating system - not very practical in many cases but possible)

F: Function

U: User Scenarios

N: Network (test the app only with 3g, only with wifi, switch from 3g to wifi during testing, only with bad quality of the 3g signal, etc)

I have not learned much from it but .... I really wished I read the article a year before!!!

My last year included so much mobile apps testing that could have benefited immensely from the article's info.

What I am trying to say is that I learnt about testing mobile apps the hard way.

It was still a lot of fun but not easy.

Maybe after you will read this article, your learning will be much faster than mine.