The document provides details about the automation testing framework and process used for an ecommerce application. It describes the team structure, sprint timeline, automation test pack details, and the Cucumber BDD framework used for automation. Key points include: - The team consists of testers, developers, a scrum master, and business analyst. - Sprints are 2 weeks with testing in the second week. Retrospectives are held at the end. - The automation test pack includes over 1200 UI and 400 API tests executed daily. - Cucumber is used with Page Object Model. Tests are written in Gherkin and executed via Maven. - Logs, reports and configuration are handled through Extent Reports,

1. Change History:

2. Current Team Structure
Testing:
1. 1 Functional Tester.
2. 3 Automation TestersDevelopment:
4 Java
Developers to
develop your
Application.
Scrum Master: Person
accountable for seam-
less Sprint delivery.
Business Analyst:
(BA)
Business Expert.
Responsible for
writing user stories in
accordance to Product
Owner or Client.

3. Project Time-Line
S-0 (2Y
back)
S-1 S-2
Many
sprints..
S-48
(Today)
•Ecommerce Domain Project.
•Java based UI application.
•Project is running since 2 Years.
•Delivered all the major functionalities.
•Current Sprint is Sprint 48.
•2 week sprint Cycle.
•Still lot of features to be delivered as ecommerce domain is a very dynamic domain and
changes are driven by customer demand and feedbacks. Like addition of new Products,
improving intuitiveness of the App, promotion of specific products, etc

