I’m leading a SWAT team. S.W.A.T. here stands for “Systematic Wondering, Automation, Testing”. We’re doing all kinds of cool stuff in testing. Might say, transforming “some” testing to awesome testing. I am very excited about it.

While doing a lot of thinking, and having a lot of ideas I could write about, and having experiences I’d like to share, I can’t help but notice that I’m not blogging for quite a few months. It seems that I simply don’t have enough time to sit in WordPress, and even when I try to, an urgent matter comes up. And yet I had a lot of stuff written in my tester’s notebook. I do it in between of things. I take notes for the very same reasons as in the article linked. In short, note-taking is my thinking tool.

So I decided – as much I’d like to write elaborated ideas and experience reports, best I can do now is to publish some of my notes, and (hopefully) I will expand them into articles in the future. Or not.

***

Who should have a control over test environment? Programmers or testers? Seemingly, agile development teams shouldn’t even have such question. And yet I saw it existing in variations both in agile and waterfall teams.

There is a number of reasons why testers need the environment to be in a specific way.

• They want to finish testing mission while pushing new code will render all testing progress irrelevant.
• They want to know what code and configuration changes are being pushed in order to define their testing mission(s).
• The database in testing environment is too trivial, not helping to create situations that will/might happen in production.
• They want to have open access to all configuration and data in order to create testing situations by purpose, not by chance.

Not all of these problems demand for the ownership of the test environment by testing team. Some of them can be resolved by timely and precise communication. Some of them can be resolved by effective collaboration.

***

“The product is a solution. If the problem isn’t solved, the product doesn’t work. “

Hence one of the questions I’m always trying to clear – what problem(s) this particular functionality is trying to solve.

Problem – Solution – Logic – Implementation.

Logic is “requirements”. They can be very elaborate and signed off, or go quite informal as “user stories”.

Implementation is specification and the software product itself.

The problem is often in “Problem – Solution” pair. If a tester doesn’t realize what is the problem that the functionality intends to solve, how he (she) can go above and beyond functional correctness?

The most important and the most hard-to-find-and-expensive-to-fix bugs are not in the compliance with specification. They are gaps in logic, conflicting requirements, misunderstood (misinterpreted) logical rules, and, of course, inadequate solutions.

On the spectrum from Problem to Implementation, some roles seem to be involved only in certain phases – “requirements gathering”, “architecture design”… Testing, especially if it pretends for the Quality Assurance role, has to spread itself everywhere.