Choosing Between QA Roles in a Software Testing Internship: A Guide for JNTUK Students

For most JNTUK students, manual QA is the best first internship role, because it teaches how to think about defects, requirements and risk, which every other testing role builds on. Automation QA suits you if you already write code comfortably, and performance testing suits you if you are curious about servers, networks and numbers. The scorecard below turns that choice into something you can fill in tonight.

Why the role matters more than the title “QA intern”

A posting that says “testing intern” can mean three very different jobs. One intern spends two weeks writing test cases and logging bugs in a spreadsheet. Another writes scripts that click through a web application automatically. A third designs load scenarios and reads response-time graphs. All three are legitimate software testing work, but they reward different habits and lead to different next steps.

Choosing deliberately saves you from a common mistake: accepting whatever is offered, finishing without a clear skill to show, and then struggling to explain what you actually did in a resume or viva. A short internship is best treated as a focused experiment in one role.

The three roles at a glance

Manual QA internship

What the work looks like

Manual testers read a requirement, work out how it could fail, execute checks by hand and report what they find. The skill is not clicking; it is deciding what to click and why.

Sample tasks for a two-week internship

• Read a short requirement document and list ambiguities or missing rules as written questions.
• Write 20 to 30 test cases covering valid input, invalid input, boundaries and error messages.
• Apply equivalence partitioning and boundary value analysis to a form with numeric or date fields.
• Execute test cases on a sample web or mobile application and record pass or fail with evidence.
• Log defects with steps to reproduce, expected result, actual result, severity and a screenshot.
• Run a quick exploratory session of 30 to 45 minutes with a written charter and notes.
• Prepare a one-page test summary: what was covered, what failed, what remains risky.

Common tools

• Test management: spreadsheets, TestRail, Zephyr, or a free alternative
• Defect tracking: Jira, Bugzilla, GitHub Issues
• Browser tools: Chrome DevTools for inspecting requests, console errors and responsive layouts
• API checks: Postman for sending requests by hand
• Screen capture: any recorder that lets you attach evidence to a bug

Automation QA internship

What the work looks like

Automation testers convert stable, repeatable checks into code. Good automation starts from good manual thinking, so an intern who skips test design usually produces fragile scripts.

Sample tasks

• Set up a project with a test runner and run a first sample test.
• Automate a login flow using stable locators (IDs, data attributes) rather than long XPath chains.
• Add explicit waits instead of fixed sleeps, and explain why in a comment.
• Refactor repeated steps into a Page Object class.
• Read test data from a CSV or JSON file to run the same test with several inputs.
• Write a few API tests that check status codes and response fields.
• Generate a readable report and commit the project to a Git repository with a clear README.

Common tools

• Browser automation: Selenium WebDriver, Playwright, Cypress
• Test runners: TestNG or JUnit (Java), pytest (Python), the built-in runner in Playwright or Cypress
• API automation: Postman collections, REST Assured, Python requests
• Version control and CI: Git, GitHub, and optionally GitHub Actions or Jenkins
• Behaviour-driven tools (optional): Cucumber with Gherkin feature files

Performance testing internship

What the work looks like

Performance testers ask whether an application stays fast and stable as users increase. The work involves modelling realistic user behaviour, generating load and interpreting results such as response time percentiles, throughput and error rate.

Sample tasks

• Define a workload: which pages or APIs matter, how many users, what ramp-up, what duration.
• Record or script a user journey and parameterise the data, such as usernames or search terms.
• Run a baseline test with a few users, then a load test, then a stress test to find the breaking point.
• Add assertions and correlation for dynamic values such as session tokens.
• Read results: average versus 90th and 95th percentile response times, error percentage, requests per second.
• Write a short findings note that names a suspected bottleneck and the evidence for it.

Common tools

• Load generation: Apache JMeter, k6, Locust, Gatling
• Monitoring: basic CPU, memory and network views on the test machine or server, and dashboards such as Grafana where available
• Analysis: JMeter listeners and reports, spreadsheets for charting
• Supporting knowledge: HTTP basics, status codes, caching, database indexing

