I will start my deep dive into different parts of testing with the Frontend UI. Not because it is the most important, but because it's traditionally where testing has focused and arguably where many non-technical testers today probably spend their time.
The focus of UI testing is to ensure that all the completed UI elements load and work correctly on the page. While this was traditionally done after development in a test environment for the testers and focus more on an end to end journey, with certain new stacks it can be easy to test and automate this while the code is still in development too.
Depending on your software architecture, you are likely not going to need to do extensive functional or user journey testing at this phase and you are rather just looking at the visual aspects of how the page renders and ensuring that they display as expected. Sounds easy when describing it but can be quite complicated to execute this correctly.
Firstly, just as any front-end developer can attest to the compacted nature of UI development, so do the same things apply to the testing side of things. There are a multitude of browsers, screen sizes, resolutions and even devices that all need to be catered for and to do exhaustive checks on every single screen across each of these items is not only time consuming, but improbable. Rather your time is best spent on prioritising where you are likely going to target most of your users and then visually testing from there.
Following the below guidelines should help you to prioritise and plan your UI testing effectively. I will talk about UI testing and UI automation separately, as you need to understand how to test a UI effectively before you can even begin to look at how to automate it:
1) Understand the core functional journey of the UI
While its difficult to lock down the exact design of a UI, the overall purpose of any new design feature and how it should function needs to be place and teams shouldn’t look to do any development work before this has been finalised otherwise it could lead to waste effort. As a tester, you would want to know the operational steps of a UI and what test scenarios to look out for as early as possible. Too many companies, for the sake of agility, try and rush this step and rather play around trying to find the right approach at a code level. This is great as a proof of concept, but terrible for the quality of your application so unless you are literally doing a POC, don’t follow this approach. Rather map out the details of how the software is intended to function and start putting together testing criteria upfront to make it easier for the UI developers to build something that matches the testing needs rather than retrofitting testing to the UI.
2) Start working with the team to standardise design objects
This might seem like an odd thing to do, but when you start getting into the automation fo your UI later, this is going to prove most important and you don’t want to leave it too late. Once you have an idea of your customer journey, it's important that you work with the designers and developers to standardise how elements will work. All similar objects like input boxes, buttons, navigation links, etc should follow a consistent pattern. This is not just great for the user experience but will mean that from a testing perspective, you can test for similar behaviours with each object. Also specifying naming conventions for unique element tags for the automation tool are important here so that you can start writing your automation earlier, knowing what to expect.
3) Know your integration points
While things like APIs and most backend code can be easily segmented into independently operating elements, chances are your UI is going to have to intersect with multiple different backend elements to work effectively. So, it’s important to understand all the different APIs, backend systems and databases you will be interacting with and understanding how those work. UI testing is a lot more tightly connecting than you might realise from an integration perspective and while you don’t go into detail on parts of the code, you will touch many parts and so it requires a broader understanding of the system. Knowing these details ensures that you as team design your elements to correctly interact with each unique system while also been aware of that system's constraints and then designing and testing with these in mind.
4) Understand what the UI does and doesn’t validate
Knowing exactly where certain validation steps happen, either a UI, BFF or API layer will help you as a tester to know the amount of focus you should place on testing it. While you want to ensure each element on a page is usable, if the core logic sits elsewhere, rather test it at the level and let your UI testing only focus on what is necessary. UI testing is not the place where you want to apply your different boundary value analysis or other test permutations, this is best reserved for testing closer to the code.
5) Practice efficient test case design
Because UI testing is more time consuming, you want to try and test as much functionality as efficiently as possible. Often you can validate 80% of your codebase with only 10-20% of test coverage and so you if you map out your coverage correctly, you can greatly reduce your testing effort. You should already know your core customer journeys at this point in time and so have those identified, along with what backend system are touch where. What you then need to do is map out how you can run through all the core use cases along with all your integration points to ensure you have everything covered.
There are many techniques like Combinatorial Test Design which help with this sort of thing, but they are focused on when you have a high number of combinations, whereas if you have done your design and analysis correctly, this should preferably be existing lower down and not at a UI level, so not of much use here.
6) Attention to detail is important
Once you have an idea of how and what to test functionally, you need to layout how you are going to ensure that everything is visually displaying as it should. This where attention to detail is important because even though you might not think about the slight misalignment of your screen on one particular browser, it’s what the customer ends up complaining about the most even if the rest of the site functionality works. While no doubt the priority is to ensure everything functionally works first, a lot o this can often be tested at lower levels leaving your UI to be around the rendering of everything and having strong attention to detail is important here.
7) Prioritise your testing
Whereas UI and API tests are a lot faster to test, UI tests take a lot longer as they generally work with a fully rendered screen, thereby meaning that it is important to know which user journeys you would want to pursue as a primary objective and which UI elements are less important. Also, unless your UI is handling all of the validation, you only need to focus on mostly happy day scenarios here and can leave other negative testing for lower levels.
Prioritisation is especially important when it comes to deciding which resolutions, browsers and platforms to support because to test how everything shows itself visually is not feasible. Having a clear idea of which platforms and area to target allows you to work towards a feasible plan where you can test effectively and not exhaustively
8) Remember security
More than anything, the UI is where security is most vulnerable as its what customers are exposed to. While every part of a system should be designed and tested with security in mind, your UI is one place where you don’t want to take any chances and a thoroughly secure UI I the best gatekeeper than any system can have from further security vulnerabilities.
9) Don't focus your performance and load here
The UI too, as where many people end up focusing their performance testing at. Art of this is because the majority of tools cater towards UI scripting, but the other aspect of it is because you want to try and replicate your user journey and see how the system performance in that regards. There is some truth to that last part, but if you are relying on your performance testing here, it's often too late. Most bottlenecks in performance typically occur at an API or database level and this is where coding can often best be optimised. So while you do want to run tests at this level, do only a few basic journeys and leave most of the performance and load tests where they are most likely to surface issues earlier.
UI testing is time-consuming and not always fun, but remains one of the most practised and important parts of many companies testing efforts Learning how to do it properly and focusing on good design and analysis rather than just pure validation though, helps to reduce the testing effort and will especially help when it comes to automation which I will go into more detail in my next article.
Comentários