Planning is a very important phase of any project, and this won't be an exception. It is important to have a test plan that identifies the resources available for testing and that prioritizes areas of the application to be tested before we start writing our cases. With this information, the testing team will be able to create test scenarios, test cases, and test scripts for scripted testing, documented in the test charter.

This is an example of the structure that our test plan should contain:

• Defined dates for each test
• Required testers
• Required resources such as servers, environments, tools, and cloud providers correctly configured to start testing
• Target application environments, such as different screen resolutions, mobile devices, and supported browsers
• User workflows/navigation to test
• Testing techniques to be used, including scripted testing, exploratory testing, and user experience testing
• Goals for testing, including the acceptance criteria to determine if a test passes or fails

Also, we can add some more sections according to our own needs:

Our GUI test plan should not be considered as a full system test plan. You can also consider other aspects such as load testing, security, backup, fault tolerance, and recovery.

Done, we have our plan! What's next? Identify our testing priorities. For example, first of all, we need to ensure the following:

• Visual design
• Security
• Usability
• Compliance
• Functionality
• Performance

Now, it's time to represent it in a mental map to be understood by the entire team and perform the required tests. Check out this example:

The most common areas to test when we are navigating on a web application are these:

• Compatibility with different versions of most used browsers
• Behavior when the user clicks on the back or refresh button (in browser)
• Behavior after a user returns to the page using a bookmark or their browser history
• Behavior when the user has multiple browser windows open on the UAT at the same time