One practical warning: only run load against systems you own or have written permission to test. Pointing a load tool at a public website can be treated as an attack.

The role-choice scorecard

Score each statement from 0 (not true of me) to 3 (very true of me). Add up each column. The highest total is your best fit for this internship; a close tie means starting with manual QA and adding one automation skill is a sound plan.

Write your score for each applicable column next to the statement. Statements that list two columns count toward both.

Reading your result

• Manual total clearly highest: take a manual QA track and aim to finish with a test case set and a bug report portfolio.
• Automation total highest: take an automation track, but write the manual test cases first so your scripts have a purpose.
• Performance total highest but statements 5, 6 and 9 are below 2: start with manual or API testing and learn HTTP before load tools.
• Totals within three points: choose manual QA with one API or scripting task added.

Worked example: one feature, three roles

Illustrative scenario only. The application, numbers and script below are invented to show how the roles differ, and the code has not been executed.

Imagine a hypothetical college event-registration site with a login page and a “Register for event” button. The requirement says a student can log in with a roll number and password, and that after three wrong attempts the account locks for ten minutes.

Manual QA view

1. Test valid login, wrong password, empty fields and a roll number in lowercase.
2. Test attempts one, two, three and four of wrong passwords, and check the lock message.
3. Ask in writing: does the lock reset after a successful login on attempt two? The requirement is silent, so it goes into the question list.
4. Log a defect if the lock message reveals whether the roll number exists, since that leaks information.

Automation QA view

The tester picks the stable, high-value checks (valid login, invalid login) and scripts them. A sketch in Python with pytest and Selenium might look like this:

def test_invalid_login_shows_error(driver):
    driver.get(BASE_URL + "/login")
    driver.find_element("id", "roll").send_keys("22KA1A0501")
    driver.find_element("id", "password").send_keys("wrong-pass")
    driver.find_element("id", "submit").click()
    error = driver.find_element("id", "error-message").text
    assert "invalid" in error.lower()

The ten-minute lock is awkward to automate because of the waiting time, so a good intern flags it and suggests testing it manually or through a configurable test setting.

Performance testing view

The tester asks what happens on the day registration opens. A possible scenario: ramp from 10 to 200 virtual users over five minutes, each logging in and registering, and hold for ten minutes. The tester watches the 95th percentile login time and the error rate. If response time climbs sharply after 120 users while errors stay near zero, the finding is a likely capacity or database bottleneck, and the note should say which metric showed it and at what load.

The same feature, three different deliverables: a defect list, a reusable script, and a load findings note.

Skills to prepare before you start

Spending the 14 days well

A two-week internship is short, so scope matters more than ambition. The free two-week online internship at CareerSwami runs 14 days across 26 tracks, includes a free offer letter and a free completion certificate after successful completion, and is a reasonable place to try one of these roles without cost. Whichever programme you pick, plan the fortnight like this:

1. Days 1 to 3: learn the application or task brief, set up tools and write down your own goal for the fortnight.
2. Days 4 to 9: do the core work for your role: test cases and bugs, scripts, or load scenarios.
3. Days 10 to 12: tidy outputs, fix flaky scripts or clarify findings, and add a README or summary.
4. Days 13 to 14: prepare a short explanation of what you did, what you learned and what you would test next.

The certificate confirms completion; your artefacts are what make the experience credible to an interviewer.

What you can keep as proof

• Manual: a test case sheet, three to five well-written bug reports and a test summary.
• Automation: a public repository with a README, a sample report and a short note on design choices.
• Performance: a scenario description, result screenshots and a half-page findings note that states the load level and metric behind each conclusion.

Remove any private data or company-specific information before you share these.

JNTUK regulations and a 14-day QA internship: what to check first

JNTUK is based in Kakinada, Andhra Pradesh, and most of its students study at colleges that follow its regulations. A short testing internship therefore has to fit around rules written at university level and applied by your own college.

