Maharishi University of Information Technology: First-Year vs Final-Year Testing Internship Plans

A first-year student should spend a 14-day testing internship learning the vocabulary and habits of testing and producing a small, clean portfolio. A final-year student should aim for a focused, interview-ready artefact set: a test plan, a defect log, a regression suite and a short automation script. The two plans share the same 14 days but differ in depth, independence and the evidence you walk away with.

Why Year of Study Changes the Plan for a Two-Week Testing Internship

Fourteen days is short. A tester who tries to learn everything finishes with a vague impression of testing and nothing to show. A tester who picks outcomes that fit their stage finishes with specific, checkable work.

First-years usually have little programming exposure, so the risk is confusion: terms such as smoke test, regression and severity blur together. Final-years usually have programming, databases and a few projects behind them, so the risk is shallowness: they run a few tests, call it done, and cannot explain their choices in an interview. The plans below are built around those two different risks.

The free two-week online internship at CareerSwami offers a free offer letter and a free completion certificate after successful completion, with 26 tracks to choose from. Whichever track structure you follow, the roadmaps here are meant to help you decide what to practise and what to record, so the 14 days produce evidence rather than just attendance.

Side-by-Side Comparison of the Two Roadmaps

First-Year Roadmap: 14 Days of Testing Foundations

This plan assumes no prior testing knowledge. Spend roughly 1.5 to 2 hours a day, and keep every artefact in one folder so you can show it later.

Days 1 to 4: vocabulary and first test cases

• Day 1: Learn the basics: what a bug is, the difference between verification and validation, and the stages of the testing life cycle. Write a one-page glossary in your own words.
• Day 2: Learn the levels of testing (unit, integration, system, acceptance) and the types (functional, usability, compatibility). Pick one simple app to test for the rest of the internship.
• Day 3: Read the app as a user. List every feature you can see and write what you expect each to do.
• Day 4: Write your first 10 test cases in a spreadsheet with ID, steps, expected result, actual result and status.

Days 5 to 9: test design and execution

• Day 5: Learn equivalence partitioning and boundary value analysis using a field such as age or password length.
• Day 6: Expand to 20 to 25 test cases using those two techniques.
• Day 7: Execute your cases and record real results. Do not edit expected results to match what happened.
• Day 8: Learn what makes a defect report useful: a clear title, steps, expected versus actual, environment, and a screenshot.
• Day 9: Write 5 to 8 defect reports. If you found few bugs, test another browser or a phone screen.

Days 10 to 14: exploration, review and wrap-up

• Day 10: Try exploratory testing with a 45-minute time box and a simple charter, such as “explore the sign-up form with unusual input”.
• Day 11: Learn what a regression test is and mark which of your cases you would rerun after a fix.
• Day 12: Watch a short beginner demo of an automation tool and read one simple script line by line. Do not try to write one yet.
• Day 13: Ask a senior or mentor to review your test cases and defect reports. Fix at least three weaknesses they point out.
• Day 14: Write a one-page summary: what you tested, what you found, what you would do next. Tidy the folder.

First-year goal-setting table

Final-Year Roadmap: 14 Days of Interview-Ready Testing Evidence

This plan assumes you already know basic programming and have seen databases and web development. Spend 2 to 3 hours a day. The aim is a compact portfolio you can open during a placement interview.

Days 1 to 4: scope, risk and planning

• Day 1: Choose a real target: a multi-screen web app, an open-source project or one of your own projects. Write what it does and who uses it.
• Day 2: Draft a one- to two-page test plan covering scope, out-of-scope items, test types, environments, entry and exit criteria, and risks.
• Day 3: Build a risk table that ranks features by likelihood and impact of failure. This drives where you spend time.
• Day 4: Design tests for the top-risk features using decision tables and state transitions where relevant.

Days 5 to 9: execution, APIs and defects

• Day 5: Execute the high-risk cases and log defects with severity and priority, noting the difference between them.
• Day 6: Test the back end with an API client: check status codes, response bodies, missing fields and invalid input.
• Day 7: Inspect data with simple database queries to confirm that what the screen shows matches what is stored.
• Day 8: Run non-functional checks: basic performance observations, input validation for security-style issues such as script characters in fields, and accessibility basics like keyboard navigation.
• Day 9: Complete 10 to 15 defect reports and add a short likely-cause note where you can reason about one.

Days 10 to 14: automation, regression and retrospective

• Day 10: Pick 3 to 5 stable, repeatable flows such as login and search, and set up a basic automation framework in a language you know.
• Day 11: Write and run the scripts with explicit assertions and sensible waits.
• Day 12: Build a regression suite list: which cases are automated, which stay manual, and why.
• Day 13: Self-review, then ask a mentor or peer to challenge your plan and reports.
• Day 14: Write a retrospective covering what the testing found, what it missed, and what you would automate next. Prepare a two-minute spoken walkthrough.

Final-year goal-setting table

Worked Illustration: One Login Feature Tested by Each Student Type

This example is illustrative. It shows how the same feature is approached at each stage; no tests were actually run.

Take a login form with an email field and a password field that requires 8 to 16 characters.

The first-year approach

The first-year student applies boundary values to the password length and writes cases such as these:

• 7 characters: should be rejected.
• 8 characters: should be accepted.
• 16 characters: should be accepted.
• 17 characters: should be rejected.
• Blank email with a valid password: should show a clear message.

