Test Player « Test in LoC »

This feature request is part of the project Splitting-up T&A Into New Components.

1 Initial Problem

When designing testplayers for the new T&A, tests in objective driven Courses (LoC) need some special attention and may need a special testplayer. 
This article is intended to gather the requirements and help in a descision, if a special player is sensible (or if the requirements should be integrated in some other testplayer)

2 Conceptual Summary

Tests in objective driven courses (LoC) have two special variations, which are -at least- diagnostic entry tests and qualifying final tests. Due to options in LoCs some configurations even allow variations like cobinations of diagnostic test which may direcly qualify objectives.

Details of the requirements were discussed in the working group Splitting up... and are stored in Test scenario LoC.

Some special settings are highlighted here:

• Test Questions should alway be created using Questionpools
• There is no continuous mode
• all participants of a LoC should be able to use the tests
• diagnostic tests usually offer one single test run (but exceptions may be required
• the concept of mandatory questions is not needed
• the number of concurrent users for a test may be restricted, if this setting is a requirement of performance considerations. From the bare concept of the test, this is not needed

Opposite to exams, which usually take place at a defined timeslot (which may be some hours or few days), tests in LoCs usually are active over a longer time and thus need some housekeeping. As an examle, errors in questions in exam-tests often are found after all testruns are fisnshed and may be adressed via postcorrection or by adjusting scores and marks. If an error is found in a test in a LoC after some weeks, there may be left a longer time of use of this test and at least future testruns should be presented a corrected version of the test, but wihtout invalidating/deleting testruns already finished (/currently running). This basically applies to all tests in a LoC, not only to diagnostic or qualifying tests. Some considerations for this are included in the file mentioned above.

Additionaly, some changes are suggested which may apply to several testplayers:

• Display of title and points coub be transferred from a 3-way radio-button to two checkboxes (display title and display points)
• participants Answers: thes 4-way radio may be transferred to two checkboxes
• display of special character menu should only be active in questions which allow input of charaters by users
• the signature checkbox should only be visipble if the platform aloows signatures and should be placed in "additional functions"

3 User Interface Modifications

3.1 List of Affected Views

This is to be discussed after a general discussion of testplayers

3.2 User Interface Details

see 3.1

3.3 New User Interface Concepts

none

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Privacy Information

As in all tests it is needed to store user's individual test data like user-id, test date and of course answers given (probably including a history)

6 Security Implications

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Jackisch, Ingo [jackisch],
• Maintainer: t.b.d.
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• DHBW

9 Discussion

10 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.