University of Burdwan Students: Documenting a Testing Internship for Your Final Report

University of Burdwan Students: Documenting a Testing Internship for Your Final Report

Facebook
Twitter
LinkedIn
WhatsApp
Email

To document a testing internship well, collect evidence every day, name every file by a fixed pattern, and write each report section within 24 hours of the work. For a 14-day internship, that means a small daily routine, one evidence folder, and a report assembled from notes rather than memory. This guide gives University of Burdwan students a full plan, a naming convention and a day-by-day timeline.

Why testing work needs stronger evidence than most internship reports

A software testing internship produces things that are easy to lose: a bug seen once, a test run that passed before a fix, a screen that looked different after an update. A reader or examiner cannot see any of it unless you captured it at the time. Statements like “I tested the login module and found several defects” are weak. A report that shows the test case, the steps, the expected result, the actual result and a dated screenshot is convincing.

The aim is not volume. It is traceability: every claim in your report should point to a file in your evidence folder, and every file should be explainable in one sentence.

What the Burdwan syllabus says about internships, and what it leaves open

The University’s BSc Computer Science syllabus is framed under the NEP 2020 Curriculum and Credit Framework for Undergraduate Programmes, effective 2023-2024. The same document lists an Internship course, INT 5081, in Semester V for all students, carrying 2 credits and 50 marks, split as Project 30 and Viva 20, with no theory or internal-assessment component. That split matters for how you write: the project portion rewards a clear, evidenced account of what you did, and the viva rewards your ability to explain it without notes.

That syllabus is a 2023-24 document, so check the current version before relying on it. It does not state a required duration, report format, page limit or whether an online internship is acceptable. Those details need confirmation from your department, and the verification steps later in this article show how.

Free 2-Week CareerSwami Internship

Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.

Apply for the free internship

The evidence-collection plan: what to capture and why

Treat evidence in six categories. Each one answers a question a reader will have.

Evidence type What to capture What it proves
Task record The task brief as given, with date and your plan for it What you were asked to do
Test design Test cases, scenarios, test data, checklists How you thought about coverage
Execution proof Screenshots or short screen recordings of runs, with visible date or URL That you actually ran the tests
Defect records Bug reports with steps, expected vs actual result, severity, environment What you found and how well you reported it
Tool output Browser developer-tools views, API client responses, logs Technical depth beyond clicking through screens
Reflection notes Three to five lines each day on what worked and what did not Learning, which feeds the viva

Rules for what you may and may not capture

  • Capture only material you are allowed to share. If a task uses someone else’s data or a private system, blur or remove names, emails, tokens and passwords before saving.
  • Never include real credentials in screenshots. Use dummy accounts and say so in the report.
  • Keep originals untouched. Make an annotated copy (arrows, boxes) and store it beside the original.
  • Record the environment each time: browser and version, operating system, device, build or URL.

A screenshot and file naming convention that survives 14 days of work

Use one pattern for every file so that sorting by name puts everything in order. The pattern below uses day number, task code, evidence type, a short description and a sequence number.

D##_T##_TYPE_short-description_##.png

D05_T02_EXEC_login-invalid-password_01.png
D05_T02_BUG_login-error-message-missing_01.png
D09_T04_API_get-users-status-200_02.png
D12_T06_NOTE_regression-summary_01.pdf
Code Meaning Example use
D## Internship day, 01 to 14 D07
T## Task number you assign yourself, starting at T01 T03
PLAN Task brief or test plan D01_T01_PLAN_scope-notes_01.pdf
CASE Test case sheet D03_T02_CASE_login-cases_01.xlsx
EXEC Execution screenshot D05_T02_EXEC_search-empty-input_01.png
BUG Defect evidence D06_T03_BUG_cart-total-wrong_01.png
API API or tool output D09_T04_API_post-login-400_01.png
NOTE Reflection or summary D14_T00_NOTE_final-reflection_01.docx

Use hyphens inside descriptions, no spaces, and keep them under six words. Use two-digit numbers so files sort correctly. If a task has no number yet, use T00.

Folder structure

  • 00_admin: offer letter, completion certificate, task brief, any instructions received.
  • 01_plans_and_cases: test plans, test case sheets, checklists.
  • 02_execution: execution screenshots and recordings.
  • 03_defects: bug reports and their screenshots.
  • 04_tool_output: developer tools, API client and log captures.
  • 05_notes: daily log and reflections.
  • 06_report: drafts, final report, figure list.

