TLDR; When testing web apps we need to test the interaction between the browser implemented controls and our system. We don’t test the browser.
Testing HTML Form Fields
Testing Web Technology
I like to use the term Technical Testing.
Many people don’t. I think other people view the term as implying that some people are technical and other people are not.
I use the term to cover “Testing which is informed by Technical knowledge”.
So if you’re testing a web application, you need to understand web technology, you need technical understanding of how browsers and the web works, otherwise you can’t test it effectively.
In this video I try to explore some of the reasons why this is important.
If I’m testing a web application and it has a form, and in the form is a date field which has a date control calendar pop up which lets me set a date.
What should I test?
What should I test?
Should I test that…
- the calendar popup works on mobile and every web browser?
- the calendar control works with keyboard?
- the calendar control correctly switches years and months when I click the control buttons?
Well, no. Not if the HTML looks like this:
<input id="datetime-local-input"
type="datetime-local" name="datetime-local">
All of the complex UI interaction is implemented by the browser.
All our application does is use an off-the-shelf browser provided control.
Do I not test the functionality?
When we are using off-the-shelf controls like this we have to test the interaction between the control and our application.
If we added JavaScript event listeners to the control to perform extra validation or functionality then… yes we have to test that.
If we use the date entered in the control by the user, then we have to test that our application can handle the data supplied by the value of that control.
If we are not using the date then we should question why we have the control on our application UI.
Learn to spot technology risks
I can see from the HTML above that there might be an accessibility risk, because I don’t see any ARIA attributes associated with that control.
So we might not have configured the control in the page properly to implement all the accessibility requirements we might want.
If we had created a custom control, or it is specialised React control, then we do want to test it because we just introduced a technology risk that might impact mobile and different browsers. We might also have functional bugs.
But if we are using built in browser controls we don’t need to test as much functionality related to the control. We need to test the functional interaction with our application and custom code.
Test the Domain Configuration
We shouldn’t spend a long time testing validation messages from custom controls, but if a control has been configured then we need to test that the configuration is correct.
<input id="password-input" type="password" name="password"
pattern="^[A-Za-z0-9_]{4,12}$" maxlength="14" required="true">
I don’t need to test that the password control above shows dots instead of letters and hides the input. But I do need to check that the configuration we supplied for the validation pattern and length are correct. And I need to make sure that the password is actually required (because we configured that it is).
NOTE: eagle-eyed readers, who have a technical understanding of how the configuration works will probably have spotted a bug in the above configuration. Yes. We should find that bug in our testing. And we know to look for it because we understand that the control has been configured with our application domain rules, and that’s what we are testing.
Don’t Trust the Client
The greater the technical understanding we have of the web technology, the less we will trust any data that the server receives.
We can edit the DOM to bypass domain configuration.
We can use JavaScript to enter data that bypasses browser validation.
We can bypass the browser altogether and just communicate directly with the server.
A greater technical understanding allows us to understand the risks of the technology more effectively
Testing Web Apps
All of the examples above are from:
I also have a guide to testing HTML elements to describe some of the risks and issues that we might have when using or configuring off-the-shelf HTML fields and elements.
I had to learn web technologies when testing web applications.
I have seen people functionally test the browser implemented controls because they didn’t learn web technologies.
This means they wasted time, because they didn’t understand the technology they were testing.
Join our Patreon from as little as $1 a month for early access to videos, ad-free videos, free e-books and courses, and lots of exclusive content.
Top comments (0)