How should a fresher in testing handle the final stage of testing?

Question

I have 4 years of previous experience in support roles. Now, I started working for a new company. Initially, I was told that there is some specific requirement that they are trying to map me, so meanwhile I was asked to do some testing work in a project. I've never done testing before, and there is no one to help me in that project. There is just me and my manager. So, I am the only one doing QA for this application. The application is being developed for the last 9 months, and I just started learning the application and testing by myself without any guidance. I've tested the application multiple times, atleast thrice daily, and found a lot of bugs. Now, that the application development is finished , the manager of the development team started scolding me saying that QA team(which has only me) not doing proper testing from a user point of view, and he is saying that he can find more bugs than me. And my manager says that if the application is released, and user finds new bugs, the company reputation will be spoiled and everyone will start blaming QA team.

I have no idea what's all this, but I feel pressurized. Can anyone suggest what should I do now ?

Answer 1

Quality(QA) is shared responsibility of the entire team. This needs to be realized by all. Sooner is better than later.

In the absence of formal software requirements, I would put together a basic test plan based on my understanding at least to define exit criteria to know what to test and when to stop. Then I would share & clarify the expectations from testing from all stakeholders. After lot of back & forth communication once all parties reach on same page, I will take their sign-off and complete testing in accordance to that plan religiously.

This might not go smooth and become bit chaotic however this has to happen at some point, sooner is better. This will give me something tangible to work upon and even if they disagree in some major way with my understanding of overall test requirements, this will be useful as a first stepping stone for starting off formal communication between all stake holders & reaching towards a consensus.

I would play more of a 'facilitator' in this conversation between stakeholders.

Effective testing is all about effective communication.

Answer 2

I would write an email to whom it may concern (that dev lead, your manager and possible a manager of they both) where I would describe the situation from my point of view. In that thread I would try to synchronize the following:

• What were the original expectation from testing
• What were the initial conditions you started from (no experience, no requirements, no help)
• What are the examples of "bad" bugs from your side (as per dev's opinion)
• What are the examples of "good" bugs
• Why do they think the situation got out of the control
• If there is any level of testing on dev side and how reliable is it assuming there is no QA testing performed.
• Is there a chance to involve 3rd party testers to improve the situation

So having all visions synchronized you can move forward to elaborate the solution for the problem that would take all the parties to the balance point.

If they won't "meet halfway" I would consider the option to find more adequate project to work at.

Answer 3

Take a look at the seven testing principles.

It's an unrealistic expectation for you (or anyone) to find all defects within a system.

I understand why you feel pressured, but being stressed won't achieve anything. Instead, try and work with them to resolve the defects you've raised. Give the defects you've found a priority and severity, as that will provide the developers a list of issues to focus on first... and shows any management that you're raising issues all over the place.

Also, finding defects isn't a competition... and the fact that the development manager can find more defects than you doesn't reflect well on him or his team. It's bad management, and doesn't put his team in a good light either.

They could help you out by unit testing at the start, or taking part in user acceptance testing at the end (i.e., using the application as the user would). And if they're not interested in working alongside you, then I'd start looking elsewhere.

An 'us vs. them' culture isn't productive, and will always be destined to fail.

Answer 4

This is a kind of thing that sometimes happen in software testing companies having small project. In this situation you can do following things:

1. Talk to your manager in detail about the situation.
2. Sort down the product in different modules.
3. Start with module wise testing and reporting of issues.
4. If the number of defects are high, provide the count to your manager and your manager will talk to Dev manager and will showcase the amount of bugs hence resulting in poor coding.
5. Accordingly create an estimate for all the modules and provide the timeline to your manager.
6. Also take the the time of validating fixed bugs in the estimate.
7. When all modules tested than test the integration of all the modules.
8. If the timeline is high then also create test cases.
9. Run multiple cycles of the product before giving go-ahead.
   10.Send email for the Patch request to the Dev and QA managers when you find any blocker.

Answer 5

Welcome to the testing world! It is full of half-baked ideas and people, who misunderstand software development and testing role in it.

Based on your story, I think you are doing pretty good and I would love to see you staying in testing (but maybe not in this particular company where you currently work).

1) Don't break under pressure.

2) If quitting job is not an option for you right now, I suggest you to take a look into risk-based testing (RBT). You cannot find ALL the bugs, so management has to identify risks and you look for bugs area which is affected by the risk. Very short introduction: https://en.wikipedia.org/wiki/Risk-based_testing Longer introduction with detailed risk based testing approach: https://www.guru99.com/risk-based-testing.html e.g. what exactly is a risk for companies reputation?

3) Manager of the development team is responsible for software development, right? In his place I would not brag about finding a lot of bugs, because it means he did bad job.

Answer 6

I agree with Alexey's approach of having an official communication with the concerned stakeholders (in such cases - the sooner, the better). In addition to the points already mentioned, I suggest you could also elaborate on the following:

• Your current approach to testing the application: Was there a requirements document shared with you? Did you use this and any other documentation (or discussions with the development and/or product managers) to prepare your test cases?
• Test cases documentation and bug reporting: Do you have any documented test cases that have been peer-reviewed by the team? Any missing scenarios identified as a result of these should also be documented. How about reporting of bugs - do you use any tool (like Jira) for this?
• Timelines of the product/feature releases: Do you have clear timelines mentioned? How is the testing planned around these timelines? The bugs that are being missed during testing - any root cause on why they were missed? Were they related to having insufficient product knowledge due to any number of valid reasons?

You get the idea. Since you haven't really worked as a QA and have been pushed into the role, you may or may not be aware of the processes around manual testing. Your team may want to invest in a dedicated QA team that follows a well-defined process to meet their expectations. And if you are really keen on working as a QA, having a team with one or more experienced QA to learn from would definitely help.