Today I like to write about the role of test engineers in software industry and value they are bringing to the software development process.
First, let me ask, what kind of value does a test engineer bring to a software company? Why software company needs test engineers for their projects? I guess the role of test engineers has been changed along with evolution of software industry. Normally people say test engineers are responsible for the quality of the product, and I believe that statement.
Do we need test engineers because developers are not perfect and they make mistakes? I think that is part of the test engineers' role. I guess we had time like that. Old days, we called developers "programmers" and they are responsible for 70 to 80% of the software development work. At the end of the project, "testers" are basically verifying their work. And there were a lot of 'hot fixes' after that. The industry has found a lot of problems about that approach in terms of cost, development pace or even success of the project.
Now, we know that test engineers are required to do more than verifying software based on spec or trying different inputs from end to end testing. I think the core requirements for test engineers are clear understanding of functionality and business value of the software, good knowledge of risk and vulnerabilities of the context of the software and strong capability of test case execution.
It sounds pretty obvious, but let's go over one by one.
Clear understanding of functionality and business value of the software
This involves with test engineers participating on spec reviews and designing of architecture of the software. Test engineers represents the end user but that is not all about test engineers. Test engineers are internal people of the software. They need to understand the architecture of the software and the interactions among components. If you join a new company and want to test, first thing you need to do would be understanding the architecture and components of the software. After that, they need to think about business value of the software. We need to be able to look at software from business perspective. Now, we know the software inside and out. We understand how the software works and how it is used.
Good knowledge of risk and vulnerabilities of the context of the software
This has a lot to do with your expertise or experience. Every software is different. I think understanding of vulnerabilities of the software you are testing is really a crucial part of your job as a test engineer. What is the risk of developing client application? What is the risk of developing web/network application? What is the risk of developing mobile application? (My plan for next blogs is focusing on risk and vulnerabilities of different context of software.) Test engineers can execute a lot of test cases on a software, but it is hard to evaluate what they are doing is exactly what software testing needed for that particular context. Software quality comes from extensive testing on risky and vulnerable part of the software. Understanding of the context of the software is worth emphasizing.
Strong capability of test case execution
This is pretty personal matters. Software development business or any kind of business has time and budget constraints. If your organization has enough resources and can afford them, that would be great. I'm trying not to talk about details of manual testing and test automation. Good test engineers need to come up with best method to execute the test cases. Some test engineers are obsessed with test automation. Some test engineers are not bothering to consider automation. We need to be able to choose best method for executing test cases and should be able to handle them. If you are not good at test automation, go back to library and study it. Understand code quality and maintainability of the software. Study about design patterns and best practices. If you think you are obsessed with automation, sit back and think about how can you use intelligent human brains and senses. There are absolutely many places where manual testing work better than automation. I remember Jame Whittaker at Google mentioning 'User experience code and infrastructure code.' Basically, manual testing is better fit for sophisticated user experience code testing. And test automation is better fit for internal of the software. I agree with his point. But in practice we cannot separate them strictly I guess. But spend some time think about which method would be better for a particular test execution rather than going with your favorite method.
