ICFAI University Nagaland Students: A Test Data Preparation Checklist for Interns

Good test data comes from three deliberate sets: boundary values that sit on the edges of every rule, invalid values that the system should reject cleanly, and realistic values that resemble what real users type. This checklist gives ICFAI University Nagaland students a repeatable way to build all three in a 14-day internship, along with a data sheet template you can copy into any spreadsheet.

Why test data deserves its own checklist

Most beginners write test cases first and invent data on the spot: “abc”, “123”, “test@test.com”. The result is a suite that passes easily and misses real defects. A bug in an age field rarely appears at age 25. It appears at 17, 18, 0, -1 or 150, and it appears when a name contains an apostrophe or a phone number carries a +91 prefix.

Preparing data before you execute has three practical benefits:

• Coverage you can explain. Every row in your data sheet traces back to a rule in the requirement.
• Repeatability. Another tester can run your cases and get the same result because the inputs are written down.
• Faster defect reports. A developer can reproduce “fails at 256 characters” far more easily than “fails on long names”.

The three data families and what each one proves

The pre-design checklist: what to confirm before creating any data

Work through these items for each feature you test. Tick them off in your notes.

1. Locate the written rule. Find the requirement, user story or screen label that states the limit. If none exists, record your assumption and flag it as a question.
2. List every input field. Include dropdowns, checkboxes, date pickers, file uploads and URL parameters.
3. Note the data type and format of each field: integer, decimal, text, date, email, phone, currency.
4. Note the limits: minimum, maximum, length, allowed characters, mandatory or optional.
5. Identify dependencies. Does the end date have to follow the start date? Does the state list change with the country?
6. Decide where the data lives. A test environment, a staging copy or a demo site. Never use real personal data.
7. Define the expected result for each value before running it, not after.

Boundary data checklist

For a numeric or length rule, test the value just below, on, and just above each edge. This is the core of boundary value analysis.

• Minimum minus one, the minimum itself, minimum plus one.
• Maximum minus one, the maximum itself, maximum plus one.
• A typical mid-range value as a sanity baseline.
• For text length: empty, 1 character, the maximum, and maximum plus one.
• For dates: the first and last valid day, the day before and after, 29 February in a leap year and in a non-leap year, and month-end dates such as 30 and 31.
• For money: 0, 0.01, the largest allowed amount, and a value with more decimal places than allowed, such as 99.999.
• For file uploads: a file exactly at the size limit, one just under it, one just over it, and a zero-byte file.
• For list or quantity fields: 0, 1, the cap, and cap plus one.

Invalid data checklist

Invalid data is not random garbage. Each value should target a specific weakness.

• Missing: blank, spaces only, null-like text such as “null” or “undefined”.
• Wrong type: letters in a number field, a number in a name field, decimals where integers are required.
• Wrong format: an email without “@”, a phone number with 9 digits, a PIN code with 5 digits or letters, a date written 31/02/2026.
• Out of range: negative numbers, zero where the minimum is 1, dates in the far past or future.
• Special characters: quotes, angle brackets, ampersands, percent signs and backslashes.
• Whitespace traps: leading and trailing spaces, double spaces, tabs.
• Duplicates: an email or username that already exists.
• Injection-style strings for a basic sanity check on a practice site: for example ' OR '1'='1 or <b>test</b>. Use these only on applications you are permitted to test.

Realistic data checklist for Indian users

Realistic data catches the defects that clean textbook values hide. Build in the diversity your users will bring.

• Names: single-word names, very long names, names with initials, hyphens, apostrophes or full stops, and names from different regions and scripts.
• Phone numbers: 10 digits, with +91, with 0 prefix, with spaces or hyphens.
• PIN codes: six-digit codes, including ones beginning with 7 for the North East.
• Addresses: multiple lines, landmarks, slashes in house numbers such as 12/B, and long locality names.
• Dates: DD/MM/YYYY entries, since many users type day first.
• Currency: amounts with commas as in 1,25,000 and the rupee symbol.
• Email: plus-addressing, subdomains and mixed case.
• Volume: a realistic count of records, such as 500 rows, rather than three.

Generate such data with fake, clearly synthetic values. Do not copy real classmates’ or customers’ details into a test sheet.

Reusable test data sheet template

Copy the columns below into Google Sheets or Excel. One row equals one data value tied to one test case.

Add two housekeeping columns if your team shares the sheet: Owner and Date executed. Keep the Expected result filled in before you run anything.

Worked illustrative example: a leave application form

