IIIT-Delhi Students: Scoping a 6-Week Testing Internship Around Open-Source Projects

To scope a testing internship around an open-source project, pick one small, active repository, write three to five testable goals, and attach a deliverable to every week. If your window is only 14 days, as with the free internship mentioned below, keep the same logic but cut the scope to one module and one or two test types.

This guide gives IIIT-Delhi students a full scoping worksheet, a worked illustrative plan, and a comparison with company-assigned scopes. The six-week structure is used as the base, and a compressed 14-day version follows it.

Why open-source repositories suit a self-scoped testing internship

Company-assigned internships usually come with a ready backlog, a test environment and a mentor. An open-source internship has none of these unless you build them yourself. That is both the risk and the benefit. You choose the target, you define “done”, and every artefact (bug report, test file, pull request) is public and can be shown to a reviewer later.

Testing is one of the better fits for this approach because contributions can be small and self-contained:

• A reproducible bug report with logs and environment details.
• A new unit or integration test for an uncovered function.
• A test plan or exploratory-testing charter for one feature.
• A fix for a flaky test, or a documentation correction found while testing.

The catch is that maintainers owe you nothing. Reviews can take days, and some projects ignore outside pull requests. A good scope therefore never depends on a maintainer merging your work. Measure success by what you produced and verified, not by what was accepted.

The repository selection scorecard

Score each candidate repository from 0 to 2 on every row. A total below 10 out of 16 suggests looking for another project.

Run this check in an afternoon. Clone the repo, follow the README exactly as written, and run the existing tests. How far you get tells you more than the star count.

The scoping worksheet: fields to fill in before you start

Copy these fields into a document and complete every one. Incomplete fields signal an unclear scope.

1. Repository and version: URL, commit hash or release tag you are testing, and the date you cloned it.
2. Target module: the one folder, package or feature you will focus on. Name it specifically.
3. Test types in scope: choose from unit, integration, API, UI, exploratory, regression, performance, accessibility. Pick two or three at most.
4. Test types out of scope: write these down so scope creep has a boundary.
5. Goals (3 to 5): each must be measurable, such as “raise branch coverage of module X from the measured baseline to a higher figure” or “file five reproducible bug reports with steps and logs”.
6. Baseline measurements: coverage figure, number of existing tests, open issue count in the module, recorded in week 1.
7. Tooling: test framework, coverage tool, issue tracker, any CI the project uses.
8. Deliverables: the exact files or links you will hand over.
9. Risks and fallbacks: what you will do if setup fails, if no one responds, or if the module proves untestable.
10. Mentor or reviewer: a faculty member, senior student or maintainer who will read your report. Name a person.
11. Weekly check-in: day and format of your self-review.

Writing test goals that can be checked

A weak goal: “Improve testing of the project.” A checkable goal: “Write ten unit tests for the date-parsing functions, each covering a distinct input class, and record pass or fail results.” The second can be verified by anyone who opens your folder. Use this pattern: action + object + quantity + evidence.

Weekly milestone template for a 6-week open-source testing plan

Worked illustration: a self-scoped plan for a small Python library

This example is illustrative. It uses an imaginary library, “datefmt”, and no code or tests were actually run.

Suppose a student picks “datefmt”, a small Python package that parses and formats dates. It scores 12 out of 16 on the scorecard: active, clear contributing guide, a test suite with gaps.

• Target module: the parsing module only.
• In scope: unit tests and exploratory testing of edge inputs.
• Out of scope: performance testing and the command-line interface.
• Goal 1: record baseline coverage for the parsing module in week 1.
• Goal 2: write 12 new unit tests across at least four input classes (leap days, time zones, malformed strings, locale formats).
• Goal 3: file up to four reproducible bug reports, each with a minimal failing input.
• Goal 4: re-measure coverage in week 6 and report the change, whether it rose or not.
• Fallback: if no maintainer responds by week 5, publish the tests and reports in a personal fork and document that outcome.

A sample bug report skeleton the student would reuse:

Title: parse() accepts day 31 for a 30-day month
Environment: Python version, OS, library version/commit
Steps: 1) call parse("2026-04-31")  2) observe result
Expected: validation error
Actual: returns a date object
Notes: related existing issue number, if any

Company-assigned scope versus self-scoped open-source scope

A sample company-assigned scope, for contrast

Illustrative only. A company might assign: “Execute the 80 regression cases for the checkout flow each sprint, log failures in the tracker, and automate five of the cases.” Here the goals, tools and acceptance rules already exist. Your worksheet would shrink to a few fields, namely which cases you own, how success is judged, and who reviews your work. In the self-scoped version, you must create all of those yourself. Treat the worksheet as practice for the discipline a company would otherwise supply.

Compressing the plan into a 14-day internship

