Manual UI testing initially arose out of necessity, as automated tools poorly capture errors related to visual perception and usability of the interface (history). All elements must be accessible, display correctly, and interact as expected by the user.
The main issue with manual UI testing is subjective evaluation: different people may perceive the same interface differently. Moreover, there are often situations where visual defects are not documented or ignored (‘problem’). To avoid subjectivity, clear acceptance criteria for visual elements need to be developed, use isometric and guidelines, and any found issues should be documented with screenshots, clear descriptions, and comparisons to original mockups (‘solution’).
Key features:
Is it enough to check the UI only in one browser or on one device?
No, elements may display differently due to differences in browser engines and device resolutions.
If a tester does not see a defect, can they assume that the bug is absent?
No, it is necessary to compare the interface with guidelines and mockups, rather than relying solely on subjective views.
Can accessibility requirements be ignored in UI testing?
No, accessibility requirements are important for end users, including those with disabilities.
The tester checked the UI only on their computer and in one browser, and only visually compared it with the previous version, without relying on the mockup. As a result, users on mobile devices saw a broken interface.
Pros:
Cons:
The tester checked the UI on different devices and browsers, compared it to the mockup, and took accessibility guidelines into account. They used checklists for visual criteria.
Pros:
Cons: