Due to delays and changes in project it is reasonable to perform testing in two stages: first to make sure base functionality of developments ordered by SC performs as expected, second to test TID+-specific additions as soon as they are ready. According to current development agreement it should be possible to do both using test environment set up for SC and delay public launch of "new TID" in Estonia until the TID+ additions have been also tested and ready for use.

This means some extra burden specially for invited beta testers who are not part of organisations participating in TID+ and who would expect to see finished system. We believe though, that providing them access in early stage and so leaving more room for suggestions resulting from testing to implemented would compensate that.

As TID technical specification is publicly available testers are able to see already planned changes and can concentrate on possible shortcomings that are not described earlier.

Testing of base-TID

• closed alfa-testing to ensure the system fulfills base requirements and is usable according to original usage scenarios
• invitations-only beta-testing for users that have been participating in earlier phases of TID+ (interviews, questionnaire)
• recording and analysing select users new to the system in performing common tasks

Tasks for alpha-testing

Target is to process "tens of ideas" (at least 20) through TID and gather user feedback:

• each tester needs to create at least 5 ideas
• participate in commenting and voting phase of ideas presented by other users
• participate in commenting received answers and possible recycle the idea based on answer
• admin-tester is constantly following the process and guarantees smooth flow of process
• user-testers have option to log in as admin in case they want to speed up the process of finding the way to reproduce a problem (user-testers should use the admin access only for this purpose)
• all testers are expected to report found problems/suggestions as a new "idea" (with special category tag)

Reading ideas, registering

1. unregistered user arrives having heard the name of web (to frontpage), tries to find somehting interesting. What is the first impression, is it possible to get overview, find an interesting subject?
2. unregistered user arrives to the site being interested in particular subject field (e.g traffic, environment). Finds an interesing idea, points to it in weblog/forum/etc, comments&votes (for that registering as a new user), invites friend, participates in idea process when announcements arrive
3. unregistered user arrives via search engine to an idea in particular subject field (e.g traffic, environment) but the idea is either already closed or not exactly corresponding to original search. Is the phase of idea (commenting/voting/answered) understandable? Can user find other related ideas on the system?

Creating an idea

1. unregistered user arrives wanting to present an idea. Is the process understandable and usable without instructions? What questions arise in the idea process and are these solved? Is the feedback about progress of idea adequate? Does user at the moment of presenting idea understand which kinds of ideas "have chance" in TID, what are the possible reasons of rejecting an idea?

Administering ideas

1. admin-tester starts a "working day" inspecting and processing ideas in queue. Is the process easy and understandable, are there any points that require using external tools to achieve necessary outcome? (using external tools may be OK, but if so we need to document that for trainings etc) Is the process understandable from the rules viewpoint (when and how to reject idea, also how to modify FAQ should the issues be repeating)?
2. admin-tester checks "stalled ideas" (no answer from ministry by deadline?). Is it easy to understand what is the status, what actions have been taken or should be taken?
3. admin-tester periodically checks the inbound queue like at the start of working day. Is it simple to quickly deal with new ideas and issues, are additional notifications needed (or perhaps minimizing disturbance by grouping ideas together and alerting admin only after certain threshold or at certain hour?)
4. admin-tester suddenly needs to be replaced by another admin, who is trained and has practice but has not been admin during "few weeks" (in testing period probably few days). Is it easy to take over the job and understand the status of tasks in process? Are there any external tools needes (access to common admin e-mail?)

Tasks for invitations-only beta-testing

As most of the alpha-testers have had some part in the project their expectations and knowledege may differ from actual everyday users and ICT/web/usability sepcialists. This beta-testing is meant for users, who have participated in interviews or surveys at the earlier stages of project to let them voice their opinions on new base-functionality of TID:

• has it become more user-friendly?
• have the previous usability problems been eliminated?
• is it easy to adapt to new system?
• are the processes logical?
• does the user get adequate feedback?
• what are the possible showstoppers that definitely need to be changed?

Tasks will be the same as for alpha-testing of the user side (e.g "Reading ideas, registering" and "Creating an idea" above), but users are not required to produce step-by-step raports of proceedings but answer a questionnaire later (of course, they are welcome to be as detailed as they wish).

Testing of TID+ additions

• closed alpha-testing to verify the functionality conforms to the specification
• invitations-only beta for the same users who participated in base testing
• public beta with a system that has all "old TOM" ideas imported, tagged etc so completely replacing the original system. this is practically the launch on TID+-based TOM

Testing scenario for TID+ additions will be written when we have had the first chance to see the actual realization of specifications.

 Create your own business wiki!Help Add to Del.ici.ousPublic, not yet premium Privacy Policy RSS