[TEST] Move forward, shift left!

Companies following Agile development practices intend to test often and have frequent releases. But sometimes, you can’t: For example, if you are part of a large enterprise with complex web applications using for example service-oriented architecture combined with legacy systems. Another problem is that the majority of testing is usually done once features are completed, after SIT (System Integration Test) and UAT (acceptance test). You can almost never test the quality of a system. Then, the time spending at the end of a cycle testing and bug fixing is going to be bigger than it could have been if you had found and resolved the issues earlier in the Software Lifecycle. Studies shows that it’s a lot more expensive to fix a defect found once it has been released. The shift left concept brings a concret solution. It tells you what can be done to improve overall quality and at the same time accelerate release cycles. The intention is to bring new services to market faster, drive growth and/or maintain competitive edge. The goal of this methodology is to shift as much of the testing prior to release (to the left, during construction) and catch errors earlier in the software development lifecycle. To achieve this:

• Create automated and continuous test through all quality stages
• Have a single version of the truth for the quality of your deliverable
• Create and run automation as a part of the development process
• Ensure governance of your testing end to end.

[User stories] Size does matter…

As a professional working in an agile environment you should be familiar with estimations of the effort needed to complete user stories.  Commonly referred to as "story points these effort can be estimated effortlessly if you relax and use well known techniques. Remember that the founder of scrum mean that story points are meaningless. Their real value is a relative value, compared to other user stories.

The team members must feel confident about the process, about their colleague and speak up! 


“The biggest risk is not taking any risk... In a world that changing really quickly, the only strategy that is guaranteed to fail is not taking risks.” Mark Zuckerberg

To start, you and your team need to determine a satisfactory measure of complexity and size. Example: Very low, Low, Medium, High or you could use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, …) or even T-shirt size (xs,s,m,l,xl).

Techniques:

Triangulation: Even when you know nothing you know something. You can compare, use experience, similar stories and reach an estimate.

Fist of five: The story gets estimated then everybody vote on that estimate (number from 1-5). Strongly disagree = 1, strongly agree = 5. The team members who voted 1 or 2 should explain before a re-vote. You stop the process only when everybody's vote is like or above 3.

Polling (planning poker): Each team member writes down (or holds up a card) what they think the story will take independently. The highest and lowest estimates should give explanation to the team. May be something new will be revealed. The the team can adjust and vote again and reach a consensus.

To conclude, we are only humans. Studies show that developers have a hard time estimating for others than themselves. What if the task is to be done by someone else, and what if there are a lot of ad-hoc tasks during this very sprint. Different people have different ways to manage their time and consider risks...so in reality the team member with the largest estimate might be right…If you have to choose, take the largest estimate!