Ram Krishna Dharmarth Foundation University Students: Your First Week as a Test Intern

Your first week as a test intern should go in this order: get access working, understand the product as a user, write down what you expect it to do, then report one clear, reproducible bug. In a 14-day internship, week one is the foundation and week two is where you apply it. The checklist below gives you a task, an output and a mentor question for each of the first seven days.

Why the First Week Matters in a 14-Day Testing Internship

A two-week internship leaves little time for a slow start. Interns who lose three days to broken logins, unclear scope or a missing test account rarely recover that time. Testing is also a discipline where early habits show: how you note what you did, how you describe a failure, how you ask questions.

The free two-week online internship from CareerSwami comes with a free offer letter and a free completion certificate after successful completion, across 26 tracks. Whatever track or product you work on, the week-one routine below applies. Treat it as a working plan you adapt to your mentor’s instructions, not a fixed syllabus.

What RKDF University Students Should Know Before Day 1

This section covers what can be said about RKDF University from its public pages, and what you must confirm yourself.

The university’s homepage describes it as recognised by UGC under Section 2(f) of the UGC Act, 1956, and lists schools including Information Technology, Engineering & Technology and Management. It was set up under a Jharkhand State Act of 2018, and the text of Act 22 of 2018 (an excerpt-based reading, so check the current version) places its headquarters at Ranchi. The same Act lets the university’s authorities make Regulations with Governing Body approval, which means internship or training rules, if any, would normally sit at university level in documents you can ask for.

What the public pages do not tell you is whether an online internship like this one fits your course rules. No internship, industrial training or project-work regulation was verified, so do not assume it carries academic credit, counts toward a training requirement or needs a particular letter format. The homepage links a Training & Placement page, a Training & Placement Committee page and an Academic Calendar 2026-27 PDF (uploaded October 2026). Their contents are unverified here, so check them directly, especially for exam and break dates that could collide with your 14 days.

Verification steps for RKDF students before you start

1. Open the Academic Calendar 2026-27 PDF from the homepage and mark any exams, internal assessments or holidays that fall inside your 14 days.
2. Read the Training & Placement page and the Training & Placement Committee page, and note the named contact for internship queries.
3. Email that office or your department coordinator asking in writing: “Does a voluntary online internship need prior permission or a registration with the department?”
4. Ask whether your programme’s rules mention internships at all, and request the exact regulation or notice name if they do.
5. Ask whether a completion certificate from an external online internship is accepted for any departmental record, and keep the reply.
6. Save the answers in one folder alongside your offer letter.

Day-by-Day First-Week Checklist for a Test Intern

Day 1: Getting Environment Access Without Losing Hours

Do not wait until you need something to find out it is missing. Go through this list on the first day:

• Can you open the application’s test or staging address, not a live production site?
• Do you have at least two accounts with different roles, if the product has roles (for example user and admin)?
• Do you know where bugs are logged: a tracker, a shared spreadsheet or a form?
• Which browser and device should you test on, and which versions?
• Where do you ask questions, and what response time is normal?
• Are you allowed to enter real personal data? Default to dummy data unless told otherwise.

Record every blocker with a time and the person you told. If access is still broken by the end of day 1, say so plainly. A mentor can fix a missing account quickly but cannot fix a silent delay.

Days 2 and 3: Product Walkthrough and Expected Behaviour

On day 2, use the product without trying to break it. Open every menu, create a record, edit it, delete it, log out and log back in. Draw or list a feature map: the screens, what each does, and who can use it.

On day 3, convert what you saw into expectations. A test needs an expected result, and you can only state one if you know what the product is supposed to do. If no specification exists, write your assumption and ask the mentor to confirm it. Many early “bugs” are simply wrong assumptions.

Walkthrough prompts that surface real defects

• What happens when a required field is left empty?
• What happens with the longest and shortest valid input?
• Does the back button, refresh or double-click change the outcome?
• Are error messages understandable and accurate?
• Does the same action behave the same way for every role?

Days 4 and 5: Writing and Running Your First Test Cases

