Medi-Caps University Students: Regression Testing Checklist for a Four-Week Internship

You can build a useful regression suite in a short internship, but only if you keep it small, risk-ranked and easy to re-run. This guide adapts the plan to a 14-day internship: roughly 20 to 30 well-chosen checks, a prioritisation matrix to select them, and a release-day checklist to run them.

What a regression suite is and what it can realistically cover in 14 days

Regression testing re-checks existing behaviour after a change, to confirm that what worked yesterday still works today. A regression suite is the saved, repeatable set of checks you run for that purpose. It is not “every test case ever written”. A suite nobody can finish before a release is a suite nobody runs.

In a 14-day window, your realistic output is:

• A written list of the product’s critical user journeys.
• 20 to 30 regression checks, ranked by risk, each with clear steps and expected results.
• A smoke subset of 5 to 8 checks that takes under 15 minutes.
• A short maintenance log explaining what you added, removed or changed, and why.
• A release-day checklist someone else can follow without you.

Automation is optional. A clean manual suite with good documentation is more valuable than a half-working script folder. If you do automate, automate only the stable, high-priority checks, and say so honestly in your report.

A 14-day plan for building the suite

Prioritisation matrix: deciding which checks enter the suite

You cannot test everything, so score every feature on three factors, each from 1 (low) to 3 (high):

• Business impact: what is lost if this breaks (payments, logins, data loss score 3; cosmetic pages score 1).
• Failure likelihood: how often this area changes or has had defects before.
• Usage frequency: how many users touch it, how often.

Add the three scores. A total of 8 to 9 means “always run”; 6 to 7 means “run in full regression”; 3 to 5 means “run only if time allows or the area changed”.

Tie-breakers when two features score the same

• Pick the one with a recent defect first; bugs cluster.
• Pick the one that other features depend on (authentication before dashboards).
• Pick the check that is quicker to run and gives a clear pass or fail.

Worked illustrative example: scoring a student-portal style app

This example is illustrative only. It uses an imagined web app with a login, course list, assignment upload and a help page; no real system or test run is being described.

From this, the suite would hold several login checks (valid, invalid password, locked session, logout), upload checks (allowed file type, oversized file, interrupted upload, resubmission) and two or three search checks. The smoke subset would be one valid login, one upload and one course search. Suppose a developer then changes the file-size limit. The upload checks move to the top of the run order, and you add a new check for exactly the new limit. The help page stays untouched.

How to write a regression check that survives maintenance

Each check should be understandable by someone who has never seen the app. Use a consistent template:

ID: REG-014
Title: Upload rejects file above size limit
Priority: P1
Precondition: Logged in as a student user
Steps:
1. Open the assignment page
2. Choose a file larger than the stated limit
3. Click Submit
Expected: Clear error message; no file saved; page stays usable
Linked bug / change: (reference if any)
Last reviewed: (date)

Good habits:

• One check, one purpose. Merge only when the steps genuinely overlap.
• Write expected results as observable facts, not “works fine”.
• Record test data separately so a data change does not break ten checks.
• Link every check to a feature, and every bug-fix check to its defect ID.

Maintaining the suite so it does not rot

Maintenance is the part most beginners skip. Even in 14 days, build the habit with a simple review routine:

1. Remove checks for features that no longer exist.
2. Update checks whose steps or screens have changed.
3. Merge near-duplicates that test the same behaviour.
4. Add a check for every escaped or fixed defect that mattered.
5. Flag flaky automated checks and quarantine them instead of ignoring red results.
6. Record each change in the maintenance log with a date and reason.

A flaky check that fails randomly teaches the team to ignore failures, which is worse than having no check.

Release-day regression checklist

Use this on the day a build goes out. Tick each item and note who did it.

Before the run

• Confirm the build number or version you are testing and where it is deployed.
• Read the change list; mark which features were touched.
• Check the test environment matches the target: configuration, data and browser or device list.
• Confirm open known defects so you do not re-report them.
• Reset or prepare test accounts and data.

During the run

• Run the smoke subset first. If any P1 smoke check fails, stop and report; do not continue on a broken build.
• Run touched-area checks next, then the remaining P1 and P2 checks.
• Capture evidence for failures: steps, screenshot or log, build number.
• Retest each fixed defect, then rerun the neighbouring checks.
• Run P3 checks only for areas that changed.

