Skip to content

Software Engineering Final Year Topic: Investigation of Flaky Test Classification Evidence

This Software Engineering final year project investigates distinguishing nondeterministic failures from repeatable defects, focusing on software lifecycle evidence, reproducible verification and the limits of the chosen engineering method.

Why choose this project topic?

The topic gives distinguishing nondeterministic failures from repeatable defects a measurable software-engineering purpose beyond building another application. Comparing classification precision, unresolved failures and rerun cost supports a defensible account of maintainability, testing or delivery trade-offs, with concrete examples of both useful findings and cases the method misses.

How do the selected software-engineering methods affect classification precision, unresolved failures and rerun cost when distinguishing nondeterministic failures from repeatable defects?

Choose an owned or permissively licensed teaching codebase, agree the controlled changes and validation plan, and narrow the evidence for distinguishing nondeterministic failures from repeatable defects.

Proposed project objectives

  1. 01Define the software artifact, expected behaviour and evidence needed for distinguishing nondeterministic failures from repeatable defects.
  2. 02Use licensed public test logs or owned repeated runs, compare classification rules and verify labels by controlled reruns.
  3. 03Compare classification precision, unresolved failures and rerun cost and document limitations and reproducibility.

A suggested research approach

Use licensed public test logs or owned repeated runs, compare classification rules and verify labels by controlled reruns. Confirm repository licences and use owned or disposable environments for mutations. Record versions, fixtures and reference outcomes, compare classification precision, unresolved failures and rerun cost with a documented baseline, and distinguish a passing bounded check from evidence about all possible software behaviour.

What you will need

  • Permitted test logs
  • Reviewed failure labels
  • Analysis scripts

Keep your project scope clear

A flaky label must not be used to dismiss a genuine defect without investigation.

Software Engineering project chapter outline

Use this outline as a starting point. You can edit the chapter titles to match your department’s format during setup.

  1. Chapter 1Introduction
  2. Chapter 2Literature Review
  3. Chapter 3Research Methodology
  4. Chapter 4Presentation and Analysis of Results
  5. Chapter 5Summary, Conclusion and Recommendations

Turn this topic into your own final year project.

Your title, department, research question and outline are ready. Add your institution, personalise the details and continue to your project workspace.

Generate the Complete Project Generation uses your word balance. Review the draft and supply your own verified research findings.