BVA test case generator

Recently I read a post about a online tool which can generate test cases based on boundary value (BVA). After a reader of my blog also attended me on this tool I made the free subscription.

On TestersDesk.com you have several tools which I think can be useful like:
- Pairwise TestCase Generator
- Boundary Value TestCase Generator
- N-Way/Random TestCase Generator
- and some more

For example the BVA++ generator is very easy in use, although it doesn’t cover the boundaries we don't know it can be useful .

If you know the values you want to test it is just minutes work to generate the list of cases you need. (within seconds).

I believe this tool can be useful if you have less time available and there is less risk in the functions you are testing. You can use it for:
- generate fast a list of cases you need to cover
- calculate how many time you need to perform those cases. If the generator gives you about 25 cases and you assume that each case will take you about 1/2 hour to execute, you at least know that you might need about 12,5 hour for execution. It can help you to identify in a few minutes how many time you might need to test a function
- the generated cases can also be used to check whether the already defined cases are sufficient.

One of the items I missing here is that you cannot get a list of the total cases so you are able to pick from the total list (if it is there I have missed it.)

How many documents can you create?

Often I hear the saying a good tester is a lazy tester. This doesn't mean that testers don't want to do nothing; it is just that testers just want to do just that what is necessary. Like why execute all 1000 test cases if based on test techniques these can be minimized to a number of 52?

Over the years I noticed that to control projects a lot of documentations is created. This made me curious about which types of documents I had to deal with or might have created if I follow the methods like PRINCE2, ISTQB, TMap or others.

Here a list of documents I had to face with:
- Project assignment document
- Initial test advice report (before actual testing starts)
- Master test plan
- Risk analysis report
- Product Risk Analysis Template/ checklist
- Product Risk Analysis report
- Detail Test Plan (for each phase one: SIT, FAT, UAT, PAT)
- Test strategy checklist
- Test strategy document (finally it would become part of the MTP and DTP)
- Weekly progress report
- Daily progress update report
- Daily progress templates (to gain information from for the daily progress reports)
- Deviations report
- Phase end report
- Escalation reports
- Logical test specification document
- Physical test specification document
- Test Script
- Test process dashboard
- Intake test basis checklist
- Checklist intake test tools
- Checklist test process evaluation
- Test Process Evaluation report
- Test Process Improvement Checklist
- Test process improvement report
- Checklist test techniques
- Test schedules
- Test estimation document
- Defect registration
- Defect screen print templates
- Test Execution Quick reference cards
- e-mails
- Review template
- Review report
- .....

Of course there are some more documents I had to face with. Looking at this list I just wonder: Is there still some time left after generating these documents to actually perform tests? Of course these can be all useful documents. We should continue asking the systems and the processes questions and preserving the outcome of it. Only: are we working for those documents or are those documents work for us?

Why test management tools can cause pain

I'm aware of management tools who claim to support the testing processes. Some of them can be very useful because they can provide information about the number of defects found, number of test cases created and executed, coverage of those cases related to requirements, and more.

This morning I asked myself why I start projects most of the times using MS Excel. In most of the cases it is because of the lack of test management tools. On the internet you might find all kinds of whitepapers why we should use these tools. It can be easy to convince people why to use it. It might be harder to explain people when to use it. It might be even harder to make people think why not to use it.

Here some points which came up in my mind why it wouldn't be wise to use tools:
- When management didn't decide yet what information they need to make decisions;
- When projects are successful because they have the flexibility to adapt their development process and test process based on their situations: multiple test approaches are used;
- When it takes more time to convince users to use the tool and actually using it instead of working (i.e. testing);
- When people start trusting on the information provided by the tool instead of using common sense;
- When the tool provide too much information which distracts people for the real goal of the project;
- When the tool is used to punish people instead of measuring progress and risks.

I think it is important when certain tools are used they are not dominating your test process and forcing you to make decisions how to act because it won't fit in the tool. Tools shouldn't dictate, it should guide and help. They also should leave space for creativity. Management should be aware to judge the information provided by those tools any time.

Two heroes dealing with uncertainty

Last weekend I was surprised by the persistence of my children which made me proud. Even thinking at that moment how they dealt with the situation makes me still give the proud feeling. Perhaps there are some similarities between their situation and projects we have to deal with.

A few weeks ago my son asked me to join a family event organized by his sport club. The event was a cycle tour through our region. As my children like to cycle in our neighborhood, the thought this was a good idea. So we decided to join that event without knowing what situations we would face. My son is 8 years old and my daughter 6 years old and as normal healthy children they complain whenever. I already calculated that a tour of 20km would be possible for my children to succeed without fewer complaints.

When starting the tour I asked what distance we have to cycle. The organizations claimed it would be between 30 and 40km. After a short discussion with my wife we decided that it would be acceptable although it was raining a bit.

During this day we had to face some challenges:
- not knowing what route to follow as after each track ended with a new piece of the map
- not knowing where to finish
- not knowing what whether to face with
- not knowing what quality the roads would have
- not knowing the unknowns on the route

During the day my children didn't complaint at all, although there were reasons to do. They already made me proud as at the end it turns out we cycled over 60km. Cycling this number of meters is already hard for a person who didn't touch a bicycle for a few years, imagine how hard it has to be for those children on those little bikes.

Afterwards it made me think why we succeeded and why they didn't complaint.
The following reasons came to my mind:
- They accepted the uncertainty
- They trusted me as guide
- We helped them by pushing them when wind was tougher or roads are steeper without they asked for it
- We listened and watched when we assumed they needed a short break
- We called the organization when we got lost
- We decided not to participate in the last track and go straight forward to home. Although we had to cycle still about 10 km. Cycle straight home is better then keep playing the last game with the risk to lose direction and stop more often which would cost a lot of energy
- We rewarded them by telling how good they are doing, how proud we are
- We focused on the beautiful environment instead on our burdens

When looking at these reasons I see some similarities with projects I delt with. Perhaps you also were in projects when things are getting tough people are starting to complain. To avoid this perhaps the following actions can be taken by the project manager/ test manager:
- Make people aware of a certain uncertainty so acceptance is easier
- Make it visible when you ask for help and for what reasons
- Help your project members before they start complaining, reducing the pain before they feel it can help avoiding focusing on that feeling
- Make the team focus on what is happen in the big picture instead of focusing on what goes wrong
- Don't stretch their capabilities for to long, give them a break, although there is time pressure
- Keep telling them when they do things right
- Be open, don't focus on the problems you have as management, keep eye for their situation
- Make the fun happen

There is more behind

When I am allowed to talk about testing I can get thrilled about this topic. People can see in my eyes that I love this profession. Over the years I met several people I had to work with. Sometimes it was easy to convince them about the meaning of testing and sometimes it was hard to test together.

I think there are several types of persons you will face during the job who need different information

1. People who have not any relationship to testing and are interested in what you are doing
2. People who are ordered to test, without knowledge about testing
3. People who are asked to test and want to learn about it
4. People who want to understand what you are doing, without testing
5. People who are dedicated to testing as you are and want to share knowledge
6. People who are dedicated to testing as you are and don't accept your knowledge
7. People who don't want to do anything with testing and just want you to do it
8. People who don't want to do anything with testing and who don't care

Talking about testing cost time and effort. I think it is important to spend those resources wisely. Therefore before you share information you should identify those types what type of person you are facing with. It will help you to avoid losing those people and spending the wrong effort.

If you acknowledge these types you can train your selves as the message will be different for each type. In your group of stakeholders there might be people who have something to say only don't have the time to listen.