When can I say I have enough resources to start testing activities?

Question

I am kind of new to testing and I am still trying to get a good footing on what to do based on the theory given from the ISTQB.

The exercise of moving from the general guidelines in the Foundation Level Syllabus to something more concrete has been challenging; that's why I'm looking for assistance.

Right now, I'm going through the syllabus trying to see if I'm in the right mindset to begin making use of what I learned, and this question seemed to be a good place to start.

In class, we were shown a small extract with guidelines for a mobile app, and were asked if that was enough info to start testing activities or if we would need more information? Then follow up with what kind of information would you ask for.

I said that since the syllabus recommends to start testing as soon as possible, it should be enough information and that if I were to ask something it would be: who could work as a point of contact to discuss more information if I ever need something, like clarifying the assumptions I made out of the guidelines.

Another classmate said that we could not start until we got an idea of the context surrounding the testing process and would ask what kind of developing model they would follow, if they had any test types in mind and if they would want us to follow some standard, etc.

Our answers weren't denied but it seemed that the question was more in line with asking about resources and identifying when was enough to start with test planning.

After asking my teacher, the idea I got is that we have to first define a test basis by collecting resources relating to that specific testing process. The example app is an insurance app to report fender benders and to do the follow-up process for the East Coast of The US. For that, we could have asked for:

• Where are the privacy policies for the states that the app was going to be working in.
• A description of the flow of information within the insurance company, the persons involved in the follow-up process, etc.

I am not familiar with how insurance companies deal with accidents, but by looking at how they work there are a lot of resources I could ask for, but even if I think I have somewhat of an idea of what I should ask for, I still don't feel sure to say when I have enough information to start planning.

My question tries to ask in general how much information is enough information to start with test planning and the rest of the testing process?

Thanks in advance for any advice.

Answer 1

Lets answer from a experienced QA perspective.

Testing is not an after thought , it is a process that needs to be integrated to all stages of SDLC. We have moved a long way from waterfall model where we waits for information or final product implementation to start testing. We also have moved away from agile where we used to split the entire project development into smaller iteration and work on it as smaller waterfall models. Agile indeed is a great methodology that adds agility and welcomes changes and is not static like waterfall where requirements cannot be changed once development starts. This because in agile , when a new requirement comes , it will be added to project backlog and then will be taken up in future sprint and is delivered as part of that sprint. So new changes of requirements are always welcomed and is delivered in future sprints. But the issue was that development team was still isolated from deployment and ops team. so we came up with new methodology called DevOps

in Devops , the three pillars are to collaborate , integrate and automate . Here we collaborates different teams like development , testing , deployment etc to identify processes that could be integrated and automated . This allows faster development and release cycles and there by provide better return of investment.

Now coming back to your question:

When to start testing ?

I am sure you might have read about 7 principles of testing, and two important principles are "early testing" and "absence of error fallacy"

Early testing:

This principle states that the testing should start as early as possible . Means it should start even from requirement phase. For example you are domain expert in banking field, and you where not part of requirement gathering. Your marketing team goes out to a client and promises they can deliver a feature that was actually illegal in the jurisdiction that your customers are in. Your marketing team was not aware of this but they made a promise that cannot be fulfilled and this costs the organization business and reputation.

so instead if the team had a domain expert like you who knows in and out of banking sector , you would point out the bug in the requirement and can strike a better deal by giving proper remedies.

"Absence of error Fallacy"

Absence of error fallacy means you create a product that is highly stable , no bugs etc. There is no error in the system, but the product features was not what the client wanted , as there was no proper testing or validation of requirement and verification during development process no one checked whether the development process is aligned with the actual requirement. This creates a useless product that makes the organization lose money.

Instead if we had proper validation of requirement, design etc by a expert test engineer who knows indepth about the domain , there will be questions and objects raised to rectify the mistake earlier itself and stopped this situation from being happening.

so answer is testing should start from requirement phase itself , bugs should be raised against requirement , design , decision , process etc.

Testing is not just about validating a output against expected output, its about providing validate feedback that can improve overall process and product

Read more about experience based testing

Answer 2

Many things in testing just can't be figured out before you actualy sit down with the product and start interacting with it and testing it. Having a plan is useful, but trying to overengineer it is not.

Trying to completely figure out the plan before diving into testing sounds to me like a classic waterfall set-up, which will probably be frown upon in many companies today, and just won't work for you in general, because what you'll encounter during testing can't be completely predicted in advance, so you will encounter situations you didn't take into account when planning, which will make your plan much less accurate in the end.

What's much more common in companies that have at least partially moved away from waterfall is you plan in about 1-3 week long periods where your work is divided into many small tasks that each individually take just a few hours maximum. Doing it like this makes all plans a bit more accurate because it's easier to get right something that's small and takes a small amount of time than to plan your next half a year on a project.

I said that since the syllabus recommends to start testing as soon as possible, it should be enough information and that if I were to ask something It would be who could work as a point of contact to discuss for more information if I ever need something, like clarifying the assumptions I made out of the guidelines.

This sounds ok to me. I'd start by learning the application, and slowly getting more into testing. During that, I'd also get to know the team and the business side of it. And during all that, I'd definitely have many questions. The point I'm also trying to make is you don't really know what information you miss until you encounter a situation where you're in need of some info that you don't currently have. It's like with bugs, you can't tell for sure what bugs you will find until have experienced them in the product. You most likely get better in predicting that when you've experience within that field/with that kind of app etc., but still, you will never make an accurate prediction.