The following is an illustrative scenario, not a record of an actual test run. Suppose a leave form has these stated rules: Reason is mandatory, up to 100 characters; Number of days is a whole number from 1 to 15; Start date cannot be in the past.

Following the checklist, the data design might look like this:

That produces roughly 30 data rows from three fields, each justified by a rule. Dependencies add a few more: a start date of today combined with 15 days should be checked against any rule about the end date or the month end.

Notice the expected results. For 16 days the form should reject the entry with a clear message. For 100 characters it should accept and store all of them. If the requirement does not say what happens at 0 days, you raise a question rather than guess.

A 14-day plan for building test data during your internship

A short internship rewards a clear sequence. A free two-week online internship such as the one on CareerSwami’s free two-week internship gives you a natural window to practise this. Adapt the plan below to your own track and tasks.

1. Days 1 to 2: Study the application or requirement. List fields, rules and assumptions.
2. Days 3 to 4: Build the data sheet header and fill boundary values for every numeric, length and date field.
3. Days 5 to 6: Add invalid data using the checklist above.
4. Days 7 to 8: Add realistic data, including regional names, phone formats and addresses.
5. Days 9 to 10: Execute the rows and fill Actual result and Status.
6. Days 11 to 12: Write defect reports that quote the exact Data ID and input value.
7. Days 13 to 14: Clean the sheet, remove duplicates, and write a one-page summary of coverage and open questions.

ICFAI University Nagaland students: preparing test data alongside your programme

The university’s homepage lists programmes including BCA, BCA in Cyber Security, MBA and MCA. Testing skills are useful across these paths, whether you work on application screens, security-minded input checks or business forms. The same site describes the university as established under a 2006 state Act and says it is empowered by UGC to award degrees, so it is a private university rather than an affiliating one.

What the published pages do not settle for this article is how internship work is treated academically. The site menu includes a Summer Internship page, but its rules on duration, evaluation, documents and online internships should not be assumed. A free online internship with an offer letter and completion certificate is a learning experience; do not assume it satisfies any university requirement without written confirmation.

There is also a location detail to be careful with. A Nagaland government PDF from 2019 gives the address as 6th Mile, Sovima, Dimapur, while the homepage metadata mentions Kohima. Check the current version before you put a campus address in any report or form. For test data, this is a good reminder that real-world records contain inconsistencies worth testing.

Use these steps to verify what applies to you:

1. Open the Summer Internship page and any linked 2026 PDF, and note the stated duration, eligibility and documents.
2. Email your department coordinator asking whether an online internship from an outside provider is acceptable, and keep the reply.
3. Ask in writing whether a certificate or report must follow a specific format or be signed by a particular person.
4. Check the academic calendar page for semester break dates so your 14 days do not clash with exams.
5. Ask the placements office what, if anything, they want to see from testing work, such as a portfolio sheet.
6. Confirm the correct campus address from the contact page before using it in any document.

Data hygiene rules before you share your sheet

• Use only synthetic data; never real Aadhaar, PAN, bank or phone numbers.
• Label which values are intended to fail so reviewers do not read them as errors.
• Keep one source-of-truth sheet, with version names such as v1, v2.
• Mask or remove anything copied from a live system.
• Record the environment and build version beside your results.

Frequently Asked Questions

What is the difference between boundary data and invalid data?

Boundary data sits at the edge of the allowed range, and some of it is valid, such as 18 in an 18 to 60 rule. Invalid data breaks the rule outright or has the wrong type or format, such as letters in a number field.

How many data values should I prepare per field?

Enough to cover each rule, usually six boundary values for a range, several invalid types and two or three realistic entries. Quality matters more than volume, so every row should tie to a rule or a risk.

What should I do when the requirement does not state a limit?

Record your assumption, test a sensible set of values, and raise the gap as a question in writing. An undefined limit is itself a finding worth reporting.

Is it safe to use injection strings in my invalid data?

Only on practice applications or systems you have explicit permission to test. Never try them on live production sites or services you do not own.

How do I make test data look realistic without using real people’s details?

Create fictional names, numbers and addresses that follow real formats, or use a data generator. Keep patterns such as +91 prefixes and six-digit PIN codes, but make the values clearly synthetic.

Should the expected result be written before or after execution?

Before. Writing it afterwards lets you rationalise whatever the application did, which hides defects.

Can I use this checklist for a two-week testing internship?

Yes. The 14-day plan above splits the work into design, execution and reporting, and the data sheet doubles as a portfolio item you can discuss in interviews.

Does the same data design work for automated tests?

Yes. Each row of the sheet can become a parameter set in a data-driven test, so a clear sheet makes later automation simpler.