Agile Testing Days — Day #3: Let's focus on people and on their interactions!

The Day 3 of ATD started with Paul Holland's keynote: The Pothole of Automating Too Much. He talked about some of the benefits of having Test Automation in place, when you also are able to increase the project's risks. Automation can:

• Give to us a decent sanity check of our product
• Execute in less time than a human performing the same checks

He also explored some numbers of a Experience Repor from a large insurance company and some of the conclusions were:

• We should not be paranoid to always have 100% automation
• On this example, 30% of the bugs came from automated tests and 70% from exploratory test sessions
• We need to invest more in vigilant testers (exploratory test skills) to be able to catch problems that automation can not be programmed to recognize

Paul also talked about what he think is a better solution: have a strategic mixed approach.

• Automate critical paths
• Automate paths with the highest use
• Always consider the cost of automation vs. its benefit
• Use humans to show how the software might not work

I had a chance to attend to the LEGO Product Exploration workshop facilitated by Anton Zotin. We worked in teams of 4. My group had people from Germany, Netherlands, Brazil and Singapore. Besides the technical subjects we talked about we also had a chance to learn about our different cultures. It was awesome! :)

Anton didi a warm up session to teach us the foundations of the workshop. Our mission was to build a duck with LEGO peaces. To do this we followed these steps:

• 3 minutes for each member of the team to build a duck. It was done individually, in silence and with no communication between the team members. This allow each member to express your thoughts.
• 1 minute for each person to present your duck and its features. No judgment from other members.
• 3 minutes to the team build a single duck merging the ideas from each one build by the team members.

Using the same 3 steps used to build our duck, the teams were challenged to build a product: a mobile app that helps parents to understand if the diapers of his/her babies need to be changed. These diapers have some sensors and also send the information thought Bluetooth :-P

1. We defined a persona
2. We explored his/her daily problems
3. We listed some features for our application that can help our persona

This exercise was very useful to educate us that we really need to center our focus in the user when building a product.

Debriefing moment. The teams talked about their personas and the features planned for the apps

It's not about superstars, it's about the team

This was the core message I got from Emily Webber's keynote. We must understand that each member on the team can collaborate with something. Each person has a power that help the groups build valuable products. Below you can find more of my notes:

• To build a team's collective intelligence, we should have flow of ideas and social learning.
• Long living team need to make sure that will not be accommodated to self-service. We need to push the teams to challenge their members to learn and experience different things
• We also need to provide a safe environment to allows these experimentations
• We should focus in people. We usually invest more time in planning product's roadmap
• "People need to want to change"
• People need to have an intrinsic motivations. They will not change only because other people say they need to

It’s not about superstars, it’s about the team

To wrap up my day, I attended the Behavior Driven UI Automation talk hosted by Gaspar Nagy.

His work is something similar to the approach we are using in some projects in CESAR. It was so nice to see that we are in the same page of Gaspar practices. He focused in using BDD to fill some gaps, architectural and programing issues we have in automation:

• Unclear purpose
• Anti-semantic locators
• Timing issues
• Code duplication
• Wrong Abstraction

Introduce BDD is something that helps on giving a way to declare more clearly the purpose of a test case. Introduce Page Objects also helps us to structure better the code and allow the reuse of elements. Also add meaning to each locator and use them in the context of the interaction with the page.