Choose one small feature, such as login, sign-up, search or a form. Small scope lets you finish. Write each case with an ID, a step list, test data, expected result and a blank for actual result.

On day 5, execute every case and capture evidence as you go. Screenshots taken afterwards from memory are weaker than those taken while the failure is on screen.

Day 6: Writing Your First Bug Report, Worked Illustration

The example below is illustrative only. It is not a real defect in any product, and no code or test was run to produce it.

Title: Login accepts email with trailing space but shows "Invalid user" on retry
Environment: Test site, Chrome (latest), Windows laptop
Role: Standard user
Steps to reproduce:
1. Open the login page.
2. Enter "student@example.com " (with a trailing space) and a valid password.
3. Click Login.
4. Log out, then repeat steps 1 to 3.
Expected: Same outcome on both attempts, or a clear message about the space.
Actual: First attempt succeeds; second attempt shows "Invalid user".
Frequency: 3 out of 3 attempts
Evidence: Screenshots attached (before and after)
Severity (suggested): Medium

What makes this report useful

• The title states the problem and the condition that triggers it.
• Steps are numbered and can be followed by someone who has never seen your screen.
• Expected and actual results are kept apart.
• Frequency shows you reproduced it rather than seeing it once.
• Severity is labelled as a suggestion, leaving the final call to the team.

Before submitting, search the tracker for duplicates. If you cannot reproduce a failure, say so honestly and describe what you saw.

Day 7: Review, Feedback and Planning Week Two

Share your report and test sheet, and ask for specific feedback rather than “is this okay?” Rewrite once. Then use the remaining days to extend coverage: a second feature, a different role, another browser, or a retest of your reported bug once it is addressed.

1. List what you completed and what remains.
2. Pick one new feature and one technique you have not yet used.
3. Ask your mentor to confirm what a good final submission looks like.
4. Keep screenshots, sheets and reports organised, since you may need them to show your work.

Questions to Ask Your Testing Mentor in Week One

Keeping a Daily Test Log That Proves Your Work

A short log at the end of each day helps with feedback and with describing your work later. Use this template:

• Date and day number: for example, Day 4 of 14.
• Done: two or three specific actions.
• Found: failures, doubts, questions.
• Blocked: what stopped you and who you told.
• Next: the first task for tomorrow.

Write facts only. Do not overstate results; “ran 10 cases, 2 failed, 1 reported” is more credible than “tested the whole app”.

Frequently Asked Questions

How many test cases should I write in my first week?

Quality matters more than volume. Eight to twelve well-designed cases for one feature, fully executed with evidence, is a stronger result than fifty shallow ones across the product.

What if I cannot find any bug in my first week?

Report that honestly and show your coverage: cases run, techniques used and areas covered. Then try different roles, devices, boundary values and unusual sequences of actions. Sometimes the useful finding is an unclear message or a missing requirement.

Should I report every small issue, such as a spelling mistake?

Ask your mentor. Many teams want cosmetic issues logged separately or batched. Low severity does not mean worthless, but a clear title and a suggested severity help the team triage.

Do I need programming skills to be a test intern?

Not for the manual testing tasks in this plan. Careful observation, clear writing and curiosity matter most. Basic knowledge of how web applications work helps you describe failures precisely.

Can I start this internship during my RKDF University exam period?

That depends on your timetable. Check the Academic Calendar 2026-27 PDF linked from the university homepage, compare it with your 14 days, and ask your department if you are unsure about exam dates.

Do I need permission from RKDF University to do an online internship?

No rule on this was verified from public pages. Email your department coordinator or the Training & Placement office, ask the question in writing and keep the reply.

What should I do if my bug is rejected as “not a bug”?

Ask what the expected behaviour is and where it is documented. Update your notes and treat it as learning about the product. Disagreement handled politely with evidence is normal in testing.

How can this internship fit into my software testing preparation?

It gives you a real exercise in test design, execution and bug reporting that you can describe accurately: the feature you tested, techniques used and reports written. Describe only what you actually did.