Feeling lost as a new Quality Engineer (QE)?
Are you just starting your QE journey and feeling clueless on how and where to start?
If you are feeling so, here are some pointers to begin with!
1. Understand the product you will be working on
Before you can do anything in the team, you must know the basic information of the product so that you will know how and what to plan for your testing. Information, such as:
Nature of Product
Type of Product
Is the product web-based, mobile, or both? If it is a mobile app, is it a native or hybrid app?
Duration of Product Development
Is the product development short term (release within 6 months)? Will there be any new features or maintenance thereafter? Is the project long term where there is a need for maintenance and ongoing new features to be developed after product release?
Data Classification of the Product
It depends on how your company classifies the data. Below are a few types of classification:
Once you have some understanding of the product, it’s time for you to get started on test planning!
2. Understand what is required of you as a QE
Your role as a QE is, of course, to lead in the quality of the product. As testing in agile is a team effort, all test documents must be written in a way that they can be easily understood and stored in a knowledge management system where they can be easily accessed by everyone in the team.
Plan the test scenarios and acceptance criteria (ACs)
How should the test scenarios and ACs be documented in such a way that everyone in the team understands? You can consider documenting the test scenarios either the same way as the ACs or using a mindmap. The team will need to standardise the format of the mindmap to make it easy to understand.
Having good documentation of the test scenarios can help:
- to onboard new team members and get them up to speed, and
- the team to validate the test coverage of the product
Store the test documents
Where should the test scenarios and the ACs be kept? For easy reference, you can consider keeping them in the knowledge management system.
Set the scope of testing
Here is a list of common types of testing we recommend you to start with:
- Functional test
This is to ensure that the product features work/behave as expected.
- API test
This is to ensure that API call satisfies requirements, performs data validation and sanitisation, contains secure authentication (if required), and follows the web services standard.
- Integration test
This is to verify that the different features of the product can work properly together as per the required functionality, and also with any external integrations.
After you are comfortable doing the three types of testing mentioned above, covering the below testing is considered a good to have:
- Basic security test
This is to ensure that the product has its data and resources protected and features still work as expected.
- Performance test
This is to ensure that the website doesn’t crash and will remain responsive when many users are accessing it concurrently.
Decide on the types of browsers and platforms testing
Is there any statistics on which are the major browsers and OS versions used by the users? You can always do a search for the major browsers and OS versions used by the public if there is no statistics available. It is always a good practice to test your product on the new browser versions and OS versions before release.
It is impossible to test your product on all physical devices available in the market as the cost and upkeep of the physical devices are pretty high. You’ll have to constantly purchase the latest model of devices and update the browsers and OS versions. Another alternative is for you to consider cloud device farms.
Choose the automation framework
It is always better to discuss as a team on the framework to use for automation! The team must be comfortable using the framework, preferably using the same development language as the product to reduce context switching as testing is a team effort. We recommend having the automation framework exist in the same repository as the product; the team tends to forget about writing tests when it is a standalone automation framework.
Also, we understand that there are challenges in the automation journey and they are inevitable (refer to this article).
3. Find out the product budget 💰💰💰
Most importantly, find out the project budget because no money, no talk. Once you know the budget, work within this budget before finalising your automation framework and tools to be used.
Don’t worry if there is no budget, there are always open-source frameworks and tools available.
Working as a new QE in a product team for the first time can be daunting and scary, and we totally understand the feeling and we hope that this article is helpful to get you started! Of course, the above list of items to consider doesn’t stop there; the types of testing depends very much on your product needs and time.
As this is our last article for the year, we’d like to wish everyone…
Stay safe and healthy everyone~ We’ll see all of you in 2022! 🎉 🎉 🎉
- Merlin 💛