Beginner’s guide to user interface (UI) testing

Tram Ho

What is GUI testing?

If wisdom’s beginnings are the definition of terms, then understanding GUI testing must begin with the definition of the GUI term. This is an acronym for Graphical User Interface, or part of an application visible to the user. The GUI can contain elements such as menus, buttons, text boxes, and images. One of the first successful GUIs was the Apple Macintosh, which popularized the user concept complete with file, calendar, trash, and computer folders. In today’s GUI testing environment. “Simple calculator application” is no longer limited to the computer screen. It is possibly a mobile application available on all major mobile platforms. Or, it could be a cloud application that must be supported by all major browsers. The tester must perform cross-browser and cross-platform testing to identify defects and ensure that the application meets all requirements. Hence, GUI testing refers to testing the functionality of an application visible to the user. In the desktop application example, this would include verifying that the application correctly responds to events such as number clicks and function buttons. A GUI test will also confirm that physical elements such as fonts and images adhere to design specifications.

Is UI testing the same as GUI testing?

One challenge when learning about software testing is that there are many terms in the industry and these terms often have duplicate meanings or are used inconsistently. For example, user interface (UI) testing is similar to GUI testing, and these two terms are generally considered synonyms. However, UI is a broader concept that may include both GUI and Command Line Interface (CLI). CLI allows users to interact with computer systems through commands and text responses. Although CLI predates the GUI, they are still in use today and are often preferred by administrators and system developers. A GUI test will also confirm that appearance elements such as fonts and colors are in compliance with the design specifications.

Where does GUI testing fit in the software development lifecycle?

Test Levels

Test levels let you know when testing occurs in the development lifecycle. Each level corresponds to a stage of the developmental life cycle. The ISTQB testing levels are component testing (also known as unit testing), integration testing, system testing, and acceptance testing.

Component testing

Component testing tests individual code units. Component testing is often referred to as unit testing, but can also be referred to as module testing or program testing. Developers write and perform unit tests to find and fix bugs in their code as early as possible during development. This is important in agile development environments where short release cycles require a fast test response. Unit tests are white box tests as they are written with knowledge of the code to be tested.

Integration testing

Integration testing combines the individual units and checks their interaction. One popular type of integration testing is interface / API testing. An application programming interface (API) is a set of rules that two code modules use to communicate with each other. Interface / API test confirms this interaction. Because API rules tend to be very stable in any given application, API tests are a good candidate for automation. Interface / API testing is also white box checking as they require knowledge of the code to be checked. System test icon

System testing

System testing verifies that a fully integrated system works as designed. Since no knowledge of basic code is required, this is a black box test. System testing is the level at which GUI testing occurs.

Acceptance testing

Acceptance testing is usually performed by the end user or their proxy, such as the product owner. The goal of user acceptance testing (UAT) is to ensure that the application addresses the customer needs.

Test Types

Test type tells you what is being tested. Below are the test types identified by ITSQB.

Functional testing

Functional testing compares an application to its functional specifications to ensure that the application does what it should do. In the case of a calculator application, the functional test will ensure that all operations are correct and that the memory and callback buttons save and return the data properly. Function test answers questions like, “Is error handling divided by 0 working properly?” GUI Test is an example of functional testing.

Non-functional testing

Nonfunctional testing checks how well the system performs rather than its specific functions. Non-functional testing looks at factors such as usability, responsiveness and scalability. This type of test answers questions like “How easy is it to do division with this application?” and “Does this app display properly on screens of different sizes?” Usability Test GUI is an example of non-functional testing.

Structural testing

Structure testing is a white box approach. It verifies that all system components are covered by an appropriate test. If gaps in coverage are found, additional tests may be designed to ensure that each component is properly tested.

Regression testing

Regression testing involves re-running previously successful tests after a code change, to confirm that no additional errors (regression) were included. Regression testing is ideal for automation as they are often repetitive.

End-to-end testing

End-to-end inspection confirms the working process of the system. For example, end-to-end testing of a shopping app ensures that the user can search for an item, add it to the cart, enter billing and shipping details, and complete the transaction. buy.

Why is it important to test the GUI?

In software development, quality is defined as providing an application that is functional and easy to use to meet the needs of the customer and is as error free as possible. It has been said that “you cannot check quality into a product. The quality is there or not at the moment it is tested. This quote is about testing a finished product like an automobile, but the same principle applies to software development as well. To improve quality, development teams seek to build it into their projects from the start. One way to do this is to migrate testing earlier in the software development lifecycle, an approach also known as Shift Left testing. Instead of waiting for a system test after the application completes, development teams increase the time and resources spent on unit and interface testing. Early detection of defects in development helps to reduce the cost of solving them. Also, unit and interface / API tests are great for automation: unit tests can be generated by developers as they write code, while APIs tend to be very stable and therefore requires less maintenance than the GUI tests. With the emphasis on Shift Left experiment, it seems that GUI testing doesn’t matter. After all, manual GUI testing can be time consuming and resource intensive. And test automation is more challenging for the GUI: Since user interfaces can change frequently, automated GUI tests that were previously working may fail, requiring considerable effort to maintain. maintain them. But unit and interface testing cannot evaluate all areas of the system, especially the critical aspects of workflow and usability. In particular, these tests can only verify the code exists. They cannot judge possible missing functionality or problems with the visual elements and ease of use of the application. This is the value of the GUI test, which is done from the user’s perspective rather than the developer. By analyzing an application from the user’s point of view, GUI testing can give the project team the information they need to decide if an application is ready for deployment.

