Choose one track. Master’s proposals target Spring 2027. Final scope and programme approval are agreed with the supervisor; bachelor scopes are suggested adaptations.
TRACK 01 · IMPLEMENTATION INCLUDED
Technical track
Develop a working solution and test whether it addresses the problem.
Possible research question
How can inspectable test prioritisation improve useful feedback under a fixed testing budget while keeping developers in control?
Suggested tasks
Read research on test prioritisation in software teams and compare existing solutions.
Identify one problem faced by developers and quality-assurance staff.
Write a research question and define what the solution should do.
Collect test durations and failures from one repository so earlier test runs can be replayed.
Build a tool that chooses which tests run first, explains its choices and lets developers change the order.
Compare it with a fixed order and simple duration-based or failure-based rules. Measure how quickly failures are found within the same time budget.
Explain what worked, what did not, and how the results compare with earlier research.
Evaluation, degree scope and deliverables
Study and evaluation
Compare the implemented solution with fixed test order and a transparent duration- or failure-based heuristic. Combine reproducible technical tests with an appropriate empirical evaluation.
Defects found within a fixed budget
Time to useful failure feedback
Developer understanding and control of priorities
Degree scope
Bachelor’s
Build a test-priority view and a transparent heuristic using historical test results. Measure feedback time under a fixed budget.
Master’s
Compare learned and heuristic priorities using chronological splits, then investigate how explanations support developer control.
Background
Programming
Automated testing and CI
Basic data analysis or ML
Possible deliverables
A focused literature review, justified problem and research question
A working prototype with source code and setup instructions
A reproducible comparison and an appropriate study of use
A report explaining design lessons, results and limitations
TRACK 02 · NO IMPLEMENTATION REQUIRED
Non-technical track
Study existing systems, information or work practices. You do not need to develop software.
Possible research question
How do software teams negotiate testing priorities under limited feedback time and computing budgets?
Suggested tasks
Read earlier studies of test prioritisation in software teams.
Choose one problem and write a research question the study can answer.
Interview team members about required checks, feedback delays and acceptable testing trade-offs.
Analyse existing CI histories or public test logs using a predefined sampling and coding plan.
Discuss prioritisation examples to understand trust in automated ordering and expectations of human control.
Analyse the interviews, observations or documents using a clearly described method. Look for disagreements as well as common patterns.
Explain the findings, compare them with earlier research and suggest practical improvements.
Evaluation, degree scope and deliverables
Study and evaluation
Use a bounded empirical study of test prioritisation in software teams. Justify case selection, recruitment and the analysis method. Distinguish observed behaviour from participants’ perceptions; use triangulation or a comparison where it serves the research question.
Reasons for prioritisation and non-negotiable checks
Perceived control, useful feedback and team coordination
Evidence for the findings, conflicting cases and limits of the study
Degree scope
Bachelor’s
Study one case or a small set of existing materials. Agree the interviews, documents or scenario tasks with the supervisor. Describe the method, analyse the findings and give practical recommendations.
Master’s
Use a clear research question and relevant IS theory. Justify the cases, participants and analysis method. Explain what the findings add to earlier research and where they may apply. No software development is required.
Background
Literature review and academic writing
Qualitative or quantitative research methods
Interest in test prioritisation in software teams; no programming prerequisite
Possible deliverables
A literature review and research question
A study plan and approved research material
An analysis supported by interviews, observations, documents or scenario results
A thesis with findings, recommendations and limitations
Scope and access
Keep evaluation budgets fixed and avoid future-result leakage. Prioritisation must not silently remove required security or contract checks. These implementation-related limits apply when developing or testing a technical solution. For a non-technical study, agree access to participants or existing materials early, use approved or fictional cases where appropriate, and distinguish perceptions from observed outcomes.
Agree access to data, participants or existing materials and any required ethics or privacy review before committing. A non-technical track needs a systematic study, not a working prototype.
Full academic proposal
Working topic
Adaptive Test Prioritisation Under Limited Development Budgets
Brief outline
This proposal examines test prioritisation in software teams in the work and information needs of developers and quality-assurance staff. The technical track combines a literature review and justified gap with requirements, design, implementation and evaluation of a bounded solution. The non-technical track investigates practices, experiences or organisational conditions through a systematic study of existing systems, documents or scenarios, without requiring implementation. Choose one track and agree the final research question, degree scope and contribution with the supervisor.
Programme fit
Information Systems. These are suggested research approaches, not a statement of confirmed programme policy. Agree the final title, track, degree scope and contribution with the supervisor and programme.
Shared research foundation
Review the literature; identify and justify a gap; formulate research questions; conduct a systematic study; analyse the evidence; explain the contribution relative to prior research and discuss limitations. The technical track additionally includes requirements, design, implementation and evaluation of an artifact.