After the run

• Summarise: checks planned, run, passed, failed, blocked.
• List open defects with severity and your go or no-go input (the decision belongs to the team, not the intern).
• Update the suite: new checks, removed checks, notes on flaky ones.
• Store the results where the team can find them.

Pitfalls that weaken a short-stint regression suite

Medi-Caps University and regression testing practice: what the official pages say

Medi-Caps University is in Indore, and its site gives the address as A.B. Road, Pigdamber, Rau, Indore, Madhya Pradesh 453331, on the B.Tech Computer Science and Engineering programme page. That page lists Programme Educational Objective 3, which promotes a research culture through internships, industry training and projects. Its FAQ says internships are a crucial part of the curriculum and are offered through industry tie-ups and the placement cell. It gives no duration, credit or evaluation rules.

The university’s NAAC Self Study Report (excerpt) also mentions project work, industrial training and case studies, and a credit-based system with in-semester and end-semester examinations. Treat that as general context and check the current version.

What this means for you: a self-directed testing internship fits the university’s stated emphasis on practical exposure, and a regression suite with a maintenance log is a concrete project you can show. But nothing on these pages confirms whether an outside online internship counts toward any requirement, how it is evaluated, or what paperwork is needed. Do not assume it counts for anything beyond experience. If you plan to use it in a department submission, ask first.

If you need a hands-on project to practise on, the free two-week online internship from CareerSwami offers a free offer letter and a free completion certificate after successful completion, across 26 tracks.

Verification steps for Medi-Caps students

1. Ask your department coordinator, in writing, whether an online internship of 14 days is acceptable for any internship requirement in your scheme.
2. Open the current CSE Curriculum and Syllabus PDF for your admission batch on medicaps.ac.in and look for internship or industrial training entries and their credits.
3. Ask the placement cell what documents (offer letter, certificate, report) they expect as proof of an internship.
4. Ask who evaluates an internship report and in which semester it must be submitted.
5. Check the official academic calendar for the 2026-27 session before planning your 14 days around exams.
6. Keep email replies; they are your record if rules are later questioned.

What to put in your final report and portfolio

• The feature inventory and filled-in prioritisation matrix.
• The suite itself: IDs, priorities, steps, expected results.
• The smoke subset and run timings.
• One completed release-day checklist from your dry run.
• The maintenance log with at least five dated entries.
• A short reflection: what you would automate next and what you would drop.

Never present illustrative numbers as real results. Report only what you actually ran.

Frequently Asked Questions

How many regression test cases should I write in 14 days?

Aim for 20 to 30 well-written checks plus a smoke subset of 5 to 8. Quality, ranking and clear expected results matter more than volume.

What is the difference between a smoke suite and a regression suite?

A smoke suite is a quick check that the build is stable enough to test at all. A regression suite is the broader set that confirms existing features still work after changes. The smoke set is usually a subset of the P1 checks.

Should I automate my regression checks during the internship?

Only if the application is stable and you have the time. Automate a few high-priority flows such as login, and keep the rest manual and documented. Be honest in your report about what is automated.

How do I decide which tests to run when a release is tomorrow?

Run the smoke subset, then checks for the features named in the change list, then remaining P1 and P2 checks. Skip P3 checks unless their area changed.

How often should a regression suite be reviewed?

After every release at minimum, and whenever a significant feature changes. Remove obsolete checks, update changed steps and add a check for each important fixed defect.

What should I do with a flaky automated test?

Quarantine it, note the suspected cause (timing, data, environment) and fix it before returning it to the suite. Do not leave it failing silently.

Can I use this regression suite as proof of experience in a Medi-Caps internship submission?

It works well as a portfolio piece, but whether it satisfies a university requirement depends on department rules that are not stated in the public pages. Ask your coordinator in writing before relying on it.

Does the suite need to cover mobile and different browsers?

Cover the browsers or devices your users actually use, as agreed with your mentor. Start with one primary browser for the full suite and run only the smoke subset elsewhere.

Related Software Testing guides

• Vinoba Bhave University Students: Asking a Mentor for Testing Internship Feedback
• JECRC University Students: Python Test Automation With Pytest From Scratch
• Vidyashilp University: A Testing Internship for Business and Liberal Arts Students
• All Software Testing internship guides