Te koop: Adriaan van Altenastraat 10, Dordrecht

Te koop: Adriaan van Altenastraat 10, Dordrecht

Huis te koop: Dordrecht, Adriaan Van Altenastraat 10 - HuizenZoeker

Huis te koop: Dordrecht, Adriaan Van Altenastraat 10 - HuizenZoeker

The Open Source Test Tool paradigm

Article to be published soon. Detailes will follow.

Assumption is the mother of all....

It still amazes me that the statement "Assumption is the mother of all F*** ups" is present in almost every project. We all seem to know what is best and what the other means without verifying it. Why is this?

In theory there are several options;

1. We assume the other person thinks like us;
As we are all human we think for and from ourselves. This means that we have a certain order in the chaos in our head that is very logical to the individual. Since we cannot look into the other person’s chaos (yet), we assume he/she has the same kind of structure, because to us, this seems logical. In doing so, we forget the fact that every chaos is unique as is the structuring of it. This structuring of the chaos is compulsory to make sense of it all. If we can make sense of something, the other person should be able to as well. And thus the assumption has been created.

2. We presume that the other party is on the same level as us;
We are all professionals, working in projects or departments and have been selected by a company because we have a certain level of education and or knowledge. Because of this, we should be at least on the same level of "brainpower". Even though this might be true if speaking in general, the application of this "brainpower" is different for everyone. As some people can think abstract, others might never be able to. Next to this, different levels of approach are often causing the problem. Someone from the business might have a complete different idea about a certain requirement then someone from IT.

3. We think we know it all (been there, done that);
As we execute more projects, we tend to do the same thing in every new project because of the fact that this is a best practice and/or it works best for us. Which is not a bad thing obviously (don't invent the wheel every time). But by doing so, we might forget that new project means new people, means new...well actually everything. We should not be sure that the best practice is applicable here as well without some fine tuning and adapting to the current situation.

4. We don't read thoroughly enough;
When we read documents, we can do this in many ways. By just reading what it says or intensively trying to make sense of it all and finding out if what it says really is correct. Even the later can be done from many viewpoints. As an example, executing a fagan inspections is done by multiple parties from multiple angles (e.g. testability, maintainability, etc...). A very thorough Fagan inspection might even take 30 minutes to an hour per page to review. But overall, we don't do this kind of review and we only notice the obvious statements, even not bothering to map multiple documents. We assume that statements in the documents are overall correct and that the professional that wrote it, would probably know what he/she was talking about. Especially when it seems to be very complex (or technical).

5. We don't dare to ask, because the other party might think we are stupid;
We all know it; afraid of asking a question because everyone seems to know what someone is talking about. But...there are no stupid questions, only stupid answers! We don't like to be seems as stupid or ignorant, so we just avoid asking the questions and might try and find out what is being said in another way. Or make an assumption (and there it is again). Asking questions in the start of a project is easy, if the project has progressed, this becomes more difficult, because people would expect you to know what it is about. Then again, we cannot read each others minds.

6. We don't dare to ask, because we are stupid;
Well....that is certainly the case with some people....but actually this is a lost case...just replace them ;)

All in all, some points why we make assumptions in my opinion which is one of the biggest pitfalls of any project! Especially when assumptions across parties are made (client-supplier in particular).

Most effective tip I can give as a tester; DARE TO ASK ANYTHING & EVERYTHING!

Test Process Improvement; Do we really need it?

Everything we do and know can or even should be able to be improved. At least that's how I look at things. If this is not the case, it would mean a complete "standstill". As a testing professional I know that nothing is perfect. And even if it appeared to be, the world around this perfect object still moves forward. So in the end even this object should improve and adapt. It’s like I said before (some posts back):

"In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change”

Charles Darwin

So if everything should be adaptable to change, the Testing process should be as well. As testers we know a lot of our own issues, but most of the time we blame the environment for it. "The developers don't takes us serious", "We don't get any budget to test what we want to test", "We're always at the end of the chain, so it's not our fault there are still some bugs in production" etc. And some of it is valid and some of it might be questioned. Is it because people don't know what testing is? Or is it because we (as testers) aren't transparent enough? Or could it even be because of the fact that we don't even know how mature our own process is?

