In the afternoon session on Monday, we reviewed our progress in the unit so far as a build-up to the introduction of the next phase. This is the last week before the two-week build where all the magic will happen. This really helped to put everything into perspective and I realised how far I have come in the project. I have solid aims to work towards and criteria to follow whereas, in the beginning, it was very muddled. This mainly falls down to the amount of user research I have performed and I think this is one of the biggest hurdles I have overcome so far. I didn’t know who I was designing for so I didn’t know what I needed to achieve. Following the prototype testing a couple of weeks ago, this has now become significantly clearer. We were also introduced to the concept of Alpha testing and were informed that we will have to conduct this type of test after our two-week development. Alpha testing is conducted when a product has just been completed and the developers need to establish core functionality.
To build upon this brief introduction, we looked further into what the requirements of a well-executed Alpha test. We were able to break these down into three levels of testing examples. These are existential, performance and behaviour. Existential level testing is to make sure the online product ‘works consistently across a named range of devices, operating systems and browser combinations’ and ‘the load time/footprint fits within acceptable bounds’. This ensures that the product can be consistently used by a wide range of users and is efficient in doing so. By naming it existential level, we are saying that we are looking at the bigger picture and overall specs of the project. Secondly, at performance level, we are looking into how the product performs technically. For example, we will be looking at whether it is ‘responsive within acceptable bounds’. If the site does not scale well across desktop, tablet and mobile it will fail this test. Lastly, behaviour level is a more in-depth look at how it behaves across the platforms specified earlier in this paragraph. I would not only be checking if my product is responsive but also if it is responsive to all specified devices as well. A real-life example of this may be when my website is loaded on a mobile device and the device is rotated, if the elements stay aligned and remained in the intended place, it will pass this test. All of these alpha tests performed together can amount to the conclusion that the product works on a functional level. The examples I have given are relevant to my project type, the development of a website. I have a smaller range of Alpha testing than compared to my peers because they are developing web-based experiences using code, so they have full control over the functionality of their final products. Seeing as I have chosen to host my website on WordPress, a lot of this functionality is already taken care of for me. For example, the theme I have chosen is fully responsive and has a reasonable load time. The only thing I am concerned about is when I start to change the CSS, this may not be compatible with all platforms. I don’t see this being a big issue, but a possible issue nonetheless.
Coupled with this, we also looked at various alpha testing approaches. The testing hierarchy can be depicted as a pyramid chart. From bottom to top, there are four components; unit tests, integration tests, end-to-end tests and UI tests.
Unit tests can then be performed on this code but this time we would see how it performs within the product. End-to-end tests are carried out after this to see how the service performs as an overall product, from start to finish. Finally, UI tests determine whether the visual aesthetic design is suitable for human interaction.
Component Testing is conducted on individual snippets of code to ensure core functionality. It is more commonly used in object-oriented coding rather than procedural coding. It is simply a test to confirm whether a unit of code functions properly and outputs the correct result. The idea behind this method of testing is that each individual unit functions as it should, the whole system should work as well.
Integration Testing involves combining individual units of a piece of software into groups to try and highlight any errors in the interaction. A good example of this is depicted in this GIF below where the two handles function adequately on their own and technically can perform the task of opening each window, however, when placed together into an overall system, where the user is intended to be able to open both at once, the system fails this test.
System Testing/End-To-End Testing can be carried when the software is almost finished to verify that the system works as a whole. This is when the design team would refer to a predetermined requirements statement to ensure the product meets the demands of the client. Having said this, this does not necessarily mean the client would see the product at this stage yet. A group of external testers would most likely be used as they do not have a direct link to the project. This means they can be fresh sets of eyes available to critique and give feedback.
UI Testing Vs UX Testing is usually at the end of the software development timeline. This is where user interaction and user experience designers able to test whether their visual representation of the software that has been developed is capable of being understood by a human. This is a vital stage of the development process because if the software cannot be used by the intended audience, a great majority of the hard work could go to waste.
Acceptance Testing is where the product is presented to the client, intended as a completely finished product. If and when the client is happy with the final outcome, the product can be released for public consumption.
Deployment Testing/Field Testing is the final stage, where the product will be tested in its intended public environment. This happens after Beta testing and an example of this could be to see how a web-based product performs in different internet speeds.
Later on, in the week, I mapped out the criteria for my alpha test and now have a solid idea of what I need to aim towards. This was very challenging for me as it was a lot more on the technical side of the subject. This is by far not my strong suit and I worry I will not carry out enough adequate tests to prove whether my website is completed to a satisfactory standard. I also planned out my first week of the two-week core build and made a start on my industry folder. I found it really tough to plan out both weeks because, at the moment, I only need to input content. I will be applying some CSS code however this is not the main aspect of my project. I hope to get to the end of the first week and the uncompleted aspects of the site will come to light. The industry folder was an enjoyable task because the industry I will be going into is a reasonably broad one. At the moment I am finding myself specialising in information architecture and have therefore been putting a lot of effort into applying my practices to this area of expertise.