Nice little poem from Anne Marie Charett

http://mavericktester.com/archive/please-dont-hire-me/

 If you want perfect software

If you want me to break your code 

If you want to measure me by the number of test scripts

I write If you want me to tell you its ready to ship 

If you want 100% of your product tested 

If your looking for a tester to only “check” if things look ok 

If you want your testers to mindlessly follow test scripts 

If you want training on a test process If you feel you can’t test without requirements

But if you’re looking for a tester who prides herself on the work she delivers, offers as much value to her clients as she can, and has a reputation for excellent testing, then yes, please hire me!

Thoughts on testing - James Whittaker

              
- Take your testing up a level from test cases to techniques

Test cases are a common unit of measurement in the testing world. we count the number of them that we run, and when we find a bug, we proudly present the test case that we used to find it.

I hate it when we do that.

I think test cases - and most discussions about them - are generally meaningless. 

I propose we talk in more high-level terms about test techniques instead. for example, when one of my testers finds a bug, they often come to my office to demo it to me (i am a well-known connoisseur of bugs and these demos are often reused in lectures i give around campus).

Most of them have learned not to just repro the bug by re-running the test case. They know i am not interested in the bug per se but the context of its exposure. there are the type of questions i like to ask during bug demos:

1. what made you think of this particular test case?
2. what was your goal when you ran that test case?
3. did you notice something interesting while running the test case that changed what you were doing?
4. at what point did you know you had found a bug?

At Microsoft, we have begun using the concept of test tours as a way to categorize test techniques.

- It is our task to use testing as an instrument of improvement

- This is the true job of a tester: to make developers and development better; we don't ensure better software - we enable developers to build better software; it isn't about finding bugs, because the improvement caused is temporal

The true measure of a great tester is that they find bugs, analyze them thoroughly, report them skillfully and end up creating a development team that understands the gaps in their own skill and knowledge

Making developers better, helping them understand failures and the factors that cause them will mean fewer bugs to find in the future

The real value of tests is not that they detect bugs in the code, but that they detect inadequecies in the methods, concentration and skill of those who design and produce the code (Tony Hoare)

- Testing without innovation is a great way to lose talent

Testing sucks. now let me qualify that statement: running test cases over and over - in the hope that bugs will manifest - sucks. it's boring, uncreative work. 

What is interesting about testing is strategy, deciding what to test and how to combine multiple features and environmental consideration in a single test. the tactical part of testing, actually running test cases and logging bugs, is the least interesting part

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

OR

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.

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?

Alex