This document discusses testing in Agile environments using Scrum and Kanban methodologies. It describes a project using Scrum with a 10 person team developing a web application using Java, JavaScript, Jira, GitHub, and virtual environments like Vagrant and Docker. It outlines roles, artifacts, and ceremonies in Scrum like user stories, backlogs, sprints, and stand-ups. It also discusses issues with virtual environments and benefits of limiting work in progress using Kanban. The conclusion emphasizes the importance of communication, visibility and flexibility in Agile approaches to software development and testing.

1. Testing in Agile. From Scrum to
Kanban. Virtual development
environments possible issues on
the live projects
Prepared by Vladimir Sidorenko

2.  Type: WEB
 Methodology: Scrum
 Team: DA 10 people
 Tools:
• Jira;
• GitHub;
• Vagrant+Docker+Virtual Box
 Languages:
• Java;
• JavaScript(Angular)
Project inputs:

3. Roles and Activities

4. Artifacts
Term Definition
User Stories Something a user wants and associated acceptance criteria.
For example, “As a Facebook user, I need an ability to retrieve
a link to someone's else entry so that I can share it via other
social networks or send by mail to my friends”
Epics A collection of User Stories
Backlog A list of requirements for a Product or Sprint

5. Activities and ceremonies
Term Definition
Sprints (Iterations) Time-boxed effort to create a “Done” product Increment
Sprint Planning Time-boxed effort to plan the Sprint by the Scrum team
Grooming “Quick” sprint pre-planning , where the whole team required
Daily Stand-ups Time-boxed effort to share the status, usually takes 10
minutes
Sprint Retrospective Time-boxed review of the Scrum Team’s performance during
the last Sprint in order to improve in the next Sprint

6. Scrum Board
ToDo In Dev Dev
Review
Ready
For Test
In Test Test
Review
Ready
For
Merge
Do not
merge(
On
Hold)
Done
Ticket 6 Ticket 3 Ticket 2 Ticket 1 Ticket N
Ticket 5 Ticket N
Ticket 4

7. QA Engineer role and testing process
1. Communication and kick-offs. Define the requirements of the ticket
before it goes to In Development. You need to understand what actually
stakeholders want.
2. Outputs from kick-off need to be put to Acceptance criteria of the story
ACs to written in Gherkin language. Example:
Scenario 1– login page
Given user is on the Login Page
When user fills in the correct credentials in the input fields
And clicks on Submit button
Then he is redirected to the home page
Why should we use this approach? For the ease of writing acceptance automated
tests.
3. Branch testing.
Types used: Exploratory + Regression tests.
To deliver: evidences + results
If story bug – back in Dev. If new one – create another ticket

8. 4 . Writing tests:
smoke checklists;
automated scripts
5. Improvement ideas.
6. Unit and back-end acceptance tests
Development process issues
• New tickets to the current and planned sprint
• Huge change requests
• Change requests after the kick-offs (time!)
As a result – wrong estimates, sprint pumping, angry team
members)

9. Moving to Kanban
• WIP limit!
• Less ceremonies. Kick-off and stand-up is a must
• No iterations
Quick Status Filters:
In Dev(2), Dev Review, Ready To Test, In Test, In Test Review(1), Ready To
Merge
ToDo DEV max 3 TEST max 2 ACCEPT max 4 Done
Ticket 6 Ticket 3 Ticket 2 Ticket 1
Ticket 5 Ticket 7
Ticket 4

10. Quick Status Filters:
In Dev(2), Dev Review(1), Ready To Test, In Test, In Test Review(1), Ready To
Merge
ToDo DEV max 3 TEST max 2 ACCEPT max 4 Done
Ticket 6 Ticket 3 Ticket 11 Ticket 2 Ticket 1
Ticket 5 Ticket 7 Ticket 12
Ticket 4 Ticket 8 Ticket 3
PROFIT!

11. Virtual environments
Vagrant – virtual machine manager which allows you to script the virtual
machine configuration. Works in combination with Virtual Box
Compatible OS: Mac, Windows, Linux
Official site states:
Run a single command — "vagrant up" — and sit back as Vagrant puts
together your complete development environment. Say goodbye to the
"works on my machine" excuse as Vagrant creates identical development
environments for everyone on your team.
Actual:
• Installation problems(path, etc)
• VB version compatibility!
• Resources consumption
• Sudden issues on different environments

12. Docker is a tool for building and deploying applications by packaging
them into lightweight containers. A container can hold pretty much any
software component along with its dependencies (executables, libraries,
configuration files etc.), and execute it in a guaranteed and repeatable
runtime environment.
• Used by testers
• Different containers: frontend,
backend and db
• VPN issues
• Jenkins creds

13. Conclusions
• It’s not all about scrum. You may even mix best methodology practices;
• Agile - process visibility, communication and team play;
• Agile tester should have more responsibility and abilities to improve
the product
• Configurable vm managing software is not always a thing you can
treat easily and without time consuming work
• You have to learn, learn and of course to learn always!

14. Thank you for attention!
Here should be funny picture…But No.)