Web_Dev_Grad

There should be a slew of tests performed on your website to make sure that everything works and that your users have a good experience.

Manual testing (often called user testing) is where the site is manually tested from the point of view of the user by actions such as clicking buttons, filling out forms, and testing that all the behind the scenes logic creates the intended user experience. This involves you loading up your webpage and checking that everything works as you intend it to.

Automated testing involves using scripts and a testing frameworks to test functionality automatically. Automated testing can be quick, thorough, and allow the developer to pick up errors early on but relies on the developer asking the right questions and does not test for user experience.

Furthermore, you should test how your website works across various browsers and devices, that your website meets all accessibility standards, performs well and does not take a long time to load, all of your written code is validated to the highest standards, and any major bugs you encounter are documented along with their fix to highlight your development process.

You should try to keep your User Stories in mind during development. These can be tested simply by checking your Features section and making sure that all of your user stories have been sufficiently covered by your implemented features.

Other manual testing will involve you opening your webpage and going through page by page and checking that everything you built works as expected. This is usually informally done as I go; checking things such as responsivity of the webpages as I build them along with how the layout looks. But at the end, it is best to go through with another comprehensive check like this.

These should be catalogued detailing the feature, the action you take, what are the expected results, if your test passed, and what was done to fix it if it did not pass with it also being logged in your Bugs section. With things such as submissions and forms, keep in mind what you want to happen when errors occur as well as when they are successful. This should result in a table with some listings looking like:

Feature	Action	Expected Results	Passed	Comments
base.html
Site logo - header	Click	Redirected to the homepage	Y	N/A
Site logo - footer	Click	Redirected to homepage	Y	N/A
Booking form	Submit with empty fields	Prompt to enter a check in date	Y	N/A
Booking form	Submit with only check in date	Prompt to enter a check out date	Y	N/A
Booking form	Submit with dates and no guests	Prompt to add guests	N	Bug 1 (link): Highlighted and fixed
Booking form	Submit with dates and no guests	Prompt to add guests	Y	N/A

It is best practice to check that your website works as it should across multiple browsers and devices. I tend to use Google Chrome for displaying my web apps during development so I also check that they look and work as expected on Safari, Microsoft Edge, Opera, and Firefox.

For different devices and screen sizes, you can easily simulate these in the Google Dev Tools system.

For automated testing of Python or JavaScript code, it is best to take a TDD approach. Testing of these are covered in the Python Testing and JavaScript Testing sections.

Generally, when new functionality is implemented, unit tests local to the specific app or function are run first. When the function is proved to run without error, all written automated tests are run as an integration test to ensure that there has not been an impact on other functionality. This type of regression testing allows bugs to be caught when code interacts in a way that was not intended and ensures that the web app will work as expected as a whole. A similar process is taken when manual testing; the feature is tested as it is introduced and then all the features are tested when the web page is complete and when extra features are added in the future.

You should keep accessibility in mind throughout development and apply best practices across your website including, but not limited to:

• Ensuring ARIA labels were used throughout. ARIA labels provide clear descriptions for elements that don't naturally convey meaning to assistive technologies, helping screen-reader users understand the purpose of buttons, icons, inputs, and interactive elements
• Ensuring alt texts were used on all images. These ensure that images are accessible to users who are blind, have low vision, or use screen readers. It describes the image's content or function so that no information is lost
• Use semantic HTML throughout. Assistive technologies rely on these built-in semantics to help users navigate pages quickly and understand the hierarchy of content. Additionally, browsers, search engines, and accessibility tools interpret semantic HTML more accurately, improving SEO and usability.
• Create colour palettes that are easy to see and have good colour contrasts. This benefits users with low vision, colour blindness, or poor screen quality who depend on strong contrast to read text and understand interfaces
• Where hidden text is used, hide it in a way that is still accessible to screen readers

CSS accessibility testing can be performed using the Wave validator to provide key information about the accessibility standard of the website.

You should document these with a screenshot of the passed test and an explanation of any errors or alerts that occur. Sometimes these are unavoidable such as floating elements having their contrast compared with the site background rather than their parent div.

Google Dev Tools can be used to do the performance testing of your website.

It can be useful to log the bugs that you come across in your testing, either to remind yourself to fix them later or purely just to highlight some of the issues you encountered during your development. You should include what the bug was, how it could be replicated, the cause of the bug and how you fixed it. For example in a booking form for a hotel management website I had the following bug:

Bug 1:

• This bug occurred when creating the booking form
• Initially the choice of guests was put inside a dropdown menu, making a sleek design. However upon submission of the form with invalid guest numbers; the following error happened:
• An invalid form control with name='adults' is not focusable.
<input type="number" name="adults" onchange="updateGuestCount()" min="1" max="5" required_id="id_adults">
• The reason behind this is that since the number of e.g. adults was in a hidden dropdown when the form is submitted, the error cannot display correctly and the functionality cannot work
• Multiple JavaScript functions were written to either display the error in the dropdown menu when the number is first entered (similar to the total guest update function) or to focus and open the dropdown menu when the form is submitted so that the input is not hidden
• However, these did not fix the issue in a satisfactory way, so the decision was taken to have the inputs outside of a dropdown menu, removing this major bug