Shyam University Students: Testing a Full Stack Internship App with a Simple Test Plan

You can test a full stack internship app properly with a one-page plan: a short scope, a list of risks, and 25 to 40 manual test cases covering forms, API endpoints and edge cases. Write the plan on day 3 or 4 of a 14-day internship, run it twice, and log every failure in a consistent bug report. This article gives you the template, the sample cases and the bug format to copy.

Why a one-page test plan is enough for a two-week project

A test plan is not a thick document. For a small app, such as a task tracker, a feedback form with a dashboard, or a simple booking page, it answers five questions: what are we testing, what are we not testing, how, with what data, and when. If a reviewer can read it in two minutes and know how reliable your app is, it has done its job.

Students usually skip testing because it feels like extra work after the “real” coding. In practice, a handful of untested cases cause most demo failures: an empty form submitted, a token that has expired, a duplicate email, a string where a number was expected. A plan forces you to think about these before your mentor or a classmate finds them.

The free two-week online internship from CareerSwami runs for 14 days, so the plan below is sized for that: light enough to maintain while you build, structured enough to show in a portfolio or interview.

The one-page test plan template for a full stack app

Copy this into a README section, a Google Doc or a Markdown file named TEST_PLAN.md. Fill every line; keep each answer to one or two sentences.

TEST PLAN: [App name]   Version: [commit/date]   Tester: [name]

1. SCOPE (in)
   Features: [e.g., sign-up, login, create task, list tasks, delete task]
2. OUT OF SCOPE
   [e.g., load testing, payment gateway, email delivery, IE11]
3. TEST ENVIRONMENT
   Browser(s): [Chrome latest, Firefox latest, Android Chrome]
   Backend: [Node/Express on localhost:5000]  DB: [MongoDB/MySQL, seeded]
   Tools: [browser DevTools, Postman or curl]
4. TEST DATA
   Valid user: [email/password]; second user for permission checks;
   invalid samples: empty, 300-char string, special characters, SQL-like text
5. TOP RISKS (ranked)
   1) Auth bypass  2) Data lost on save  3) Bad input crashes server
6. APPROACH
   Manual cases (see table), run in 2 rounds; API cases via Postman/curl;
   re-test every fixed bug.
7. ENTRY / EXIT CRITERIA
   Entry: feature merged and runs locally.
   Exit: all high-priority cases pass; no open Critical/High bugs.
8. SCHEDULE
   Round 1: Day 8-9  Round 2 (regression): Day 12
9. DELIVERABLES
   Test case table, bug log, short summary (pass/fail counts)

How to fill the risk section well

Rank risks by damage, not by how hard the code was to write. Ask: if this breaks during the demo, how bad is it? Login failing is worse than a misaligned footer. Your top three risks decide which cases you run first when time is short.

A 14-day schedule that keeps testing alongside building

Manual test cases for forms: what to check on every input

Every form, whether sign-up, login, create-item or profile edit, deserves the same core checks. Apply this list field by field.

• Required fields: submit with each required field empty, one at a time. Expect a clear message next to the field, not a blank page or a server error.
• Format validation: emails without “@”, phone numbers with letters, dates in the past where the future is required.
• Length limits: exactly at the limit, one over, and a very long string (300 or more characters). Check the UI does not break and the database does not truncate silently.
• Whitespace: a field containing only spaces, and leading or trailing spaces around an email.
• Special characters: apostrophes, quotes, <script> text, emoji, and Hindi (Devanagari) text if your app should support names in Hindi.
• Double submit: click the button twice quickly. Check you do not create duplicate records.
• After success: does the form clear, redirect or show confirmation? Does the data appear after a page refresh?
• After failure: are the values the user typed preserved so they do not retype everything?

Manual test cases for APIs: status codes, payloads and permissions

Test the API directly with Postman or curl, not only through your front end. The front end hides mistakes because it sends well-formed requests. A direct call shows what happens when the input is wrong.