They then record real results. Suppose 17 characters is accepted. They write a defect titled “Password of 17 characters accepted although limit is 16”, with steps, expected and actual results, and a screenshot. That is a complete, useful beginner deliverable.

The final-year approach

The final-year student starts with risk: login guards every other feature, so failure is high-impact. They use a state-transition view: logged out, logged in, locked after repeated failures, session expired. Their cases cover:

• Lockout after a set number of wrong attempts and what unlocks the account.
• Session expiry and what happens to a half-completed form.
• An API call with a missing password field, checking the response code and message.
• Script characters in the email field, checking the input is handled safely.
• Whether a failed login leaks which part was wrong.

They automate the valid-login and invalid-login flows, keep lockout manual because it changes system state, and note that reasoning in the regression list. The interview value lies in explaining that choice.

MUIT Lucknow Students: Fitting a Testing Internship to Your Programme

MUIT describes itself on its main website as established under the MUIT Uttar Pradesh Act No. 31 of 2001, which makes it a state-legislated private university. The Lucknow campus home page cites Notification No. 573 dated 6 October 2001 for that Act. In practice, treat the university’s own regulations and notices as the final word on anything that touches your academic record, rather than rules you have heard from other colleges.

For first-years, the official B.Tech Computer Science course-structure page appears to list semester-I subjects including Fundamentals of Computer System & Problem Solving, Algebra & Matrices and Environmental Science. This is based on a search excerpt, so check the current version. The practical point is that your early coursework is about problem solving and basic computing, which fits the first-year plan: a testing internship should reinforce logic and clear writing rather than demand coding skill.

For final-years, timing matters. The official Placement Procedure page says the placement season begins in August and names the Corporate Resource Cell (CRC) team as the placement cell members. If you want your portfolio ready for interviews, finish it before that season, not during it. Other websites may use a different name for the cell, so rely on the official page and ask the cell directly which name and contact to use.

Whether a short online internship can be recorded in your academic file, and under what conditions, depends on university rules that are not confirmed here. Do not assume it counts for anything beyond the certificate you receive.

Verification steps for MUIT students planning a testing internship

1. Open the current B.Tech course-structure page for your branch and batch, and note whether any project, training or internship component appears in your semesters.
2. Check the university’s rules and regulations page for anything on internships, industrial training or documentation, and save a copy of what you read.
3. Email your department coordinator with one written question: “Can I list a self-chosen 14-day online testing internship in my records, and what proof is required?” Keep the reply.
4. Ask the placement cell (CRC) when your batch’s preparation sessions and registration begin, so your portfolio is ready first.
5. Check the academic calendar with your department for semester breaks before fixing your 14 days.

Daily Time Budget and Weekly Checkpoints for Both Plans

If you fall behind, cut breadth, not quality. A first-year can drop exploratory testing and keep the defect log. A final-year can reduce automation to two flows and keep the test plan and retrospective.

Choosing Whether to Follow the First-Year or Final-Year Plan

• Second-year students who have not written a program that uses a database should start with the first-year plan and add the API day from the final-year plan.
• Third-year students who can code comfortably can follow the final-year plan but reduce the target to 25 to 30 cases and 2 automated flows.
• Final-years with no testing exposure should spend Days 1 to 3 on the first-year foundations, then move to the final-year plan from its Day 3.
• First-years who already code can keep the first-year goals and attempt writing one small script on Day 12 instead of only reading it.

Frequently Asked Questions

Can a first-year student realistically learn testing in 14 days?

You can learn the foundations: terms, test case writing, two design techniques and defect reporting. You will not become job-ready in testing, and that is fine. The goal is a small body of accurate work and good habits you can build on.

Does a final-year student need to learn automation in a 14-day testing internship?

A small amount is useful, because interviewers often ask about it. Automate 3 to 5 stable flows and be ready to explain what you left manual and why. Understanding the choice matters more than the number of scripts.

Which programming language should I use for testing automation?

Use one you already know reasonably well, since 14 days leaves no room to learn a language and a framework together. The testing ideas, such as assertions and waiting properly for page elements, carry over between languages.

What should I show an interviewer after a two-week testing internship?

Bring a small folder: a test plan or case sheet, a defect log, and for final-years a script repository and retrospective. Be ready to explain one defect you found and one test you chose to skip.

How many defects should I expect to find?

There is no required number. Some applications are cleaner than others. Quality of reports matters more than count, so if you find few, vary browsers, devices and unusual input rather than inventing issues.

Can I do both plans in one internship?

No, treat them as alternatives. Combining them in 14 days spreads your effort too thin. If you finish the first-year plan early, add depth, such as more techniques or a script, rather than switching plans.

Will a CareerSwami testing internship certificate help my MUIT placement chances?

The free completion certificate documents that you completed the 14-day internship, but it does not guarantee placement. What helps is the evidence you build, so use the programme to produce a portfolio you can explain, and ask the placement cell how it views such work.

What if I only have an hour a day as a Maharishi University of Information Technology student?

Keep the same sequence but lower the targets: 15 test cases and 4 defect reports for first-years, or a smaller test plan and 2 automated flows for final-years. Protect the review and summary days, because they turn activity into evidence.

Related Software Testing guides

• Medi-Caps University Students: Regression Testing Checklist for a Four-Week Internship
• Vinoba Bhave University Students: Asking a Mentor for Testing Internship Feedback
• JECRC University Students: Python Test Automation With Pytest From Scratch
• All Software Testing internship guides