ICFAI University Tripura Students: Building a GitHub Repo for Testing Internship Work

Yes, a well-organised GitHub repository is one of the best ways to show what you did in a testing internship. The trick is to publish your own thinking (test cases, scripts, bug reports, summaries) and never the client’s data, credentials or screenshots. This guide gives you a folder structure, a README template, a data-safety checklist and a 14-day plan you can follow.

Why a testing internship needs a repository, not just a certificate

A certificate says you finished. A repository shows how you think. Reviewers of fresher QA profiles usually want to see whether you can write a clear test case, separate a defect from an observation, automate a small check and explain your result. None of that is visible on a PDF.

A repository also forces good habits that matter on real teams: version history, readable naming, and a habit of writing down what you tested and what you did not. For a two-week internship, the repo does not need to be large. Twenty well-written test cases, one small automation script and two clear bug reports beat a hundred copied examples.

Repository folder structure for test cases, scripts and reports

Use one repository per internship, or one per project if you work on several. Keep the layout predictable so that anyone can find things in under a minute.

testing-internship-portfolio/
├── README.md
├── .gitignore
├── LICENSE
├── docs/
│   ├── test-plan.md
│   ├── scope-and-assumptions.md
│   └── daily-log.md
├── test-cases/
│   ├── functional/
│   │   └── TC-LOGIN-001.md
│   ├── negative/
│   ├── boundary/
│   └── test-cases-summary.csv
├── automation/
│   ├── requirements.txt
│   ├── config.example.env
│   ├── tests/
│   │   └── test_login_page.py
│   └── utils/
├── bug-reports/
│   ├── BUG-001.md
│   └── bug-summary.csv
├── reports/
│   ├── execution-summary.md
│   └── screenshots-sanitised/
└── samples/
    └── dummy-data.csv

What each folder is for

A naming convention that keeps test artefacts traceable

• Test cases: TC-[MODULE]-[number], for example TC-LOGIN-001. Keep the ID in the file name and inside the file.
• Bugs: BUG-[number], with a severity and priority field in the body.
• Scripts: name them after the feature, such as test_login_page.py, and mention the test case IDs they cover in a comment.
• Commits: short, present-tense messages such as “Add boundary cases for password length”.

This traceability lets a reader jump from a requirement to a test case, then to a script and a bug, which is exactly what real QA teams value.

Test case template you can copy

Save one Markdown file per test case, or one row per case in the CSV. Here is a compact template.

README template for a testing internship repository

The README is the first thing a recruiter or mentor reads. Keep it to one screen of essentials, then link to details.

# [Project name] - Software Testing Internship Portfolio

## Summary
Two or three lines: what application type was tested (described generally),
what you tested, and the duration (14 days).

## My role and scope
- What I tested: e.g. login, registration, search (functional + negative)
- What I did not test: e.g. performance, security
- Tools used: e.g. Python, pytest, Selenium, Excel/Sheets, Markdown

## Repository map
- docs/ - test plan, assumptions, daily log
- test-cases/ - N test cases (functional, negative, boundary)
- automation/ - M scripts and how to run them
- bug-reports/ - K defects with severity
- reports/ - execution summary

## Results at a glance
| Metric | Count |
|---|---|
| Test cases written | |
| Executed | |
| Passed / Failed / Blocked | |
| Bugs reported | |

## How to run the automation
1. Create a virtual environment
2. pip install -r automation/requirements.txt
3. Copy config.example.env to .env and add your own values
4. Run: pytest automation/tests

## Data and confidentiality note
All data in this repository is dummy data created by me. No client data,
credentials or internal screenshots are included.

## What I learned
Three honest bullet points.

Keeping client data out of your repository

This is the part most beginners get wrong. A public repository is visible to everyone, and removing a file later does not erase it from Git history. Prevent leaks before the first commit.

Data-safety checklist before every push

1. Write the .gitignore first. Add .env, *.key, *.pem, config.local.*, *.log, and any folder of raw exports before you commit anything.
2. Use a config.example.env. It lists variable names with placeholder values, such as BASE_URL=https://example.test and PASSWORD=changeme.
3. Invent your test data. Use made-up names, phone numbers and emails. Do not copy rows from a real database, even “just a few”.
4. Generalise the product. Write “an e-commerce web application” unless you have written permission to name the client.
5. Sanitise screenshots. Crop or blur names, emails, order numbers, internal URLs, browser bookmarks and open tabs.
6. Remove internal links. Staging URLs, ticket numbers and project codes can identify the client.
7. Scan your changes. Run git diff --staged and read every line before committing.
8. Get written permission from your mentor if you want to name the company or share anything beyond your own writing.

If a secret is committed by mistake

• Treat the credential as compromised and ask the owner to revoke or rotate it immediately.
• Do not rely on deleting the file in a later commit; the history still holds it.
• Remove it from history with a history-rewriting tool, or delete the repository and start fresh if it is new.
• Tell your mentor. Reporting early is far better than hoping nobody notices.

When in doubt, make the repository private while you work and switch it to public only after a final review.

Worked example: turning one day of testing into repository content

The following is illustrative and invented. No code or tests were actually run.