Back the folder up to a second location at the end of every few days. A lost phone or laptop in the last week is the most avoidable way to lose an entire report.

A 14-day documentation timeline for a two-week testing internship

The free two-week online internship from CareerSwami runs 14 days and offers a free offer letter and a free completion certificate after successful completion, so the offer letter and certificate belong in your admin folder. The timeline below fits any 14-day testing internship.

Days Work focus Documentation actions
1 Orientation and scope Save the offer letter and task brief. Create the folder tree. Start the daily log. Write the report’s one-paragraph scope statement.
2-3 Understanding the application and writing test cases Save test case sheets. Capture the application’s main screens as baseline images. Note assumptions.
4-6 Functional test execution Take EXEC screenshots for passed and failed cases. Record environment. Draft the Methodology section.
7 Mid-point review Check every file follows the naming pattern. List gaps. Back up the folder. Draft a half-page progress summary.
8-10 Defect reporting, boundary and negative testing Write bug reports with full steps. Save BUG evidence. Draft the Findings section as you go.
11-12 Tool-based testing and retesting Capture API or developer-tools output. Retest fixed or repeated defects and record before and after.
13 Consolidation Build the figure list and metrics table. Finish the Results and Learning sections. Remove sensitive data.
14 Wrap-up Save the completion certificate if issued. Write the final reflection. Assemble the first full draft and back up.

After day 14, reserve a few days for editing, formatting to your department’s template and preparing for the viva.

The 15-minute end-of-day routine

  1. Rename any files saved with default names.
  2. Move files into the correct folders.
  3. Add three to five lines to the daily log: tasks done, defects found, what you learned, what is pending.
  4. Add each new figure to a running figure list with a one-line caption.
  5. Check that no screenshot shows personal data or credentials.

Illustrative example: turning one day’s work into report-ready evidence

The following is an illustrative example, not a record of real testing. Suppose on Day 5 a student tests the login page of a demo web application.

  • Task T02: verify login behaviour for invalid inputs.
  • Test case: TC-LOGIN-03, enter a valid email with a wrong password. Expected: an error message stating the credentials are invalid. Actual: the page reloads with no message.
  • Files saved: D05_T02_CASE_login-cases_01.xlsx, D05_T02_EXEC_login-invalid-password_01.png, D05_T02_BUG_login-error-message-missing_01.png.

The defect entry in the report might read:

Defect ID: BUG-002
Title: No error message after login with wrong password
Environment: Chrome (version noted), Windows laptop, demo site URL
Steps: 1) Open login page 2) Enter valid email 3) Enter wrong password 4) Click Login
Expected: Visible message "Invalid credentials"
Actual: Page reloads, fields cleared, no message
Severity: Medium (user gets no feedback)
Evidence: Figure 7 (D05_T02_BUG_login-error-message-missing_01.png)

In the report, Figure 7 carries a caption such as “Login page after submitting a wrong password; no error is displayed (Day 5)”. The viva answer then writes itself: what you tested, what you expected, what happened and why you rated it medium.

Structuring the final report around your evidence

Report section Built from Typical length guide
Introduction and scope Day 1 notes, task brief Half to one page
Methodology Test plan, case sheets, tools list One to two pages
Test execution summary EXEC files, daily log One to two pages
Defect findings BUG files, defect records Two to three pages
Tool-based testing API and tool captures One page
Results and metrics Counts of cases run, passed, failed, defects by severity One page with a table
Learning and reflection NOTE files One page
Appendix Full case sheets, extra screenshots, certificate copy As needed

These lengths are a suggestion only; follow whatever page limits your department sets. Only report numbers you can trace to your files. A results table is useful when every count matches a case sheet.

Linking your testing work to your coursework

The Honours course structure in the University’s Computer Science syllabus includes Software Engineering and Database Management Systems among its core courses, alongside a Python Programming skill course. If your testing work touched requirements, test levels or database checks, one or two sentences connecting your observations to those subjects show that you can apply classroom ideas. Keep such links accurate and modest; do not claim a course covers something you have not confirmed.

For Burdwan students: aligning your testing report with INT 5081 requirements

