Why You Are Not A "Professional"​ Software Quality Engineer?

We all know that “testing” is quite an interesting and innovating concept in the world of Software Engineering. Earlier, the developer used to code and test. Gradually with increasing number of software, there was a need of QUALITY ENGINEERS. Why? Because testing is not only about making sure that code works as expected, it is much more than that. Requirements testing, Integration testing, Functional testing, Regression testing, Performance testing, Accessibility testing, Security testing and the list goes on, there are so many aspects to keep in mind while testing particular software.

In this article, We are going to focus on top reasons why you are not a professional quality engineer and what should be improved in order to become one.

1. Thinking that testing is all about creating and running test cases: this is the biggest myth which needs to be busted. We all have studied in theory that testing starts as early as requirement phase but very few QEs do that. Let’s be honest here, once we know the requirement, we are more into converting it into a test case and executing them. We never bother about improving the requirement to improve the quality of the product.
2. You think testing is not a technical profession, and so you don’t even try to understand the code behind your product! If you work on Software Development you should understand at least a little about software engineering. As a quality engineer, you need to be able to read code in order to analyse your product and understand how changes and fixes can affect it and cause additional bugs. The days of hiding behind “black box” vs. “white box” testing are over. You can still get away without writing any code if you don’t want to, but as long as you refrain from reading the code you will be missing a very important input to your overall testing process.
3. Non-effective communication: we all have been there when a bug is found by the customer and we were blamed. Most of us take it on our ego and get defensive about it. Testing profession demands patience and effective communication. Shouting back or getting defensive won’t take you anywhere but communicating effectively about the bug and improving the test process will definitely help.
4. Limited client exposure: During the whole QE/testing cycle, we do not really communicate with the users or the clients who are going to use the product. The only time we had done it is when support team has asked us to contact them to reproduce a bug. If we try and communicate with them about their experiences and feedbacks on a regular basis, I am sure that we are going to test more effectively and this will also help us to think from a user’s perspective.
5. Waiting for the developer to give you heads up: As I have mentioned earlier, testing starts with the requirement phase but most of the quality engineers wait for the first build to start testing. Ideally, QE team should participate with the other teams and give their feedbacks and suggestions so that most of the bugs in requirements could be avoided and also saving a lot of testing time in later stages.
6. Not prioritizing the areas to test: “enough testing” is not a term in this profession. Time management according to the priority of the test areas can help in effective testing practice. For example, the area which had the most bugs in past releases or if we have technical knowledge about the development technology and its complexity could be taken on priority. The point here is that most vulnerable and important parts should be tested first and rest of the time should be divided accordingly.
7. Underestimating Automation: there are a number of automation tools available in the market, some of them require very less coding and are simple to use. We should stop making excuses for not using automation. If we can automate our regression test cases then every time a new fix is introduced to the product, by running that suite will ensure that there are no new bugs introduced in the system. Automation saves a lot of time and efforts; we should understand the importance of automation.
8. Not considering QE/testing as a profession: most of the QEs look at this profession as a step to becoming a manager or programmer. I do agree that managing a QE team has its own benefits and perks but without proper knowledge of testing and, latest technology and QE processes, it would become really difficult to guide your team to make a high-quality product. With high position, comes high expectations. It is better to improve our skills as a QE so that we can become a good QE manager tomorrow.
9. Not improving your test plan strategy: test planning is as important as testing itself. If our plan is good, then results would automatically come out better. This also includes your skill set and learning new things which will benefit you andyourorganization as a whole. Some of them could be:What tools you should be using?
10. What were the failures in the last release?
11. How can you make more effective test cases?
12. No plans to improve professionally: as QE profession is gaining popularity, there are so many training programs and certification available for us to improve our skills and keep ourselves updated with the latest technology. Some of the examples are 

• ISTQB certification
• Training on automation tools
• Scripting languages
• Training on Bug reporting tools

    We can also conduct training sessions within the testing team to motivate     other QEs and improving our presentation skills at the same time.

Quality Engineering is a profession where a QE has to know more than others about the system as a whole and gives his suggestions for continuous improvement. Some of the things will come by experience and some we have to learn by ourselves. Becoming a Quality Assurance Engineer or Quality Engineer you care about the quality of the product and also are dedicated to improving it. There are no right or wrong ways to do testing but there are good and bad ways to follow the QE/testing process. So, these were the top reasons why you are not a professional SOFTWARE QUALITY ENGINEER. Hope you found it useful. 

References: www.qablog.practitest.com, www.softwaretestingclass.comre