Suppose on day 4 you test a practice login page. You write three test cases, automate one, and find one defect.

• test-cases/negative/TC-LOGIN-002.md: “Login rejects an empty password field.” Steps: open the page, enter “demo_user_01”, leave the password blank, click Login. Expected: a validation message appears.
• automation/tests/test_login_page.py: one test that mirrors TC-LOGIN-002, with a comment “Covers TC-LOGIN-002”. The base URL and credentials are read from environment variables, not typed into the file.
• bug-reports/BUG-001.md: Title: “No validation message when password is empty”. Environment: browser and version. Steps to reproduce, expected versus actual, severity Medium, status Open. The screenshot has been cropped to show only the form.
• docs/daily-log.md: “Day 4: wrote 3 negative cases, automated 1, raised BUG-001. Not yet covered: password reset.”

Commit message: “Add negative login cases and BUG-001”. Notice what is absent: no real user, no real URL, no secret. A reader still sees your method.

A 14-day plan for building the repo alongside your internship

If you join the free two-week online internship from CareerSwami, which gives a free offer letter and a free completion certificate after successful completion, you can use the repository as the running record of your work. The plan below fits any 14-day testing internship.

Documenting internship work for ICFAI University Tripura students

The university’s Summer Internship page says the faculty-supervised programme is undertaken after the second and fourth semester of each programme. It describes the aims as applying classroom concepts to real situations, simulating a real work environment and assigning time-bound company projects. A repository supports all three: it shows concepts applied, a professional workflow and a time-boxed deliverable.

For B.Tech students, the B.Tech programme page lists Summer Internship Program I after Semester IV and II after Semester VI in the Civil, CSE and ECE structures. The CSE structure also includes Database Management Systems, Computer Networks and Industry Coding Practice (Python and R), which map well to testing work such as database checks, API behaviour and scripting. The page notes the structure may change marginally, so check the current version.

The ICFAI group page for Tripura says the Placement Cell also handles industrial visits and the Summer Internship Programme, working under a Placement Officer. That excerpt is a pointer to who may handle paperwork, not a full rule.

What is not verified here: the university’s formal rules on duration, credits, evaluation, required documents, or whether an online internship counts towards the university requirement. Do not assume a free online internship satisfies the summer internship requirement. Also ask whether the department expects a report and whether a public repository is acceptable alongside it.

Verification steps for ICFAI Tripura students

1. Email the Placement Cell or your internship coordinator and ask in writing whether an online, self-sourced internship is acceptable for the Summer Internship Program.
2. Ask for the current internship guidelines document: minimum duration, credits, evaluation method and required report format.
3. Ask whether a certificate, offer letter or NOC from the host is required, and in what format.
4. Ask your faculty supervisor whether a GitHub link can be submitted as supporting evidence, and whether it must be private.
5. Check the current B.Tech structure page for any change to the internship placement in your semester.
6. Save the replies and keep them with your repository documentation.

Quality checks before you share the repository link

• A stranger can understand the README in two minutes.
• Every test case has an ID, expected result and status.
• Every bug has reproducible steps and a severity.
• The automation runs from a clean clone using only the README instructions.
• No file contains a real name, password, token, internal URL or client logo.
• The commit history reads as a sensible story, not one giant upload.
• Your claims are honest: say “automated 3 checks”, not “built a test framework”.

Presenting the repository on a resume and in interviews

Add the link under Projects with one line: “Designed 20 test cases, automated 3 checks in Python and logged 2 defects in a 14-day testing internship.” Use only numbers that match your repository. In interviews, be ready to explain one test case, why you chose its data, and how you would test the feature differently with more time. Interviewers care more about your reasoning than your tool list.

Frequently Asked Questions

Should my testing internship repository be public or private?

Keep it private while you work. Make it public only after a final data-safety review, and only if your mentor or host has not asked you to keep the work confidential.

Can I name the company I tested for in the README?

Only with written permission. Otherwise describe the product generally, such as “a web-based booking application”. Your offer letter or mentor can clarify what is allowed.

What if my tests were on a real client system?

Then the artefacts may be confidential. Rewrite your cases against a public practice site or invented scenario, and show your method without exposing the client’s screens, data or workflows.

How many test cases are enough for a 14-day internship portfolio?

There is no fixed number. Around 15 to 30 clear, well-structured cases with results, plus a few defects and one small script, is a realistic and credible amount for two weeks.

Do I need automation code in the repository?

Not strictly, but a small script shows initiative. If you include it, keep it simple, explain how to run it, and keep credentials in an ignored config file.

Can ICFAI Tripura students use this repository as their university internship report?

Do not assume so. The university’s Summer Internship page does not state report or format rules, so ask your faculty supervisor or Placement Cell what the department requires, and treat the repository as supporting evidence.

How do I remove a file I accidentally committed with a password?

Revoke the password first, then remove the file from Git history using a history-rewriting tool, or recreate the repository if it is new. Deleting it in a later commit is not enough.

Which Markdown or CSV format is better for test cases?

Use Markdown for detailed cases that need readable steps and CSV for a summary you can sort and filter. Many students keep both: one file per case and one summary sheet.