The role of a QA engineer is sometimes unclear. It’s seen as the “guy who can break the application.” With a lot of work and effort though this concept has changed for good. Now, the QA engineer is embraced and even demanded by development teams, and seen as an critical partner in software design and development. Why is the QA engineer role crucial? Here’s a list that shows just what can happen if QA isn’t executed well.
Twenty ways to fail as a QA Engineer:
- Think it’s ok to have incomplete or ill-defined requirements. Someone else will fix it.
- Use invalid inputs to break the application. The development team needs more pressure.
- Consider only the “happy path” when developing test cases. Never consider alternative paths. Alternative scenarios don’t matter.
- The shorter the defect list, the better. Trust that developers will find the errors. We shouldn’t take much time of a developer by adding extra steps on how to reproduce the defect (this applies also to: adding videos and screenshots).
- Focus ONLY on my job, and report progress only to my immediate superior.
- If the application fails despite test cases being executed and passed, leave it to developers to identify and figure it out.
- It’s not necessary to help with process improvements. That’s your project leader’s job, not yours.
- If you notice that your assignments don’t have the necessary scope to cover the whole requirement you shouldn’t raise your hand. This job will be done by your Scrum Master or Project Leader.
- If you’re stuck on a testing task, keep working on it until it is complete. Never ask for help from any team member (QA or Dev.). It will take valuable time away from the Developers or QA.
- Say “ok” even when you don’t clearly understand the client’s requirements. This will say to the client “we got the idea…” even though we did not understand what the client said.
- Rely on all communications to come from the project leader. The client doesn’t want to be disturbed with simple or silly questions.
- Being in an Agile project means that we won’t need to document everything. All the testing is done “on the go” and we don’t need to develop test cases.
- Am I in a Waterfall project? That’s good because we won’t need to update our requirements till the end of the development stage.
- If a test case passed, there’s no need to run it again on new deployments. Just trust in a simple law “a passed test case will never fail again.”
- We should only be doing functional testing. If we only test the system’s funcitonality we will guarantee superior quality.
- We only need ONE test case to cover the whole requirement, even if it makes the test case huge.
- Automating our project means we can eliminate some test strategies such as Functional and Regression tests.
- Recommend that the engineer test everything on the developer’s machine. This will save time in making stable deployments.
- When finding lots of defects during testing, that’s a sign that you’re doing a great job! There’s no need to check first if the environment that you’re testing on is stable or if it has the latest version, or if the database has got the right data.
- Remember… “there’s no ‘I’ in Team…. and there are no QA’s in a development team.” You should never post blocking or high impact defects because that will bring a lot of bad “karma” to the team and developers might look at you as the bad guy.
The role of a QA engineer is about much more than just testing the application. Besides testing the appliation, a QA engineer needs to ensure upfront that all of the software requirements are detailed and complete to enable the development team to accomplish what they need to do to avoid the need for last minute changes or even worse, needing to start from scratch due to misinterpreted requirements.
In addition to analyzing and supporting overall requirements, a QA engineer defines and recommends which testing strategies and testing tools (of course, this depends on the QA’s seniority) to use as well as help improve the whole development process, including the testing stage.
Being an effective QA engineer doesn’t mean just reporting failures or defects, then not being a part of the process that follows. The QA engineer must have a functional and active role on the team, and in team meetings. He should do a joint analysis of the requirement, working side by side with developers.
The main goal of a QA engineer, aside from detecting defects, is to be able to provide a well defined “guide” for the developer so he can then reproduce that defect. It also includes providing, when necessary, suggestions or process improvements for the requirements based on his technical knowledge and his business expertise, offering an objective vision of the problem.