1. Happy path: a valid request returns the expected status (200 or 201) and the documented JSON shape.
2. Missing fields: remove a required key. Expect 400 or 422 with a readable message, not 500.
3. Wrong types: send a string where a number is expected, or an array instead of an object.
4. Unknown record: request an ID that does not exist. Expect 404.
5. No token / bad token / expired token: expect 401 on protected routes.
6. Someone else’s data: log in as user B and try to read, edit or delete user A’s record. Expect 403 or 404. This is a common real-world bug.
7. Duplicates: create a second account with an existing email. Expect a conflict message (often 409).
8. Repeat and idempotency: delete the same record twice; the second call should fail gracefully.
9. Response hygiene: make sure responses never include password hashes, tokens belonging to others, or stack traces.

An illustrative curl call for the “missing field” case (the endpoint and fields are examples, not from a real project):

curl -i -X POST http://localhost:5000/api/tasks \
  -H "Authorization: Bearer <valid-token>" \
  -H "Content-Type: application/json" \
  -d '{"description":"No title supplied"}'
# Expected: 400 with a message such as "title is required"

Edge cases that break small full stack apps most often

Sample test case table you can paste into your plan

These rows are illustrative, written for a hypothetical task tracker with sign-up, login and task creation. Replace IDs, fields and expected results with your own app’s behaviour.

Add two result columns when you run the cases: Round 1 and Round 2, each marked Pass, Fail or Blocked, with a bug ID for every Fail.

Worked example: planning tests for a feedback form with an admin view

Illustrative scenario; no tests were actually run. Suppose you build a feedback app: visitors submit name, email, rating (1 to 5) and comment; an admin logs in to see all entries.

1. Scope: submit feedback, admin login, admin list. Out of scope: email notifications, load testing.
2. Top risks: (1) admin list visible without login, (2) invalid rating stored, (3) comment text breaking the admin page.
3. Cases derived from risks:
   • Open /admin in a private window without logging in. Expect redirect to login.
   • Call GET /api/feedback without a token. Expect 401.
   • POST rating 0, 6, “abc” and 4.5. Expect rejection for each.
   • Submit a comment containing <b>bold</b>. Expect it displayed as plain text, not rendered HTML.
   • Submit with the comment blank, if comments are optional. Expect success.
4. Result: suppose the rating 4.5 case fails because the backend accepts decimals. You log a bug (template below), fix the validation to accept integers 1 to 5 only, re-test that case, and re-run the neighbouring rating cases in round 2.

Notice that the cases came from risks, not from a random list. That keeps the plan short and the testing relevant.

Bug report template for your internship project

A good bug report lets someone else reproduce the problem without asking you anything. Keep one report per bug, in a spreadsheet, GitHub Issues or a Markdown file.

BUG ID: BUG-007
Title: Rating accepts decimal values (4.5) via API
Reported on: [date]   Build/commit: [short hash]
Environment: Chrome latest, localhost, Postman
Severity: Medium   Priority: Medium   Related test case: TC-09

Steps to reproduce:
1. POST /api/feedback with body {"name":"A","email":"a@x.com","rating":4.5}
2. Open admin list

Expected result: 400 with message "rating must be an integer 1-5"
Actual result: 201 Created; admin list shows rating 4.5

Evidence: [screenshot / copied response / console log]
Status: Open | Fixed | Verified | Won't fix
Notes: [suspected cause, fix commit, retest date]

How to set severity without arguing about it

• Critical: app crashes, data lost, or security bypass (for example, another user’s data visible).
• High: a main feature does not work, with no workaround.
• Medium: a feature works incorrectly in some conditions, or validation is missing.
• Low: cosmetic issues, typos, minor alignment.

Shyam University, Dausa: matching your test documentation to department expectations

If your internship project is also meant to support coursework or a department project, your test plan should match what your department asks for. The university’s official homepage lists a Department of Computer Science & IT and a Department of Engineering & Technology, the latter linked for B.Tech programmes and Polytechnic Diploma. Which department you belong to may decide who reviews your work and what format they expect, so find out early.