The free two-week online internship from CareerSwami runs 14 days, with a free offer letter and a free completion certificate after successful completion. It offers 26 tracks. If you use a testing track, the six-week plan above has to shrink, and the honest way is to cut breadth, not depth.

Reduce goals to two or three, restrict the target to a single function group, and do not plan around merged pull requests, since maintainer responses rarely arrive within two weeks.

IIIT-Delhi students: checking how an open-source testing internship fits your degree rules

Whether an internship like this counts toward anything in your degree depends on IIIT-Delhi’s own rules, and those need checking at source. One document to start with is the Regulations for B.Tech. Programs (July 2019 edition). A search excerpt of it mentions course types labelled IP, IS, UR, BTP and OC, and says CSE, CSD and CSB students can do something only in the 8th semester. The excerpt is truncated, so it does not say what that activity is. The document is also from 2019, so a later version may have replaced it. Read the current regulations rather than relying on this summary.

The same excerpt points readers to the university’s ordinances on the iiitd.ac.in website. That is a sign that formal rules on training, projects or electives may be spread across more than one document. Nothing verified here covers internship duration, credits, evaluation, required paperwork or whether an online, self-scoped internship is accepted. Do not assume any of these.

The practical risk is planning six weeks of work and then finding it cannot be reported in the form your department needs. Settle this before you start, not after.

1. Download the current B.Tech regulations and ordinances from iiitd.ac.in and search them for “internship”, “industrial”, “project” and “independent study”.
2. Identify which course type (for example IP, IS, UR, BTP or OC in the 2019 text) would apply to your situation, and whether it is restricted to a particular semester.
3. Email your academic office or faculty advisor asking in writing: “Can a self-scoped, open-source testing internship be reported, and in what form?” Keep the reply.
4. Ask the Training and Placement or career office, if your batch has one, whether an offer letter and certificate from an online internship are accepted as supporting documents.
5. If you want a faculty reviewer for your final report, ask for their agreement in writing, along with the evidence they would want to see.
6. Check the academic calendar for break dates so your plan does not collide with exams.

Choosing evidence that a reviewer can verify

Whoever reads your work, whether a faculty member or a hiring engineer, will look for proof that is easy to check. Prefer these over claims:

• Links to issues and pull requests, with dates.
• A repository fork containing your tests, with a commit history showing steady progress.
• Before and after coverage output, pasted as text, with the command used.
• Your test charter and session notes, showing how you chose what to test.
• A short written reflection on what failed, including tests that did not find anything.

Do not inflate numbers. A report that says “coverage rose modestly and two of five bugs were confirmed by a maintainer” is more credible than a perfect-looking claim.

Handling blockers during a self-scoped testing plan

• Setup fails on day one: time-box it to half a day, then switch to your second-ranked repository from the scorecard.
• Existing tests are broken: record the failures as your baseline and make fixing or documenting them goal one.
• No bugs found: shift to risk-based test design and report the coverage added and the cases tried.
• Maintainer says an issue is a duplicate: link to the existing issue, add your reproduction if it helps, and move on.
• Scope is too big: narrow to one function group and update the worksheet with the date and reason for the change.

Frequently Asked Questions

How many repositories should I evaluate before choosing one?

Three is enough. Score each with the scorecard, run the setup for the top two, and commit to the one that builds and runs its tests fastest.

Should I aim for a merged pull request in a 14-day plan?

No. Maintainer response times are outside your control. Treat a submitted issue or pull request as the deliverable, and keep your tests in a fork as a fallback.

Is code coverage a good primary goal for a testing internship?

It is a useful measurable baseline but a weak goal alone, since tests can raise coverage without checking anything meaningful. Pair it with goals about defect quality, such as reproducible bug reports.

Can I test a large, popular project instead of a small one?

You can, but limit yourself to one module and expect slower reviews and heavier setup. Small and mid-sized projects usually let you finish a full cycle of plan, test and report.

How do I know whether my IIIT-Delhi department will accept this kind of internship?

Check the current regulations and ordinances on iiitd.ac.in, then ask your academic office in writing. The 2019 B.Tech regulations excerpt does not settle the question, so get an explicit answer for your programme and batch.

What belongs in the final report?

The completed worksheet, baseline and final measurements, a list of tests and bug reports with links, a short account of what changed from the original plan, and what you would test next.

Does the 14-day internship change which test types I should pick?

Yes. In two weeks, choose one or two, such as unit testing plus exploratory testing, and leave performance, UI automation and cross-browser work for a longer engagement.

Related Software Testing guides

• A Weekly Log Format for Seacom Skills University Students in Testing Internships
• Non-CS Background? A Testing Internship Starter Map for Central University of Kerala
• Remote Testing Internship Habits for Sikkim Professional University Students
• All Software Testing internship guides