Agile Buddha - Page 17 - Demystifying Agile, Getting to its Core

Developer First Test Automation

Waterfall made a clear demarcation between developers and testers. While moving from waterfall to Agile, both development and testing has to be grinded in a way that you can’t separate from testing activity from development.

People in Agile projects are moving away from “developers vs testers” (we vs they) culture and are collaborating in order to deliver the product at the end of sprint. Sprint success is major goal instead of developer or tester success.

That has been a great change in the recent years and which also means some more miles to go before reaching the state of true collaboration. Even today, quality is considered to be the major responsibility of testers which in reality shouldn’t be the case.

As developer is primarily involved in developing the functionality, (s)he needs to have tremendous commitment in building quality into source code and if bugs come, primary responsibility should be of developers. It doesn’t mean that testers don’t have any responsibility. They need to move away from their traditional role of just finding bugs and instead should be able to focus on creating infrastructure, frameworks for building quality within and also focus on exploratory testing, improving product etc.

In Automation testing, though automation test creation is the responsibility of the testers, developers lay the foundation of creating those test cases.

Sometimes this demarcation doesn’t work in a smooth way. While developing the automation tests, tester discovers many basic foundational pieces missing, which eventually hampers the tester in developing those tests.

In one of the teams I worked with, team came out with a norm which helped the testers a lot.

Developers suggested to write the first functional test of the user-story themselves, which laid the foundation and provided all required resources to build further tests. While developing those tests, developers identified many issues which otherwise would have blocked testers. As developers eventually fix these issues, it made much more sense that they themselves discover those issues.

Based on this basic foundation, testers further elaborate the test cases and create more automation tests. The norm worked pretty well for the team and also helped developers understanding the issues testers face on daily basis.

It’s step ahead towards ATDD. However this team was not using BDD or tools required for ATDD and was not planning to move towards them in near future. Developer-first norm worked quite well for them.

Agile is Genchi-Genbutsu: Go, See and Confirm

by Avienaash Shiralige 4 Comments

Genchi-Genbutsu is the Japanese expression for a practice of finding your answers right down at the source, rather than relying on second-hand reports or charts of data to achieve true understanding. This practice emphasizes going to a place(gemba) where you watch, observe and ask “WHY” five times. I shared few posts earlier on 5 Whys.

Most of the time we are hidden in our project plans and design documents to find root causes. Traditional methods assumed that having a great plan and good documentation is the secret to project success. They alienated themselves from implementation and real world.

Agile, on the other hand, believes in delivering some thing early on to confirm our understanding. It inherits the expression Genchi-Genbutsu.

Dev Box Testing : Reduce Your Bug Life Cycle

by ShriKant Vashishtha 13 Comments

The idea of dev-box testing is simple but very effective. Let’s take an example of a development cycle:

Developer implements the functionality along with unit and integration tests and when she’s satisfied she commits the source code in the source code repository like svn or git.
Continuous Integration (CI) gets triggered by source code commit and CI tool like Jenkins performs the automated build which results in code compilation and execution of the test cases (unit, integration and automated functional tests).
After multiple builds when developer thinks that functionality is ready for functional testing, she asks the tester to take a specific build and test.
Tester starts testing. If tester finds bugs in the functionality, she informs the developer about the problem and developer again begins from step 1.
If everything is good, tester moves the user-story into DONE state.

Working through step 1-3 takes a lot of time and if testers has to move the story again in development, it results in a lot of time-waste and frustration.

How about this?

As developer sees everything working on his machine, he asks tester to test the functionality on his machine. While testing on dev-machine if everything works, only then developer commits the code which eventually triggers the build and auto-deployment. On the committed code available in testing environment tester performs further exploratory tests. Otherwise developer continue to fix the issues on his machine. This way, a lot of valuable time is saved.

Agile Offshore : Business Analyst – Complementing the Role of Product Owner

by ShriKant Vashishtha 2 Comments

Let’s take a scenario.

You have a product owner at distributed location but somehow he is not able to provide sufficient time to distributed team. Because of that team doesn’t get enough understanding of user-story.

Does it sound familiar?

Mostly it’s about PO getting involved in too many other things. That results in not having user-stories READY, analysed or communicated properly.

That brings another question related to suitability of people assigned for PO role. Not everybody is good in analysing and writing good user-stories.
[Read more…] about Agile Offshore : Business Analyst – Complementing the Role of Product Owner

Agile Offshore: Create Effective and Decisive Product Owner Proxy to Offshore Team

by Avienaash Shiralige 6 Comments

Off-shoring in current market is a global economic and strategic need. Building Agile Offshore teams across boundaries and time zones is a different ball game. It has its fair share of challenges to work with. I shared few of those challenges and a possible approach to take in my earlier articles.

1. How to Address People and Communication Challenges
2.Distributed Agile:10 Best Practices of Successful Teams
3. Distributed Scrum: A Day In The Life Of A Distributed Team

You need to make few changes along your way to your normal routine to make it work. One challenge I often see is integration of offshore team with onshore team and to project/business vision.