Aurora Higher Education and Research Academy: Test Plan Template for Internship Projects

A test plan for an internship project is a one-page document that says what you will test, what you will not test, how you will test it, what could go wrong, and when you can call the testing finished. For a 14-day internship, the plan must be small enough to write in an hour and strict enough to keep you from testing everything badly. The template below does exactly that, with a filled example you can copy and adapt.

Why a 14-day internship project needs a one-page test plan

Industry test plans can run to dozens of pages. Yours should not. In two weeks you will have roughly ten working days, and some of that goes to learning the application, writing test cases, running them and reporting bugs. Without a plan, students typically spend days on the first few screens and never reach the features that matter most.

A short plan does three jobs:

• It limits your work. Writing “not in scope” next to a feature is a decision you make once, instead of a worry you carry every day.
• It makes your report believable. A reviewer can see what you planned, what you actually did and why the two differ.
• It gives you a finish line. Exit criteria tell you when to stop, which is the part most beginners skip.

If you are looking for a structured way to practise this, CareerSwami offers a free two-week online internship with 26 tracks, a free offer letter and a free completion certificate after successful completion. Any project you test, whether through that or your own college work, can use the template below.

The one-page test plan template for a software testing internship

Copy this structure into a document or spreadsheet. Each row should fit in one or two lines. If a row needs a paragraph, you are probably over-planning for a 14-day project.

Scope in plain terms: what you will and will not test

Scope is simply the boundary of your testing. Everything inside is something you promise to examine; everything outside is something you openly leave alone.

A practical way to set it is to rank features by two questions: how many users touch this feature, and how bad is it if it breaks? Login, payment and data saving usually rank high. A rarely used “About us” page ranks low.

Three rules for writing scope

1. Name flows, not pages. “Register, verify email, log in” is clearer than “registration page”.
2. Give a reason for every exclusion. “Performance testing: out of scope, no load tools available in 14 days” is honest and acceptable.
3. Cap the in-scope list. If you cannot realistically write and run test cases for an item in the time you have, move it out.

Risks in a test plan: what can go wrong and what you do about it

A risk is anything that could stop you from testing properly. In a student project, the risks are usually practical rather than technical. Writing them down early means you have a response ready instead of a surprise on day eight.

• Unstable or unavailable test build. The application is down or changes mid-test. Response: record the build version on every bug and re-test only high-priority flows after a change.
• Unclear requirements. You do not know what the correct behaviour is. Response: write your assumption in the plan and ask your mentor or project owner to confirm it in writing.
• Limited devices or browsers. Response: test the main flows on one primary combination and sample the rest.
• Not enough test data. Response: prepare a small set of valid, invalid and boundary values on day two.
• Time lost to learning the tool. Response: cap learning time at two days and use simple tools such as a spreadsheet for test cases.

Exit criteria explained: how to know your testing is done

Exit criteria are the conditions that let you stop testing and write your summary. Without them, testing never feels finished. They should be measurable, so another person could check whether you met them.

The percentages above are illustrative targets, not industry standards. Pick numbers your mentor agrees with.

Filled example: test plan for a to-do web app over 14 days

The plan below is an illustrative example for an imaginary task-management web app. It was not run against a real product, and the numbers are placeholders to show the format.

TEST PLAN - TaskTracker (illustrative)
Version tested: Build 0.9 (staging)   Tester: A. Student   Dates: Day 1 - Day 14

OBJECTIVE
Check that a user can sign up, log in, create, edit, complete and
delete tasks without data loss or confusing errors.

IN SCOPE
- Sign up and email format validation
- Log in, log out, wrong-password handling
- Create / edit / delete / mark-complete task
- Task due-date field (past dates, blank, invalid)
- Basic layout on Chrome (desktop) and one Android phone

OUT OF SCOPE (with reason)
- Load and security testing: no tools or permission
- Password reset by email: mail server not available in staging
- Safari, iOS: no device access

TEST TYPES
Functional 60% | Exploratory 20% | Usability 10% | Compatibility 10%

ENVIRONMENT
Chrome latest, Android 13 phone, 3 test accounts, spreadsheet of test data

RISKS
- Staging down: log downtime, retest critical flows after recovery
- Unclear rule on due dates: assumption written, mentor to confirm

