Tag Archives: scrum

Standard

Posted by

Posted on

April 24, 2012

Posted under

Software testing

Comments

2 Comments

Why test “by the book”

The other day I was reading a blog post on agile and why agile will fail in many instances. One of the comments got my specific attention, the comment states the following:

” a process with little Agility due to the remains of the “old process”. ”

This is why by-the-book scrum is so powerful. Too many agile consultants try to fit agile into the existing org structure and processes, thereby allowing existing dysfunction to remain, or worse, covering it up. They try to modify everything right out of the gate, instead of just choosing scrum.

This got me thinking about why so many methodologies seem to get followers who treat “their” methodology as a religion. I have been pondering about the different development and testing methods, such as XP, Scrum, Lean for development life cycles and ISTQB, TMap and such for testing in particular.

In religions it is generally considered bad to be extreme in following the rules, hence the term extremist, whether this is an orthodox, katholic, jewish or islamic extremist, they are always considered to be dangerous to society. Isn’t it the same in software development and testing? Aren’t the people who go to extremes to follow the rules as dreamed up by some author also extremists that seem to lose sight of the context?

Thus far the best implementation of any methodology I have seen, is a form of hybrid, or as the Dutch would call it a “polder model”, where you make a compromise between “the book” and “what actually works for us as a team or organization”.

Are methodologies best practices then? Aren’t methodologies meant to help people get a frame of reference and fill that in for themselves, by thinking about the frame of reference, critizing it, adjusting it to their needs. Shaping the method in such a way that it works optimally for you, in this situation, in this particular context. When moving on to a new task or assignment, you can take these learnings with you and see what of it works for you within this new context and adjust whatever doesn’t work.

Maybe it is time for a new methodology, which ties in well with a solid development method by Zed A. Shaw. A possible working name could be “Testing, fuckwit!”.

Standard

Posted by

Posted on

April 20, 2012

Posted under

Software testing

Comments

7 Comments

Is testing the dumping grounds of IT?

The other day I was talking to a few developers I was on an assignment with about getting testers added to their scrum team, and the response I got from them disturbed me. They told me that in their experience most testers do not work together in the team, they work against development, trying to get everything fully tested, despite them knowing this is not a feasible thing, and with that delay projects. On top of that they told me, most of the testers they have worked with, are part of the dumping grounds of the IT industry. And with that they meant that in their view most testers are not good enough to be a developer, so they decided to become testers instead (<sarcasm> cause, come on, testing is not that difficult anyone can do that! <\sarcasm>).

I was shocked to hear there are still a lot of developers out there who believe that testers are the dumping grounds of the IT industry, but I was even more shocked of their experiences with testers, working in an “us versus them” modus operandi instead of working in a team, part of a joing effort with a shared focus and goal.

What is it that still makes testers often work against developers instead of with them?

Most testers I have worked with over the past years agree that working side by side with development is the most effective and efficient way of working, this way you both keep track of your joint goal: get the software out on time, on budget and according to what your customer (or end-user for that matter) wants and needs. Together you try to add value to the software.

So is it indeed true that there are still a lot of testers out there in the field who are indeed not seeing the big picture and are trying to prove their worth by working against dev and looking for bugs that are not relevant, e.g. just looking for bugs for the sake of finding one, no matter what the value of that bug is to the end-user/customer, just so they can triumphantly point to a developer that indeed, “see! There are bugs in your code, you did it wrong!” Unfortunately I fear there are still too many testers out there that think and work this way, not to even mention all the developers out there that seem to not understand the added value of a good tester to the team and to the developers work!

Fortunately there is a wonderful contrast out there as well, in the form of this blog post by Nathan Lusher who shows that there indeed are good testers out there, who weigh in on a project and prove the value of testing and with that show that testers are not (or at least not everywhere) the dumping grounds of IT.

In my experience, there are a lot of very good, inspired and knowledgable testers out there, who see the added value of working together, in a team with a shared goal, a shared approach and shared respect. If testers want to get the respect of developers, I believe it is up to quite a lot of the testers to start by showing respect to the developers and where needed, increasing their technical knowledge in order to be able to counterbalance a developers viewpoint. You get what you give!