Students Staff
University of Essex

July 19, 2013

Testing Methodology: How can I get involved?

Filed under: Project Report,System Development,Technical — sgswaine @ 10:48 am

Testing Methodology

In our testing methodology for this project we have tried to make it easy for people to “jump in” and make suggestions or comments on areas of the system before they are released.

Below is the “testing life cycle” we are using for the project:

Alpha testing

1. Richard develops a part of the system on his local machine and then checks that the part functionally works okay eg when you press a button it retrieves a set of search results. When Richard is happy that this function works correctly, it is moved onto a testing server where other people can have access to view it or play with the new button.

Black, Grey and User testing

2. This is where Richard, the Learning Technology Team, the testing Frotnrunner and testing “Ambassadors” check the new feature and how it actually performs. We’d hope at this stage it is less about finding bugs and more about checking whether a search is performing the right actions. The testing ambassadors are a core group of students, academics or admin staff that will be notified when there is a new feature that needs checking over. This is so we don’t push out something live that does not behave as expected.

At this stage, the feature will also be opened up for input by the relevant user groups self-enrolled on the Moodle course (we won’t allow students, for example, to check a feature that only admin staff will have access to). Users on the Moodle forum will be notified that there is a new feature they are able to test or view and leave feedback on. This raises awareness of a feature before going live.

This stage will only be open for a certain period of time for input from Moodle users. Then the testing for that feature will be closed and the feature will be rolled out to the “Beta” department.

“Beta” testing

3. We will choose a sole department to have access to the new system before other departments do. The “Beta” department will be reading from and creating assignments in the same database as other departments – but they will see a different looking system in the web browser. This means we can test the system with live data for all staff and students from the “Beta” department – this is something quite different for ISS development and something we think will help with smoother integration for other departments. We will discuss the selected “Beta” department in a future blog post, as they will be vital to being a  buffer between testing and full release, making sure this system performs as expected for a department. It’s the bridge between testing features with a dozen people, to releasing to 14,000.

Full release

4. Once we are happy with the performance of a feature, and possibly made alterations we will release a blog post and targetted email informing users of the expected publish date of a new feature. It will then be released during the next appropriate slot – most likely a Tuesday morning network at risk period between 8am and 9am.

Click on our image below to view a .pdf image of the testing cycle.



Leave a Reply

Your email address will not be published. Required fields are marked *