Barkatullah University Students: Using Cucumber and BDD in a Short Testing Internship

Yes, Cucumber and BDD fit a two-week testing internship well, provided you keep the scope tiny: one application, three to five features, and scenarios written in plain business language before any automation code. The goal is not to master the tool but to produce a small, reviewable project that shows you can describe behaviour clearly and turn it into executable checks.

This guide gives a 14-day plan, a minimal feature-file project, Gherkin writing rules, a scenario quality checklist you can score yourself against, and notes for Barkatullah University students on how to document the work for your department.

What BDD and Cucumber actually give a beginner tester

Behaviour-driven development (BDD) is a way of agreeing on how software should behave by writing examples in plain language. Cucumber is a tool that reads those examples, written in a format called Gherkin, and links each line to code that performs the step. Gherkin files have the extension .feature.

For a student, the value is practical:

• You practise turning vague requirements into concrete, checkable examples, which is the core skill of test design.
• Your work is readable by non-programmers, so a mentor or faculty member can review it without reading code.
• You get a small automation portfolio piece that shows both thinking (scenarios) and implementation (step definitions).

What BDD is not: it is not a replacement for exploratory testing, and Cucumber does not make poor tests good. A badly written scenario is simply a badly written test with nicer formatting.

Choosing a small system under test

Pick something public, stable and simple so that your effort goes into scenarios rather than fighting the application. Good options for a beginner:

• A practice login and registration site built for testers.
• A demo shopping cart or to-do application.
• A small calculator or string utility you write yourself in Java or Python, which needs no browser at all.

The last option is underrated. If browser setup eats three days, you learn little about BDD. A tiny function with clear rules lets you focus on Gherkin quality first, and you can add a UI feature later if time allows.

Gherkin guidelines for writing scenarios that survive review

Gherkin has a small vocabulary: Feature, Scenario, Given, When, Then, And, But, Background, Scenario Outline and Examples. The grammar is easy; the discipline is hard. Use these guidelines.

1. One scenario, one behaviour. If the title needs the word “and”, split it.
2. Write in the user’s language. Say “the customer sees an error about the password”, not “the div with id err2 is visible”.
3. Given sets up state, When performs one action, Then checks an observable outcome. Avoid placing an action after a Then.
4. Keep steps declarative. “When the customer signs in with a valid account” beats five lines of typing into fields.
5. Use concrete example data only when it matters. Otherwise describe the type of data (“a registered email”) and keep the values in step code or an Examples table.
6. Keep scenarios short. Aim for three to seven steps.
7. Make scenarios independent. No scenario should rely on another having run first.
8. Name scenarios as outcomes. “Locked account cannot sign in” is clearer than “Test login 3”.
9. Use Background sparingly. Only for setup that truly applies to every scenario in the file.
10. Use Scenario Outline for the same rule with different data, not for different behaviours.

A minimal BDD project layout you can finish in two weeks

The structure below assumes Java with Maven, which is the most common Cucumber setup, but Python (behave) or JavaScript work on the same principles. Check the current Cucumber documentation for exact dependency versions rather than copying old blog snippets.

bdd-testing-project/
  pom.xml
  src/test/resources/features/
    login.feature
    cart.feature
    search.feature
  src/test/java/
    steps/
      LoginSteps.java
      CartSteps.java
    runner/
      TestRunner.java
  README.md

Keep one feature file per business capability, one step-definition class per feature, and a README that explains how to run everything in three commands or fewer. A reviewer who cannot run your project in five minutes will judge it on the README alone.

Worked illustration: from a requirement to a clean feature file

This example is illustrative. It shows the thinking process and has not been executed against any real application.

Requirement (informal): “Users can sign in with email and password. After three wrong attempts the account is locked.”

First draft (weak):

Scenario: Test login
  Given I open the browser
  And I go to http://example.test/login
  When I type "a@b.com" in the email box
  And I type "wrong" in the password box
  And I click the button
  Then I see an error
  When I type "wrong" in the password box
  And I click the button
  Then I see an error
  And the account is locked

Problems: it mixes two behaviours, the title says nothing, it is tied to interface details, it hard-codes a URL, and it has two When/Then cycles.

Revised version:

Feature: Customer sign-in
  Customers sign in with an email and password.
  Repeated failures lock the account.

  Scenario: Registered customer signs in with correct details
    Given a registered customer
    When the customer signs in with the correct password
    Then the customer reaches their account page

  Scenario: Wrong password is rejected with a clear message
    Given a registered customer
    When the customer signs in with an incorrect password
    Then the customer sees a message that the details are incorrect
    And the customer remains signed out

  Scenario: Account locks after three failed attempts
    Given a registered customer who has failed to sign in twice
    When the customer signs in with an incorrect password again
    Then the customer sees a message that the account is locked
    And signing in with the correct password is also refused

Notice what changed. Each scenario has one trigger and one outcome. The third scenario uses Given to set the state “failed twice” instead of replaying the whole story. Nothing mentions page elements, so the interface can change without rewriting the file.

Next, a Scenario Outline can cover input rules:

  Scenario Outline: Invalid email formats are rejected
    Given the sign-in page is open
    When the customer enters the email "<email>"
    Then the customer sees the message "<message>"

    Examples:
      | email        | message                    |
      | plainaddress | Enter a valid email address |
      | a@           | Enter a valid email address |
      | @b.com       | Enter a valid email address |

The message text here is invented for illustration; in a real project you would copy the wording from the application or the requirement.