4. Sprint Time Line
Sprint Start-
Day 1
• 2 week sprint Start
• Scrum Master, BA, Product Owner will refine and finalise the stories.
• Refinement sessions for User stories to be delivered in the sprint.
• User stories will be estimated and poker planned.
• Tasks for Testers and Automation testers will also be determined and estimated.
• All the tasks and User stories will be tracked and Logged in the JIRA.
Sprint Mid-
Day 5
• During the First Week:
• Developer: Will deliver the coded functionality of the User stories assigned to him. He will also write Unit Tests.
• He will deploy features in “Development environment” on the daily basis.
• Functional Tester: Will study the user stories for current sprint and write the Manual test cases. Usually 30 to 50 test
cases per sprint.
• Automation Tester: Will Automate the test cases created by functional tester in pervious sprints. He will do, will to
maintenance work, i.e. fixing scripts which are failing.
Sprint End-
Day 10
• Last week of the Sprint, is dedicated towards SIT (i.e. System Integration Testing) and Regression Testing.
• Developer would work towards, fixing any defects raised by testers, for New User Stories or Regression defects.
• Manual Testers and BA: Both of them will go and test the application manually. BA usually, go and check that the FUser
stories are correctly implemented.(SIT) Manual Tester, does the comprehensive testing(SIT + Regression), i.e. new User
Stories test cases which he has written in the previous week. He also does regression test cases execution, if they are not
automated. In few cases, if manual regression test case execution is not possible, exploratory testing is also done by
Manual tester and Business Analysts.
• Automation Testers: Since this week, is all about testing, primary goal of automation testers is to execute automation pack
on daily basis. This is called as Automated Regression Test Pack. If project has Jenkins integration, then this pack is
configured with Jenkins to execute every time there is a deployment on Test Environment URL. If jenkins integration is not
there, then this pack is executed manually on “Virtual Machines”. (not on local machine
• Automation Tester will might also pick priority test cases from Current Sprint from SIT test case list as well for automation.
• While testing manual testers, BA or Automation tester might find defects. These defects will then be raised in Jira and
developer will fix them during this week.

5. Sprint Time Line
Sprint End-Last
Day activities
• When is Sprint testing completed?
• Testing is completed:
• When all the SIT Test cases are executed.
• All the regression test which are not yet automated are manually executed
• Exploratory testing is completed, in case all the regression manual test cases
execution is not possible.
• Regression automation pack execution is completed.
• All the defects are fixed and re-tested by testing team.
• Retrospective: Idea is to simply sit together and take feedback from each other on
“what was good”, “what went wrong” and “what should be continue to do”. Every one
writes these things down, either on JIRA or simply on white board and then people
discuss these and create action items, if any, can be written down.
• For example: I can write in a “Good section”: It was good that we did not change the
scope of User stories in Mid Sprint. Even after our client instead that we should. We
pushed it back saying this is against agile-scrum and there is risk of spill over. We
should continue to do it.
• In “What went wrong”: Estimation of one of the story was not correct. Our
understanding of the requirement was not full due to which we gave less
estimation. This lead to un-necessary strain on the team. From next time we need
to be more extensive in understanding the requirement. May be BA need to be
more elaborate on the User stories he is creating.
• 2nd example can be: We are reviewing the Automation Code, this could lead to
issues in automation test quality. We need a proper review check list and review
process before new test cases can be added in to the final regression pack/
• In “Continue to Do”: Defects were fixed on time. Also, automation pack did not
have much script related failures. This means our automation test pack is effective
in catching defects. We should continue to do this.

6. About Automation Test Pack
Current Count?
•Total UI test cases: 1200
•Total API Test Cases: 400
•Test Pack execution Time: 5 hours for UI and 40 min’s for API test pack.
When do you execute the pack?
•We have two automation suites.
•Health check: Executed every time we have code deployment on test environment URL.
•Regression pack: Executes End of the Day.
•If UI health check fails, High severity defect is raised to fix it because it blocks the execution. Developer has to
immediately fix the issue and re-deploy the code.
•Regression execution results is analyzed to look for any possible defects.
Automation Test Pack Failures?
•Test case fails due to three main reasons:
•Failure because functionality is changed. For example, there was a specific category of products previously, for
which you had test cases, now the product category is no longer available.
•Failure due to script was not properly written. For example, script sometimes work but fails due to sync issues. Or
test data is hard coded. Like trying to add a product in to basket which is not present anymore. This is called as
Hard coding of data. Such scripts, if not properly reviewed get their way in the main test pack and then its starts
failing. So such script has to be identified and either fixed or removed.
•Failures due to actual bug. This fails when you have actual live system defect.
•Usually fail rate of 3-5 percent is acceptable. But if it exceeding more than that then we have a problem.

7. About Automation Test Pack-Cont..
Who writes the test case?
• We are using Cucumber Framework.
• BA writes the requirement in Given when then style in Jira.
• Manual testers/ Automation tester reads these Jira tickets and then we write our own
automation feature file and scenarios in Given when then format for our framework and
then we write our step defs to automate them.
Where are you maintaining your test code?
• Our development technology is java and our test automation technology is also Java.
• We have a separate Git Hub repository, other than developer, where we maintain our test
code. Our tests are integration tests and there fore they are not executed as part of Dev
java code build process. With dev code build process, Unit tests are being executed.
• We have robust code review process. For each new test cases/User story Jira ticket, we
create a branch. Test scripts/ step defs are created under this branch. Once the
development work is completed, test cases are run from this branch and quality of the
scripts are proven.
• Then the Automation Tester creates the Pull request also called as PR, to merge this change
in to the master branch. This PR is assigned to peers and leads. Once every one approves
and all the reviews are done, then lead will merge the pull request in the master branch.
This master branch test code get executed on the daily basis.

8. About Automation Test Pack-Cont..
Where do you run your execution test code?
• We have Four environments:
• Dev Env: During the first week of the sprint, this environment is used by developers.
All the dev work happens here
• Test Env: After the first week, application code is deployed on Test environment URL.
All the SIT and regression testing, exploratory testing, Automation test execution
happens here.
• Performance Env: This is a separate env to test the performance of the application.
This environment mirrors the actual production environment. Performance tests are
written using Jmeter and they are outside the purview of the sprint testing.
• UAT Env: After the end of sprint, code is deployed to UAT env, where Client and their
business team does the testing. This is again outside the purview of sprints cycle.
• Project is released every three week. i.e. 2 week Sprint cycle-Dev + testing. After
sprint is completed, Dev and test team starts working on the next sprint. But the
code is then moved to UAT and Perf Env for further testing. This takes another week
and then, new version is deployed to the Production environment.

9. Automation Framework
Driver/Test
Cases
•We are using Cucumber Framework.
•We use Maven sure fire or maven fail safe plug-in to execute the test pack. Explained under
Config and exec section.
•Maven profiles is used to configure and execution.
•Test case can also be executed via directly executing the Junit Runner file.
•Test cases are written in feature file format and their associated steps are kept under step
defs.
•We use Jenkins to execute our test pack on remote machines. We have scheduled our
Jenkins job to execute the pack every day at 7 PM.
•Our Integration test pack is not park of Continuous Integration yet. We are trying to move
in that direction however.
Locators
•Using Page object model, to store objects.
•Created Page Factory class files with locators and their corresponding Setter methods.
•Also, created Business keyword methods as a Wrapper on top of these locators setters. For
example, for a login page, we have 3 locators defined at the top , then we have 2 set
methods for username and password and one click method of Submit Button. But then we
have an additional Wrapper method which we call Business Keyword called as
“LoginToApp” which does the login. This makes the code concise and clean.
•We have kept common locators, locators which appear on all the pages , like Menu etc, in
separate Page Object file so as to avoid having to add these locators in multiple files.

10. Automation Framework
Logs and
Reporting
•We are using, Extent report adapter for High level reporting.
•Extent report offers a library which once we mention under the plugin section of cucumber
options, would start logging the scenario step logs in HTML format.
•This gives us good enough reporting.
•For logging specific text in the report, we use Scenario Interface of Cucumber.
•This Interface is injected at run in the @Before Hook of Cucumber.
•The Same Scenario object we use to embed Screen shots of the application, when
something fails.
•For low level logs we are using log4j2.
Config and
execution
•Configuration files are created to keep config information like, URLs, Username,
passwords, product information etc.
•We use these config files to keep static information.
•We use maven profiles to manage the dynamic config at run time. For example, which
browser to run against, which env (dev, test,uat) to run the pack against can be sent from
Maven command like like below:
•=>mvn clean install –P env_test –Dbrowser=chrome [this command will execute, pack on
test env with chrome browser
•=>mvn clean install –P env_dev –Dbrowser=firefox [this command will execute the pack on
dev env and will use firefox]
•In above commands, _P indicates profile, env_test is a maven profile created in your
POM.xml file and browser is a system property

11. Automation Framework
Other FW
Features
•Reusable libraries like:
•Browser Manager
•DB Manager
•Excel Manager etc to handle Excel, DB and Browser Operations.
•Parallel execution is implemented by maven sure fire plugin. We execute 5 test
cases in parallel for faster results.
•Jenkins job to run the pack on virtual machine and agents.
•We use tags to control to the execution flow, in the sense what needs ton be
executed etc. Tags like, @smoke, @regression @search_module @end2end etc
are the tags which we use.