A full-stack QA engineer needs to know the product well and understand how to test it from the user’s point of view. They should be involved in the early stages of the feature’s development, so that they can share their advice and experience from a testing and user-perspective. Fewer defects are introduced by developers if the QA engineer is involved from the start, which includes defining the feature’s requirements.
A feature-level perspective is critical – just because none of the user stories have defects, it doesn’t mean that the feature as a whole works well. At the beginning of the feature, QA should be involved in feature elaboration to understand and influence the end-to-end flow, and come up with the usage scenarios that will be supported by the feature. After the user stories and features are complete, the full-stack QA engineer will test them, and ensure the flow is correct.
The full-stack QA engineer needs to understand how users use the product, and is concerned with its usability. Security testing is important too – it’s not only relevant for applications that maintain sensitive or private data, it is also concerned with the availability of the application. The application’s services must be ready for us and available to authorized users as and when they need it, which requires the QA engineer to examine the software from a security perspective. Similarly, the full-stack engineer will be a competent performance tester, since many of today’s applications are high-end web apps that are accessed concurrently by potentially millions of users who expect a flawless user experience.
The full-stack QA engineer will work with the developers to understand a feature’s architecture, how it’s implemented, and the technologies used. This will help them determine how best to test the feature. Consider, for example, auto-complete on a selection list. The QA engineer will consider issues such as: the time delay to refresh the selection after typing a single letter; how to test the event that triggers a REST call to the backend service; how the UI layer behaves if the backend service is broken; etc. The full-stack engineer doesn’t need to know the actual code of the application, but a deep knowledge of the implementation can raise some very useful technical questions. This helps the team as a whole to think more carefully when implementing the feature, and prevent defects from reaching the end user. Testing is treated more as defect prevention than defect detection.
Full-stack QA engineers must think about test efficiency. Investing in automation is critical to repeatable testing. The tests themselves can and should be automated, but so should data or environment preparation, which is time-consuming and error-prone when done manually. The engineer will use their understanding of the feature’s architecture to design effective test cases that maximize coverage. For example, a new feature on a typical Model-View-Controller web application might have a browser-based user interface, and a REST-based API to access the back-end.
The QA engineer can test the API layer before it’s integrated with the user interface. Similarly, testing an application through its API is more resilient and efficient than testing it through its user interface – resilient because APIs tend to change less frequently than the user interface; and efficient because testing through the API is quicker than testing through the user interface, and it’s easier to validate the data it returns. Some user interface automation will still be performed, but the full-stack QA engineer will consider the best strategy for automation.
Software development organizations must nurture and grow full-stack QA engineers. As a tester acquires the skills of a full-stack QA engineer, their influence on the product’s direction and quality will increase. An experienced full-stack QA engineer is also a product expert, quality advisor, and risk analyst.
theFullStackQA 