How to write a GUI test plan

A GUI test plan sets the scope of a test project. Before writing test cases, it’s important to have a test plan that identifies the resources available for testing and prioritizes the areas of the application to be tested. With this information, the test team can create test rules for discovery testing and test scenarios, test cases, and test scripts for scenario testing.

The test plan identifies key information including:

  1. Expected test date
  2. Personnel needed
  3. Resources needed, such as physical hardware, virtual or cloud-based servers, and tools like automation software
  4. Target test environments, such as desktop, mobile, or web with supported browsers
  5. AUT processes and events will be tested, as well as AUT’s visual design, usability, and performance.
  6. Planned testing techniques, including script testing, discovery testing, and user experience testing.
  7. Objectives to test include criteria to determine the success or failure of an overall test effort.

How to write GUI test cases

To write a GUI test case, start with a description of the GUI event to be tested, such as a login. Then add conditions and procedures to perform the test. Finally, define the expected results of the experiment and the criteria for determining whether the experiment succeeds or fails.

Writing general or detailed procedures depends on factors such as:

  1. Testers’ level of experience, both with general GUI testing and with the specific application being tested. Less experienced testers may need more detailed procedures.
  2. The frequency of user interface changes. If an interface changes frequently, maintaining detailed procedures requires more effort.
  3. How much freedom will the end user have when navigating through the app. If the user has a lot of freedoms, you can write procedures to include all possible paths, or rely on the tester’s ability to predict the random paths that the user might have. go.

If the tester only needs general procedures, these can appear in the test case itself. If testers need detailed procedures, including these procedures in a separate test scenario can help make your tests easier to maintain.

Testcase for the GUI

  1. All required fields must be validated and indicated by an asterisk (*) symbol.
  2. Authentication error message must be displayed correctly in the correct place
  3. All error messages must be displayed in the same CSS style (e.g. use red)
  4. The general confirmation message must be displayed using a CSS style other than the error message style (e.g. use green)
  5. Drop-down fields must have either blank entry first or text like ‘Select’
  6. Deletion functionality for any records on the page should require confirmation
  7. Default page sorting should be provided
  8. Reset button functionality must set default values ​​for all fields
  9. All numeric values ​​must be properly formatted
  10. The input fields must be checked for maximum field value. Input values ​​greater than the specified maximum limit will not be accepted or stored in the database
  11. Check all input fields for special characters
  12. Field tags must be standard, for example a field that accepts a user’s name must be correctly labeled as “First Name”
  13. Check page sorting after add / edit / delete operations on any record
  14. Check cookies used in an application
  15. Test the timeout function. Timeout values ​​must be configured. Check the behavior of the application after the uptime is over
  16. Check that the downloadable files point to the correct file path
  17. Application crashes or unavailable pages will be redirected to the error page
  18. Check text on all pages for spelling and grammar errors
  19. Check numeric input fields with character input values. Appropriate verification message will appear
  20. Check for negative numbers if allowed for fields 27.
  21. Test functionality of the buttons available on all pages
  22. Check the amount fields with decimal values
  23. Users will not be able to submit the page twice by pressing the submit button consecutively.
  24. All fields on the page (e.g. text boxes, radio options, drop-down lists) must be aligned correctly.
  25. Sufficient space should be provided between the field labels, columns, rows, error messages, etc.
  26. Scroll bar should be enabled only when necessary
  27. Disabled fields are greyed out and the user will not be able to focus on them
  28. Description, the Address text box must contain multiple lines
  29. Users will not be able to enter a select drop-down list
  30. Information entered by the user must remain intact when there is an error message on the submission page. Users will be able to resubmit the form by fixing the error
  31. Check that the appropriate field label is used in the error message
  32. Drop-down field values ​​must be displayed in the specified sort order
  33. Tab order should work properly
  34. Check if correct fields are highlighted in case of errors
  35. Check if the drop-down list options are readable and not truncated due to field size limits
  36. Examine all pages for broken links
  37. All pages must have a title
  38. User can select only one radio option and any combination for checkboxes

References

https://www.ranorex.com/resources/testing-wiki/gui-testing/ https://reqtest.com/testing-blog/gui-testing-tutorial/

Share the news now

Source : Viblo