ENTRY CRITERIA
- Staging URL reachable; test accounts created; requirements note received

EXIT CRITERIA
- All 25 planned high-priority cases executed
- 0 open critical bugs; open high bugs listed with reasons
- At least 90% of executed cases passed on final build
- Every failure has a bug report
- Summary report submitted on Day 14

DELIVERABLES
Test case sheet, bug list, one-page summary report

Day-by-day schedule for the example

Aurora University students: fitting a test plan into your internship and project terms

Aurora’s academic calendar page describes a quarter system of four 10-week terms, where the first three are for coursework and the fourth is for projects, internships, workshops, research and exchange programmes, and for clearing backlogs. The page carries a 2024 banner, so check the current version. If that structure applies to your batch, a 14-day internship fits comfortably inside a project term, and a test plan helps you show a clear scope within it.

The university’s FAQ page says the Training and Placement Department helps students find placements and internships, and that the placement cell welcomes company internships and live projects. A written test plan and summary report are the kind of evidence you can show when discussing such work, though the page does not say how any internship is assessed.

The FAQ also says pre-placement Campus Recruitment Training covers technical skills, resume building and mock interviews. A filled test plan can serve as a concrete item to discuss in a resume or mock interview.

What has not been verified is any formal rule on internship duration, credits, evaluation, required documents or whether online internships are accepted for academic purposes. Do not assume a 14-day online internship earns credit or meets a departmental requirement.

Steps to verify before you rely on this

1. Ask your department coordinator in writing whether a 14-day online internship is acceptable for your programme, and whether it counts toward any requirement.
2. Request the current internship or project-work guidelines, and check the scheme year that applies to your batch.
3. Ask what documents are needed, such as an offer letter, completion certificate, report or mentor sign-off, and in what format.
4. Confirm with the Training and Placement Department how internships are recorded and whether they need prior approval.
5. Check the current academic calendar for the dates of your project or internship term.
6. Ask whether a test plan can be submitted as part of a project report, and what template your evaluator expects.

Checklist for reviewing your own test plan before day three

• Can a stranger tell in 30 seconds what you are testing and which build?
• Does every in-scope item have at least one planned test case?
• Does every out-of-scope item have a reason?
• Are all exit criteria measurable?
• Does your schedule add up to 14 days with time left for retesting?
• Has someone senior, such as a mentor or lead, read the assumptions you made?

Frequently Asked Questions

How long should a test plan be for a two-week internship project?

One page is enough. Aim for about 300 to 500 words, using short bullets and one small table for the schedule. If it runs longer, you are likely including detail that belongs in your test cases.

What is the difference between a test plan and a test case?

A test plan describes the overall approach: scope, schedule, risks and exit criteria. A test case is one specific check with steps, input data and an expected result. The plan guides which test cases you write.

Do I need exit criteria if my project is small?

Yes. Small projects benefit most because there is always one more thing to test. Three or four measurable conditions, such as all high-priority cases executed and no open critical bugs, are enough.

What should I do if the requirements are unclear?

Write your assumption in the plan, list it as a risk, and ask your mentor or project owner to confirm it in writing. If no answer arrives, test against your assumption and mention it in the summary report.

Can I include manual testing only, without automation?

Yes. For a 14-day project, well-designed manual test cases and clear bug reports are more valuable than a rushed automation script. If you add automation, limit it to one stable flow and list it in scope.

Which risks are most common in student testing projects?

Unstable builds, unclear requirements, missing test data and limited device access. Each can be handled with a short response in the plan, such as recording the build version or sampling browsers instead of covering all of them.

Will an internship test plan count for credit at Aurora University?

That has not been verified. Ask your department coordinator in writing whether a short online internship counts for your programme and what documents they need.

How is a summary report different from the test plan?

The plan states what you intend to do; the summary report states what you did. It should list tests executed, pass and fail counts, open bugs, deviations from the plan and whether each exit criterion was met.

Related Software Testing guides

• Dr. Shyama Prasad Mukherjee University Students: Ethics and Confidentiality for Test Interns
• Durg Vishwavidyalaya Students: A Beginner Test Case Design Workbook
• Jai Narain Vyas University Students: Teamwork in Agile Testing Internships
• All Software Testing internship guides