This last question is not that strange to ask. The testing profession is not even a profession in it's true nature. Compared to (for example) lawyer, doctor or bartender, we are just beginning to find out ourselves what software testing is. But before I dwindle to far away from the subject, I wanted to talk about improving our test process. Every projects starts with the best intentions and maybe even a complete test process in place, but during a project things always change. How adaptable are we then with our standardized test process?

Using methods like TPI NEXT, we can make a snapshot of our current situation and work our way toward our (pre) set goal(s). For example, if we want to be cost effective, more effort should be put into getting the test environment more mature instead of getting our meetings formalized. But methods should only be used to support practice and not be the leading factor of your process. Let it become a tool for yourself to get an overview, insight and something to "hit" management with in order to get resources/time/money to improve and/or change.

Being at the top level of maturity does not guarantee that "all goes well". It does give some basis of a proper process at that given time. Keep in mind that every project changes and that at a mature level, so should your test process!

To state it more boldly;

"We don't want to be CMMI level 5!"

The Dolt's Guide To Self-Organization

One of the best presentations I've seen lately:

The Dolt's Guide To Self-Organization

View more presentations from Jurgen Appelo.

TPI NEXT is a big improvement from "TPI Classic"

On November 17th, Sogeti organized the TMap® day. During this day
customers and other interested people were invited to Hotel Vianen to participate in lectures and workshops. One of the themes addressed was the introduction of the new TPI® NEXT book.

This new book is the follow-up of the “old” Test Proces Improvement (TPI) book. Ben Visser, one of the writers of the TPI® NEXT book, notices: “also a book about Test Proces Improvement needs to be improved”.

The new model differs in several aspects from the previous one:

• The total number of key areas is reduced from 20 to 16. Some key areas are combined, whilst others are revised or added;


• The maturity levels are uniformed for every key area, with the levels ‘Initial’, ‘Controlled’, ‘Efficient’ and ‘Optimizing’;


• The test process is classified in three areas (Stakeholder Relation, Test management and Test Processes), with corresponding key areas.
  

But perhaps the biggest improvement of the new model is the implementation of clusters. Clusters are groups of related checkpoints, which can be defined depending on the business driver that is of most importance to the situation. This enables an improvement strategy, in which the checkpoints of the key areas that are related to the business drivers can be addressed first, before the rest of the process is improved. This brings an enormous amount of new possibilities regarding the applicability of the model within different business environments. A detailed description of the new model, the clusters and a detailed summary in which situation the new model can be used (and how) can be found in the new TPI® NEXT book.

Also, discussing business drivers and how Testing can support them, provides a possibility for Test Consultants to enter on a higher level in an organization. No longer only Testmanager and Project Managers are their counterpart, but now also CIO’s and “the business” come into view.

In the final stage before publication of the book, field tests were performed in several countries to prove (and test) the application of the new model in practice. In the Netherlands, this field test was performed in a collaboration between Sogeti and Capgemini in the UWV Test Improvement project at the Dutch Socoal Security organization (UWV). Thomas Som, Reinder Otter and Ralf van der Ven from Cap-NL conducted an extensive field-test, and . Maurice Siteur, John van Veen and Gerwin van Eersel were involved in reviewing the manuscript.

To support the use of the model Reinder Otter has developed a practical tool in which the different aspects are combined. By using the tool it is possible to create a graphical representation of the maturity level of a test organization with a single click of a button. Next to this, business drivers can be defined and manipulated, the clusters can be manually altered and different overviews can be generated. In short: to use the new model properly within a business situation, this tool is indispensable. This is emphasized by the fact that Sogeti has made the use of this tool an essential part of their presentation of TPI® NEXT, including a demo of the tool. Also Reinders’ tool is downloadable from Sogetis’ TPI® NEXT site: www.tpinext.com.

The TPI® NEXT model can be used in different situations, one of which is combining TPI® NEXT with CMMI. For this situation, Ralf van der Ven together with Sogetis’ testguru Rik Marselis has made a thorough comparison between the two models and published a white-paper about the subject. This white-paper is a good starting point to determine the TPI® NEXT maturity level of an organization that has already implemented a CMMI approach. A unique accomplishment, since so far this subject has not been addressed in so much detail. The whitepaper is also downloadable from www.tpinext.com.

It can be concluded that it the TPI® NEXT approach will create a massive following within the coming years. With the book, the tools and the white-paper, a complete package is provided to improve the test process. Feel free to look on the website of TPI® NEXT at http://www.tpinext.com for more information on how to order the book, the free download of the tool and the white-paper.