The same homepage carries a news item titled “Industry projects extend practical approach of students”, which suggests practical project work is part of the university’s public message. It does not tell you how an online internship, a self-built project or a test plan would be recorded or assessed. Rules on duration, evaluation and documents can differ by programme and scheme year, so treat any assumption as unconfirmed until a department source states it.

The homepage also shows a “Training & Placement” page under its About menu, and your semester timing is set by the university’s academic calendar PDF. Check the current version before you choose which 14 days to run your internship, so your test rounds do not collide with exams or practicals. An internship through CareerSwami gives you an offer letter and a completion certificate after successful completion; whether your department accepts such documents for any purpose is for the department to say.

Verification steps for Shyam University students testing a project

1. Open the academic calendar PDF linked above and note exam and practical dates; place your Day 8-9 and Day 12 test rounds outside them.
2. Email or visit your Computer Science & IT or Engineering & Technology department office and ask in writing whether an online internship project or its documentation has any role in your programme’s project or training requirement.
3. Ask which documents, if any, the department wants (report, certificate, mentor letter), and whether a test plan and bug log can be attached as supporting material.
4. Visit the Training & Placement page from the About menu on the official site, or the cell’s office, and ask whether they review project portfolios or give feedback on them.
5. Keep the reply, in email form if possible, in your project folder with your test plan.

Running the plan: a repeatable routine for each test round

1. Reset the database to the seed data so results are comparable.
2. Run High-priority cases first, then Medium, then Low.
3. Record the actual result immediately; do not rely on memory.
4. Log a bug per failure, with evidence, before you start fixing anything.
5. After fixes, re-run the failed case and its neighbours, since fixes often break nearby behaviour.
6. Write a three-line summary: cases run, passed, failed, plus open bugs by severity.

Ask a friend to run your plan on a fresh clone of the repository. They will find setup gaps, missing environment variables and unclear README steps that you stopped noticing long ago.

How to show your testing work in a portfolio or interview

• Link TEST_PLAN.md from your README, with the pass/fail summary at the top.
• Keep two or three well-written bug reports public to show your reasoning.
• Mention one bug you found by testing the API directly that the front end hid.
• Be honest about scope: say what you did not test, such as performance or automated tests, and what you would add next, for example Jest and Supertest for the API.

Interviewers in junior roles generally respond well to a clear explanation of how you check your own work. Do not claim coverage you did not achieve.

Frequently Asked Questions

Do I need automated tests for a 14-day internship project?

No. Manual cases documented in a table are enough for a two-week project. If you finish early, add automated API tests for your three highest-risk endpoints and mention them in the plan.

How many test cases should a small full stack app have?

Between 25 and 40 well-chosen cases is realistic. Cover each form, each endpoint and the main edge cases. Quality matters more than count; ten cases tied to real risks beat fifty copied ones.

Should I test the front end or the API first?

Test the API first as soon as an endpoint exists, because bugs there affect every screen. Then test forms end to end through the browser once the front end is connected.

What is the difference between severity and priority in a bug report?

Severity describes how badly the bug affects the app; priority describes how soon it should be fixed. A typo on the home page is low severity but may be high priority before a demo. For a solo project, setting both is optional, but it shows you understand the difference.

Can I use the same test plan for a team project?

Yes. Add an “Owner” column to the test case table and a line in the plan saying who tests which module. Avoid having developers test only their own code in the final round.

Does the internship require a test plan?

The internship does not need you to submit one for the offer letter or the free completion certificate beyond what your tasks ask. The plan is a quality habit that makes your project stronger. Follow your mentor’s or task instructions if they specify a format.

Will my university accept this test plan as part of project work?

That depends on your department and programme. Ask your department in writing, as described in the Shyam University section above, instead of assuming it will count toward any requirement.

Which tools are enough for manual API testing?

Browser DevTools (Network tab) plus either Postman or curl. Save your Postman requests as a collection and export it to the repository so reviewers can repeat your API cases.