Do you trust the Work-Around

In the past I already made a post related to workarounds March 23rd, 2008: Start managing your Workaround's!

In that posting I advice to start with documenting workarounds and managing them based on their lifecycle. We should avoid that workarounds get normal desired functionality by just using it; the next step would be that that usage become normal expected activities.

An article I read a while ago is related to functionality which is default in MS Outlook, auto complete e-mail addresses, only that functionality is often not embedded in processes. It is there, only organizations often don't tell you to use it or not.
CNet new: February 5th, 2008: Lilly's $1 Billion E-Mailstrom;
The New York Times, January 30th, 2008: Lilly Considers $1 Billion Fine to Settle Case.

In this example you see that functionality available in the system can be used. Workaround are often also defined because the system missing some functionality and tells you how to use parts of other functions to get your job done.

Most of us know that when defects are found, workarounds are defined; we also test the work around. Only after a while it is forgotten what the workaround actually was. Therefore we should manage the workarounds we define in systems.
We should ask ourselves each time: do we trust the workaround?

Just one development method

Over the years I learned that in most companies a development method is chosen. In the Netherlands it depends in which area you work. Most of the organizations I saw or heard about classified RUP as development method. In SAP related projects they claimed they were working according ASAP.

How often is not asked to the tester if he/she has experience with that certain development method? At least it is a pre when you have some experience. The conclusion is often made that if a person has experience working with a certain development method he/she is able to fit that experience towards testing in those projects.

Besides that experience of development method also experience is asked about testing methods and the ability to adapt that method to those development methods. In plain theory it is all possible and is also written in several books.

Most of the time those organizations are not able to use the development method as it was intended. And they also did not write down or monitor which adaptations they have made. The risk here is that it will be even harder to make the test method fit to the process. I think we should never forget that testing is just a part of the development process and if that process is not clear then the chance that the test process is optimized is very small and improvements can only be made towards the testing process. A strong link in a weak chain is created.

I wonder why organizations keep sticking to one development method although they already know it doesn't fit for all projects and still demanding to work accordingly as it is default standard.

What I suggest to evaluate in your organization what need you have and how that need can be turned into value. Sometimes you have large projects were RUP can work very well. Sometimes you have smaller projects were an Agile approach fits better. The main thing is to define multiple approaches and select them based on the benefits and check if the disadvantages are acceptable. Also keep in mind if the chosen approach fits in the business culture and supports the organizations vision, strategy and goals.

If the development method is clear a test method can be fit much better and the benefits of both approaches can be reached and the disadvantages controlled better.