A 14-day plan for a Cucumber BDD internship

The plan assumes roughly two to three hours a day. Adjust it if your exams or lab schedule leave less time, and cut features rather than quality.

If you are looking for a structured place to do this, the free two-week online internship from CareerSwami offers a software testing track, and a 14-day plan like this one can be used to organise that work.

Scenario quality checklist with a scoring scale

Review every scenario against these criteria. Give one point for each “yes”. A scenario scoring below 7 out of 10 should be rewritten before you write any step code.

Feature-level checks

• Is there a short description under the Feature line explaining who benefits and why?
• Do the scenarios include at least one failure or negative path, not only the happy path?
• Are boundary values covered (for example, exactly three failed attempts, not only two and ten)?
• Are tags meaningful and limited to a few?
• Does the feature file still make sense if you delete all the step code?

Common step-definition problems in beginner Cucumber projects

• Near-duplicate steps. “the user logs in” and “the customer signs in” create two code methods for one idea. Pick one phrase.
• Assertions hidden in When steps. Checks belong in Then steps so failures point to the right line.
• Shared mutable state. Variables stored statically make scenarios depend on each other. Use Cucumber’s dependency injection or a per-scenario context object.
• Fixed sleeps. Replace Thread.sleep with explicit waits when testing a browser.
• Regex that is too clever. Prefer Cucumber Expressions such as {string} and {int} for readability.

Barkatullah University students: documenting a BDD internship for your department

Barkatullah University is a state university in Bhopal. Its About page describes it as offering courses through affiliated colleges and its own University Teaching Departments, so your internship paperwork may depend on whether you study in a teaching department or an affiliated college. The Department of Computer Science and Applications lists subjects such as Java, DBMS, Oracle and Computer Networks, which are directly useful when writing step definitions or setting up test data.

On the rules side, the university publishes its Act, Statute and Ordinance on an official Google Sites page, which is where formal regulations sit. Its notices list also includes titles such as “Notification for Campus Internship” and “Notification For Project and internship marks entry”; the contents are not visible in the list, so read the full notices yourself. The 2020-21 AQAR mentions that internship viva-voce is part of assessment, which is a 2021 statement, so check the current version. A viva is easier if your repository, scenarios and report are tidy.

Whether an online internship is accepted for any academic requirement is not established here. Treat this internship as skill-building unless your department confirms otherwise in writing.

Verification steps before you rely on this internship for college requirements

1. Open the “Campus Internship” and “Project and internship marks entry” notices on the university notices page and note the deadlines, formats and who signs.
2. Read the internship or project-work clause in the current Ordinance PDF for your programme and admission year.
3. Email your head of department or internship coordinator asking: “Is an online internship accepted, and what documents are required?” Keep the reply.
4. Ask whether rules are set by the university or by your affiliated college, if you are not in a teaching department.
5. Check with the Training and Placement Cell, using the contact on its official notices, whether they want internship evidence for drives.
6. Confirm viva format and what to bring: certificate, report, repository link or printout.

Packaging the project for a viva or interview

Prepare a short package that stands on its own:

• A repository or zip with the layout shown earlier and a README.
• A one-page scope note: what you tested, what you left out, and why.
• The scorecard from the checklist, showing scenarios you rewrote and what you learned.
• A Cucumber report screenshot or file from a real run you performed yourself.
• A short list of genuine defects or observations, if you found any. Never invent bugs.

Questions to rehearse: Why Given/When/Then rather than a test-case table? When is Scenario Outline the wrong choice? How would you stop UI changes from breaking your steps? What does a failing scenario tell you versus a failing unit test?

Frequently Asked Questions

Do I need to know Java before starting a Cucumber project?

Not deeply. Basic syntax, classes and methods are enough for step definitions. If you are weaker in Java, start with feature files for the first week and keep code simple. Cucumber also supports Python, JavaScript and other languages.

How many feature files are enough for 14 days?

Three well-reviewed features with eight to fifteen scenarios in total beat ten rushed ones. Reviewers value clarity and coverage of failure paths over volume.

Should I automate the browser or test a simple function?

Either works. A function or API keeps setup light and lets you concentrate on scenario quality. Add a browser feature only if you finish the plan early.

What is the difference between Scenario and Scenario Outline?

A Scenario is a single example. A Scenario Outline runs the same steps against several rows of data in an Examples table. Use it when the behaviour is identical and only inputs and expected values change.

Can I use this internship project for my university internship requirement?

That depends on your programme’s rules, which you need to confirm in writing with your department and in the current Ordinance. Nothing here confirms that an online internship is accepted for academic purposes.

Is Background a good place to log in?

Only if every scenario in the file starts from a signed-in state. Otherwise put the sign-in in a Given step, so each scenario states its own preconditions.

How do I show that my scenarios are good quality?

Keep your scorecard. Showing the original draft, the checklist score and the rewritten version demonstrates review skill, which interviewers and examiners often value more than the final file alone.

Why do my scenarios pass but still miss bugs?

Passing scenarios only prove the examples you wrote. Add boundary values, invalid inputs and error states, and supplement them with exploratory testing sessions.

Related Software Testing guides

• ARKA Jain University Students: Daily Routine of a Testing Intern, Hour by Hour
• Monark University Students: Testing an E-Commerce Site as an Internship Practice Project
• Dev Bhoomi Uttarakhand University Students: Git Basics Every Testing Intern Needs
• All Software Testing internship guides