Welcome to UI Testing B. An ongoing curated list of frameworks, books, articles, talks, screencasts, recordings, libraries, learning tutorials and resources about UI Testing & Best Practices Development. Thanks to all contributors, you're awesome and wouldn't be possible without you! Our goal is to build a categorized community-driven collection of very well-known resources.
- User interface or UI testing, also known as GUI testing, is the process of testing the visual elements of an application to validate whether they accurately meet the expected performance and functionality. By testing the GUI, testers can validate that UI functions are free from defects.
- Visual Design
- Functionality
- Usability
- Performance
- Compliance
What UI Testing is important in the SDLC?
Like most types of software testing, the scope of GUI testing can be very broad. In this section, we put together essential test cases that can help QA professionals test their interfaces thoroughly. The test cases cover different UI aspects, including images, color standards, page content, navigation, usability, and more. Use this checklist to ensure your UI tests are more exhaustive.
- Data type errors – Ensure only valid data can be entered for specific data types such as currency and dates.
- Field widths – If a certain text box permits a specified amount of characters, then make it clear on the user interface that the data entered shouldn’t exceed the character limit. ( For instance, a field that allows 50 characters in the application’s database should not allow users to enter more than 50 characters on the interface).
- Navigational elements – Verify all navigational buttons on the page are working correctly, and that they redirect users to the right page or screen.
- Progress bars – When displaying screens that take time to render results, a progress bar should be used to show the user that a process is still running.
- Type-ahead – If your UI uses drop-down lists, ensure you include type ahead. In a drop-down menu with hundreds of items, typing the first letter should skip the list to items beginning with that letter such that users will not have to check through a long list.
- Table scrolling – If data in your tables extends to another page, then the scroll function should allow users to scroll the data but keep all headers intact.
- Error logging – When the system experiences a fatal error, ensure the application writes the error details to an event viewer or log file for later review.
- Menu items – Ensure the application only displays valid menu items that are available at a particular state.
- Working shortcuts – For applications that support shortcuts, verify whether they work correctly, no matter the browser, platform, or device being used.
- Confirm action buttons – Ensure the UI has working confirm button every time the user wants to save or delete an item
- UI Testing Introduction
- Testing strategies (4)
- Generic Best Practices (5)
- Server Communication Testing (3)
- Beginners (1)
- Generic testing perks (1)
- Tools (1)
- Component Testing (3)
- Advanced (5)
- Real Life Examples (1)
TL;DR: Identifying the test types is the starting point to understand and master all the UI testing strategies, the tools, and the pro/cons of them. UI integration tests are the most effective ones (you are going to love them), E2E tests give you the highest confidence, and Component tests allow you to test the units of the UI in isolation.
Otherwise: You end up writing a lot of E2E tests without leveraging other simpler kind of tests. E2E tests are the most confident type of tests but even the hardest, slowest and most brittle ones.
🔗 Read More: Component vs (UI) Integration vs E2E tests
TL;DR: Software Testing is an amazing topic but a limited experience could make you fighting with a new enemy instead of relying on a new ally. Avoid, if you can, to test every complex user flows since the beginning of your UI testing journey. The simpler your first tests are, the sooner you get the advantages.
Otherwise: You create complex and hard to be debugged tests. This kind of tests slow down your work and do not have any kind of usefulness.
🔗 Read More: In the beginning, avoid perfectionism
TL;DR: Cross-browser testing is way overrated. It's an important topic and it's the first thing you can think while starting evaluating the right testing tool. Don't worry: start by splitting functional testing from visual testing, that's the first step to correctly evaluate the need for cross-browser support (and to choose the right testing tool, too). Visual testing can be integrated into every testing tool, thank services like Applitools and Percy.
Otherwise: You could choose the wrong testing tool based on the cross-browser support.
🔗 Read More: Choose a reference browser
TL;DR: A test is a good ally when you need to be sure that you are able to systematically reproducing a bug. A test allows you to speed up the fixing flow and to be 100% confident that the same bug is caught forever.
Otherwise: You could not identify correctly the bug and you can not be sure that the bug will not present again in the future.
🔗 Read More: Found a bug? Write the test, then fix it
TL;DR: When testing your UI, you define a sort of key points the app must pass through. Reaching these key points is an asynchronous process because, almost 100% of the times, your UI does not update synchronously. Those key points are called deterministic events, as known as something that you know that must happen. You need to wait for these events to make your tests robust.
Otherwise: Sleeping the tests make your tests slow and brittle, it's one of the most common and biggest errors in UI testing.
🔗 Read More: Await, don't sleep
TL;DR: Lot of times you need to launch just a type of tests and it's super easy if you follow a common pattern while naming your testing files.
Otherwise: You need to launch a long test suite just to have some of them run.
🔗 Read More: Name the test files wisely
TL;DR: Debugging a UI test could be really hard, especially if you use generic browser automation tools. Here is a list of simple rules that are at the base of the debugging process.
Otherwise: You are going to waste a lot of time without taming the exponential complexity of a UI test.
🔗 Read More: UI Tests Debugging Best Practices
TL;DR: As a developer who wants to ensure quality, it is important to think about cost of tests vs the value they provide. Where reasonable, strive to not duplicate effort, and still get high value by considering alternatives for setting up state for a test.
🔗 Read More: Reaching UI state
TL;DR: Leveraging your testing tool to avoid manual tests is one of the biggest improvements you could do to speed up your working flow. Testing tools are faster than you and the most modern ones include some UI utilities that make easy to use them as a development tool.
Otherwise: You code the app the old way, losing a lot of time interacting manually with the UI itself.
🔗 Read More: Use your testing tool as your primary development tool
TL;DR: The UI communicates continuously with the back-end, and usually every communication is critical. A bad request or a bad response could cause inconsistent data and inconsistent UI state. Remember that all the business is built around data and the user experience is scratched by every single UI failure. So, every single XHR request must be checked carefully. XHR request checks make your test more robust too, correct XHR management and testing are one of the most important aspects of a UI test.
Otherwise: You could miss some relevant communication inconsistencies and when you need to debug them, you are going to waste a lot of time because the test will not drive you directly to the issue.
🔗 Read More: Test the request and response payloads
TL;DR: A lot of times, the front-end application breaks because of a change in the back-end. Ask your back-end colleagues to allow you to export every schema that describes the back-end entities and the communication with the front-end. Some examples could be the GraphQL schema, the ElasticSearch mapping, a Postman configuration, etc. more in general, everything that can warn you that something changed in the back-end. Every back-end change could impact the front-end and you must discover it as soonest as possible. You can keep the schema checked with a simple snapshot test.
Otherwise: You could miss some back-end change and your front-end application could break inadvertently.
TL;DR: The more the test suites are launched periodically, the more confident you are that everything works as expected. UI tests should be based on the user perspective but there are a lot of small tests that could give you a lot of immediate feedback without debugging the expected user flows. Monitoring small and taken-for-granted tech details helps you preventing bigger test failures.
Otherwise: You mix tech-details tests with the user-oriented ones.
TL;DR: Approaching the testing world could be inefficient and not satisfactory. You start writing some unit tests but you are left with a lot of doubts. UI Testing allows you to start with a high confidence since the very first day.
Otherwise: The wrong approach could condition the way you think about testing and could leave you with the false idea of testing the right way when the truth is you're testing nothing.
🔗 Read More: Approach the testing pyramid from the top!
TL;DR: Tests are a good way to have a concise, code-coupled, and updated documentation. Good storytelling test descriptions could make the comprehension of a codebase or a new project very simple.
Otherwise: You rely on the code documentation or, worse, on the readability of the code to comprehend that the code does.
🔗 Read More: Software tests as a documentation tool
TL;DR: Why is testing a web application so hard? Why generic browser automation tools do not fit well the UI/E2E testing needs? Why does Cypress outstand?
Otherwise: A generic features comparison is not enough to understand what are the main UI Testing pains and how Cypress removes them.
🔗 Read More: Some UI testing problems and the Cypress way
Please note: the whole Component Testing world is changing rapidly, more contents will be added.
![✔] 7.1 @NoriSte's approach: Testing a component with Cypress and Storybook
TL;DR: Components ar the building blocks of your app, testing them in isolation is important to discover, as soon as possible, iof there is something wrong with them.
Otherwise: UI Tests without lower-level tests do not allow you to understand the source of the problem.
🔗 Read More: Testing a component with Cypress and Storybook
![✔] 7.2 @daedalius's approach: Exposing components from Storybook separating stories from tests
TL;DR: You may expose the component reference from Storybook Story to test it whatever you wish in Cypress without breaking testing logic into pieces.
Otherwise: Splitted test logic and test data will make it difficult to read and support.
🔗 Read More: Cypress + Storybook. Keeping test scenario, data and component rendering in one place.
TL;DR: Cypress v4.5.0 release allowed Unit Testing React components, an external tool like Storybook is not necessary anymore to test isolated components.
🔗 Read More: Unit Testing React components with Cypress.
TL;DR: Tests should be repeatable, modular and should handle their own state setup. UI Tests should not be repeated in order to achieve state for another test.
TL;DR: Tests must produce consistent results every time. Repeatable pipeline execution results are the quorum. If a test cannot produce reliable results, it reduces confidence in the tests and requires maintenance which reduces all value. In these cases it is best to manually test the functionality.
TL;DR: Most software bugs and failures are caused by one or two parameters. Testing parameter combinations can provide more efficient fault detection than conventional methods. Combinatorial Testing is a proven method for more effective software testing at a lower cost.
🔗 Read More: Combinatorial Testing
TL;DR: Although this is a vast topic, Performance testing from a web development perspective can be simplified with modern tools and understanding. It is highly effective in ensuring user experience, satisfying non-functional requirements (NFRS), and detecting possible system-flake early on.
🔗 Read More: Performance Testing
TL;DR: Email testing is critical for business success. Modern services not only allow automated email testing but also provide a stateless, scalable solution while testing SaaS applications.
![✔] 9.1 Siemens - Test the front-end with the integration tests, the back-end with the E2E ones - in reference to Component vs Integration vs E2e Testing
TL;DR: UI tests with a stubbed server are reliable and faster compared to full E2E tests. Full E2E tests are not always necessary to ensure front-end quality. We can instead have high confidence in front-end quality by using lower-cost UI integration tests and saving higher cost E2E tests for the back-end.
Otherwise: You waste time and resources with slow and brittle E2E tests while you can get a lot of confidence with a lot of UI integrations tests.
🔗 Read More: Test the front-end with the integration tests, the back-end with the E2E ones
License
To the extent possible under law, Veilair has waived all copyright and related or neighboring rights to this work.