The Quality Assurance role is one of the most essential roles in the Software Development Life Cycle process, however, it seems to be one of the least talked about. The QA role goes by many names such as QA Analyst, QA Engineer, Test Engineer, SDET, etc., but the job focus remains to stay the same, to thoroughly test applications.
What is a QA Engineer?
Now that I have hyped the role up in my introduction you may be wondering, what does a QA Engineer even really do? When an application is conceived as an idea, it SHOULD go through the proper Software Development Life Cycle which includes it being developed, tested, and then deployed to an end-user.
A QA Engineer’s role is to test and make sure that a given application meets certain requirements before it can reach an end-user. This is done in the process of creating tests, running the created test, and then documenting the results from their test. Any time a test has results other than what was expected, a defect or bug should be created. This should then be relayed back to team members to see if its priority level is high enough to need a fix now or could be fixed later after the deployment.
How do you create tests for applications?
For each application that they are testing, a QA Engineer should create a test plan. In the test plan, there should exist different test cases that represent the different possible scenarios that the application should be tested for. In the test cases, a test script should be created that documents the exact steps for performing the test case.
The test plan should cover all of the requirements presented in the requirements analysis step of the SDLC as well as other test scenarios that they feel are adequate. Because part of creating tests may involve using the QA Engineer’s best judgment, it is important that they familiarize themselves with the application as much as possible. They must also be able to think from an end user’s perspective to make sure that different possible user interactions are covered in the test plan.
What are the different types of QA Engineers?
There are 2 different types of QA Engineers, manual testers, and automated testers who are sometimes also called Software Developer Engineers in Test(SDET). Some businesses have 1 or the other, while others have a hybrid mix of both. Don’t forget they both have the same goal, to adequately test an application.
Manual testers perform their testing by manually going through the workflow that is written in the test cases for their test plans. Automation testers create an automated script using code that relates to the test cases for their test plans. There are pros and cons to both, which is why it is optimal to have both as part of your testing team. An example is automation test can run faster than manually running a test, however, many automation tools have limitations such as not being able to handle things such as reCAPTCHA.
What software do you use as a QA Engineer?
Depending on the company and framework, you will use different software and applications to do your job. For test cases, defects, and bug tracking you may use tools such as Jira, Backlog, IBM’s Rational Collaborative Life Cycle Management(RCLM), and Azure DevOps. The most common tools for automation include Selenium, Appium, Rational Functional Tester(RFT), and Postman.
What are the different types of testing?
These are some of the different types of testing that should be included in the testing process.
Unit Testing-testing the smallest piece of code that could be isolated in a system
Integration Testing-testing 2 or more modules of code that interact with each other
End To End Testing-testing complete behavioral flow of the application
Performance Testing-testing how stable a system performs under a particular workload
Security Testing-testing to confirm information is adequately protected in a system.
Why are testers even needed?
Every successful tech company has a quality QA team. Quality QA Engineers can make or break a company. Especially with the growing number of competitors in every field increasing daily, one bad release can be the end of a company. Imagine if Apple never tested their iPhone 1 back in 2007. There is a good chance it may have been filled with bugs and thus lead to a horrible end-user experience. Then everyone who took a chance and purchased this first iPhone would communicate to everyone else they know not to buy these devices.
The company would not only lose money because of this initial iPhone release but may also lose the opportunity to gain future customers because of their new bad reputation. Customer loyalty and retention is a big focus for every company. This may have resulted in not enough support for any future iPhone releases.
Comments