One example is a 2020 document titled Common Academic Regulations (R20) for all autonomous colleges of JNTUK, hosted on an affiliated college’s website rather than on JNTUK’s own domain. Search excerpts of it say a student must register for and undergo an internship in the final semester, and must submit an internship completion certificate and a project report. The excerpt also mentions a mandatory summer industry/field internship of at least 6 weeks, with credits awarded only on submission of the required documents and a guide allotted to monitor attendance. The excerpt is fragmentary, so which programme and semester each clause covers is unclear, and the rules for your regulation may differ. Check the current version.

In practice, a 14-day online testing internship is shorter than that 6-week figure. Do not assume it replaces a mandatory internship. Treat it as extra practice unless your department confirms in writing that it can be recorded. Whatever you do, keep the paperwork a guide would ask for: the completion certificate, a dated log of tasks, and a short report. Your manual QA test cases, automation scripts or performance test notes can be organised into that report.

The same excerpt says project work carries 200 marks, though the breakdown is cut off. If you plan a final-year project, a testing deliverable such as a test plan or bug report set could support it, but only if your guide agrees.

For contacts, JNTUK has a placement cell site at pc.jntuk.edu.in. A search excerpt of its contact page lists the Director of the Industry Institute Interaction unit as the contact, but the excerpt is undated, so confirm current details. Your own college’s training and placement officer is usually the first person to ask.

Link the role you pick to your syllabus: manual QA to software engineering and test design topics, automation to your programming courses, and performance testing to databases, networks or operating systems, subject to your regulation’s actual subject list.

Checks before you commit to a testing role

• Find your regulation year (for example R20 or a later one) and read its internship clause on your college’s or JNTUK’s official notices, not only on copies hosted elsewhere.
• Ask your training and placement officer in writing whether an online internship of 14 days can be recorded, and what proof is needed.
• Ask your allotted guide or head of department what format the completion certificate and report must follow.
• Check whether credits depend on submitting documents, and get the answer by email or notice.
• Compare the 14 days against your lab and exam calendar from your department.

Common mistakes when choosing a testing role

• Picking automation without programming fundamentals. Strengthen one language first; scripts that you cannot explain will not survive an interview question.
• Treating manual testing as a lesser role. Requirement analysis and defect reporting are the skills automation depends on.
• Chasing tool names. Employers ask how you chose a test, not only which tool ran it.
• Running performance tests on live sites. Use your own or an explicitly permitted environment.
• Finishing without evidence. Keep artefacts as you go, not on the last day.

Frequently Asked Questions

Do I need to know coding to start a software testing internship?

Not for manual QA. Test design, reading requirements and writing bug reports need no programming. Automation and most performance work do need basic scripting, so build that foundation first if you want those roles.

Which QA role is best for a first-year or second-year student?

Manual QA, usually. It has the lowest entry barrier and builds the thinking that automation and performance testing rely on. You can add Postman or a simple script in the same fortnight.

Is automation testing better paid than manual testing?

Pay depends on the employer, city and your skills, and no single figure applies. Instead of comparing roles by salary rumours, compare the portfolio each one lets you build.

Can I try more than one role in a single internship?

You can touch more than one, but depth beats breadth in 14 days. Pick a primary role and add one small task from a second, such as an API check in Postman during a manual track.

Which language should I learn for test automation?

Choose the language you already know best. Java with Selenium and TestNG, and Python with pytest, are both widely used. JavaScript suits Playwright and Cypress, particularly if you already do web development.

How do I show a performance testing internship to an interviewer?

Share your workload design, the metrics you tracked and a short finding that links a specific number to a likely cause. Explaining your reasoning matters more than polished graphs.

Will an online internship certificate count for my JNTUK college requirements?

That depends on your college and regulation. Ask your training and placement officer or department head in writing whether outside online internships are accepted and what documents they need.

What should I do if the internship task is vague?

Write down your assumptions, list open questions and proceed with the safest interpretation. This is itself a QA skill, and noting it in your summary shows maturity.

Related Software Testing guides

• Software Testing Internship Interview Questions and Practice Tasks for Osmania University Students
• Software Testing Internship Guide for RGPV Students: Building a Test Documentation Sample Set
• Evaluating Software Testing Internship Offers as a KTU Student: Tasks, Tools and Mentoring
• All Software Testing internship guides