The syllabus describes INT 5081 as a Semester V internship worth 2 credits and 50 marks, divided into a 30-mark project and a 20-mark viva. In practice, that suggests building your evidence folder so it can serve two purposes: a written project report and a short oral explanation of the same material. Prepare a one-page summary and a printed or offline figure list for the viva, since you may be asked to walk through specific defects.

The University also publishes calendars for its affiliated colleges, such as the 2023-24 Academic Calendar, which shows examination periods and recess weeks. That one is old, so use it only as an example of what to look for, and find the current calendar for your own college before planning when to do the internship and submit the report.

The syllabus does not state internship duration, required documents, evaluation procedure, or whether an online internship is accepted. Because affiliated colleges may handle arrangements, do not assume a rule until it is confirmed.

Verification steps for Burdwan students

  1. Ask your department office or internship coordinator in writing whether a 14-day online internship satisfies INT 5081, and request the answer by email or notice.
  2. Download the current Computer Science syllabus from the University website and compare it with the 2023-24 version.
  3. Ask for the report template or format guidelines: page limit, font, binding, declaration and certificate pages.
  4. Ask who evaluates the project and viva, and whether an external supervisor’s letter is needed.
  5. Confirm the submission deadline and viva date from your college’s current academic calendar.
  6. Ask whether screenshots and appendices count toward the page limit, and whether company or platform data must be masked.

Writing quality: how to describe testing work without exaggeration

  • Use verbs that match what you did: “executed”, “reported”, “retested”, not “led” or “owned” unless true.
  • State limits: “Testing covered the login and search modules only.”
  • Separate observation from opinion: what happened, then what you think it means.
  • Give counts with context: “18 of 24 cases passed” is better than “most tests passed”.
  • Do not invent tools, metrics or achievements. A modest, accurate report scores better in a viva than an impressive one you cannot defend.

Final pre-submission checklist for a testing internship report

  1. Every figure has a number, caption, date and matching file name.
  2. Every defect has steps, expected result, actual result, severity and environment.
  3. Numbers in the results table match the case sheets.
  4. No credentials, personal data or private information appear in any image.
  5. The offer letter and completion certificate are in the appendix or admin folder as your department requires.
  6. The report follows the department’s format.
  7. You can explain any three defects aloud without looking at the page.
  8. A backup copy exists in a second location.

Frequently Asked Questions

How many screenshots should a 14-day testing internship report include?

There is no fixed number. A reasonable approach is one clear screenshot per significant test result and per defect, plus a few baseline and tool-output captures. Quality and traceability matter more than count, and your department’s page limit may set the ceiling.

Should I record my screen instead of taking screenshots?

Short recordings help for defects that depend on a sequence of steps, such as a flicker or an intermittent error. Still extract a key frame as a screenshot for the report, since printed reports cannot play video. Name both files with the same pattern.

What if I forget to capture evidence on a particular day?

Repeat the test if the application is still available, and record the real date you re-ran it. Do not backdate files or claim the capture was made on the original day. Note the gap honestly in your daily log.

How do I document a bug I cannot reproduce again?

Record what you remember immediately, attach any screenshot you captured, and mark the defect as “not reproducible” with the number of attempts. Reporting an intermittent issue honestly is a normal part of testing practice.

Can I include test cases written in a spreadsheet as proof of work?

Yes. Case sheets are core evidence. Include a summary in the body of the report and the full sheet in the appendix, using the CASE naming code so the file can be matched to the figure list.

Do I need a separate daily log if I already have screenshots?

Yes. Screenshots show results but not your reasoning or time spent. Three to five lines a day take little time and become the raw material for your methodology and reflection sections, as well as your viva answers.

Will my Burdwan department accept a certificate from an online testing internship?

That depends on your department and college, and the University syllabus reviewed here does not say. Ask in writing, as described in the verification steps above, before you rely on any certificate for INT 5081.

How should I handle screenshots that include a company’s or platform’s data?

Mask names, emails, tokens and any private information before saving the annotated copy. If you are unsure whether something is shareable, ask your supervisor or the platform before including it in a report that others will read.

Related Software Testing guides

Ready to put this into practice?

Join the free two-week CareerSwami online internship in Software Testing. The internship, the offer letter and the completion certificate are free.

Start your free 2-week internship

Web Stories

Scroll to Top