There will always be smart technical people who do not like to code. There will always be ways of taking advantage of their talents.
I'm a coder. And I love my manual tester. She see's the world differently than I do and that's exactly what I need. What I hate are manual test scripts that pile up without any automation behind them.
The solution isn't to ...
I'd like to address the reporting aspect of the question. You say...
I just keep on writing excellent test cases and executing them, but then I don't have anything to show to the management. Sometimes it makes me think that I am not providing any value to the product
Even in the perfect world where the software leaves the developers' hands 100% bug free ...
Testing no longer means testing
Confused? We can imagine! The purpose of testing used to be fairly
clear–“Testing is the process of executing a program with the intent
of finding errors”. This changes when adopting agile and
I think the testing manifesto has it at the right end. Focus on preventing defects over ...
If request sounds reasonable (which includes taking into account my other priorities), I would spend some more time researching.
If not reasonable, I will respond "sorry this is the best I can", and if my polite refusal to spend more time researching is not enough for the developer, I will ask my manager to make the decision. I would also mention to ...
There will always be bugs that get past a tester and land in production. I have even had bugs that where in my face, we researched it, thought it was a fluke, because we couldn't reproduce it and then released the issue into production.
The best thing you can do is learn from it and prevent the same in the future. I write an automated test-case for each ...
As others have said: code review.
It is not uncommon for code like assert true == true to be used as a placeholder during test automation development (I personally would use assert true == false or assert fail or similar as my placeholder so my code could not pass until I was ready to write the correct assert, and so there was no chance I would forget the ...
Test automation can NEVER replace manual testing.
One classic argument is test automation can never catch random bugs that can be caught via manual exploratory testing.
I have had two colleagues in the past who did not know any coding skills and hated coding, but they were extremely good manual testers, were able to catch bugs no one else could.
As Joe Strazzere explained, it is a matter of discussion between devs and testers. The question is what factors to consider in such a discussion. I think Danny R. Faught explained that pretty well in How to Make your Bugs Lonely: Tips on Bug Isolation.
There is no clear dividing line between the bug isolation and
reporting that the tester ...
There is no standard anything in testing.
In very broad terms, all testers need to be observant and good communicators. Outside that, it depends.
First, there are several broad fields of testing, including:
Expertise in one area is no guarantee of expertise in another.
Second, there ...
There's not enough data for any trend to be clear.
You found ~26 bugs in the last half of May. You found ~27 bugs in the first half of June. If the bug discovery rate keeps going like this, you're projected to maybe find 40 bugs in the month of June (40 being somewhat conservative).
So you have potentially two data points: 26 and 40.
Consider this ...
No matter what else you do, you will need your team lead's approval before you act.
I recommend that you take some proposals to your team lead, after you have done the following:
Measure skill levels - find out just how much skill you and your fellow team members have with coding and designing automated tests. There are plenty of online tutorials and ...
I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would ...
Short answer: it depends, but in my opinion: YES.
Long answer: it depends... on the company, projects and business.
As a senior test analyst, you possess all the necessary strengths that make a great tester so valuable. In addition to what you've mentioned:
analytical skills (from a testing perspective)
for example, you're that guy that ...
Can a Manual Tester survive in software industry without learning Automation?
Survive - Yes, but be valuable and desirable on a job market in the long run - No.
Let me expand on this thought.
You can, of course, grow as a professional doing manual testing only exploring new techniques and methodologies, testing different products in various industries ...
I will answer this question with Agile iterations in mind. (An iteration could be a full Sprint or a single-user-story-cycle if you do Kanban or swarming.)
The QA department is understaffed when:
Not every cross-functional Agile team has a someone with QA knowledge
The ratio defects versus released features is getting out of control
Test automation is not ...
We have several "testers" who are involved in manual testing and test
automation, but all of that part-time. Some of them are not really
interested in testing and test automation as a field and lose interest
in test automation and improving testing skills pretty quickly.
How should we deal with them?
That depends on why you have uninterested ...
Many companies I've worked for shared a policy...
...and that policy is:
Testers are free to consult with developers while attempting to characterize, isolate or reproduce anomalous behavior.
Once a tester can document the steps necessary to faithfully recreate the behavior, the developer should be able to take it from there.
Developers are free to ...
As per my experience, it's very difficult to get a right employee who has very good judgment, sharp focus, attention & great observation skills.
Earlier it was very difficult to filter right candidate but our team come with some solution for that We made some minor changes in our interview process as follows:-
Now before conducting F2F ...
I'm always on the lookout for grammar and spelling errors - purely because we're here to assure quality, and typo's aren't professional.
It's usually not the developer's fault because they just copy + paste it from a requirements document or something similar, and testers are more likely to catch it.
As a consumer - if a company can't spell properly, I won'...
There is a gap in communication between you and your senior management.
Personally, I do not think senior management take the first bug discovery diagram too seriously. It is merely an idealistic guideline which perhaps never happens in real life.
I speculate that the reason your senior management questioned your competence or commitment is perhaps you ...
Some bugs may take days to track down and report correctly (to be reproducible). And if bug is not reproducible, bug report is worthless.
Tell your management: "be careful what you ask for: you will get it". If they want to count the bugs, testers will enter big number of trivial bugs but would tend to ignore bugs which take long time to report properly.
But, what are the general ways to avoid having or deal with such
conflicts keeping the relationship between the teams healthy and
Both QA management and Development management must come to an agreement regarding the ground rules of bug reports.
In some shops, more detail is required before the bug report is sufficient to hand off to ...
My personal preference is to share resources across features and even products. While working on a single feature or product does increase specializing, that in itself has some associated cons:
If the person specializing in a feature has missed something
important and everyone else is not familiar enough with what they
are doing to notice it, that could be ...
Apart from obvious activities like test data creation, test case
execution, bug reports...what other initiatives can a QA engineer ,
take which will help raise his value to the project/Client.
You can only do what the situation and context permit you to do.
In some shops testers get to review the Requirements before they are finalized. If that's the ...
My testing motto has always been this. "The purpose of testing is to reduce the risk of implementation." I have always found that when a testing organization is graded simply on the number of bugs that are found, it is very inaccurate. If you find a large number of bugs, is that because you are that awesome or your developers are that bad. Or in your ...
Review test automation code.
Run each automated test at least once before you write the code it will test. (Of course, this means you'll have to write the test code before you write the code it will test.)
Right now you might not see much need for a single repository design. Later, you may find your opinion changes.
You might want to use a single repository if
you need to keep your different projects in sync. It's more difficult to keep separate repositories in sync than a single repository.
your team members will need to switch between ...
For a QA guild I would consider some of the following:
Lunch and Learns
Demos to non-guild members
Rewards, awards and presents
Internal Testing Conference Day
External Conference Group Outings
Bi-weekly meetings on topics of interest
Mugs, hats. t-shirts, etc. with QA guild on them
Slack channels within the existing workspace (or ...
In addition to the other answers, it would seem important to me that you find out IF you are actually letting bugs slip through. The way you write this would make it seem the software is up and running in production, so surely if there are bugs they would be reported. Then you can check if you should have been able to find them or not.
I would also ...
Virtual Knowledge Area teams:
We have been experimenting with setting up Virtual Knowledge Area teams (e.g. communities/guilds) as actual Scrum teams. The team consists of specialists or people who like to get deeper knowledge in the teams' topic area. They have a Product Owner, a person who creates a backlog and has the final say in prioritization of the ...