Today we are developing software very differently than even ten years ago. The Waterfall days are pretty much gone to let Agile take over, but have you wondered if this is the correct choice? Are we betting on the winning horse?
Probably if you take a breath and step back for a moment to see the whole picture, the real question should be, is this methodology enhancing the quality of the product?
Leandro Melendez (Sr Performo) explains this agile phenomenon in a practical way by providing some good and bad practices that could cause controversy in the software industry. At first glance, most of the software companies want to be trendy and seen implementing agile, usually with minimal adaptations, thinking that this nostrum elixir eventually fixes any team’s bad practices. Leandro points out that the magical potion of agile requires a shift in mentality:
1. Let go of harmful habits and customs
We should embrace the evolution of methodology and keep only the habits and customs that provide value. Otherwise, some bad practices could collide with new ones. Don’t be afraid to change the process; be afraid of trying to preserve legacy habits that could make the process to fail. Prepare your mindset to let go of everything that could prevent you from reaching the goal.
2. Agile does not mean cheaper or faster.
When adopting the Agile model, we must invest to cover initial costs. However, this investment pays off by producing software which is more adaptable to your customer’s requirements and changes within your business, and this adaptability could help you deliver higher levels of satisfaction or revenue.
3. Don’t just test at the end of the cycle
Testing right before release is a pretty common mistake. QA teams should be involved at every stage because their knowledge is valuable. Through shifting left QA duties, the quality of the product will improve because they are participating in the requirements gathering or even in interviews with the customer, which creates a stronger shared understanding of the correct behaviour of the application.
4. No tool can replace the skills of your team
This misconception could be related to investing in a tool that promises to reduce your company’s requirements, which in turn should reduce engineering effort, or thinking that skilled engineers without the right tools could be effective at their job. The right tools can be composed together to create a nearly infinite number of results.
There should be a balance between tooling, skills and the interconnection between them to get results.
5. The Automation Cult
Automation is more than just functional UI testing. It should include the full gamut of testing across your application stack. Including unit tests, functional tests, and performance tests.
The coverage provides better visibility into how the application will behave in the hands of your customers. The critical item here is that we usually care about the top of the Automation pyramid, but this is the most expensive spot, we should start to think about pushing efforts at the bottom of the pyramid where fixes are faster and cheaper by increasing the use of unit testing.
In line with the cult of Automation, by promoting the multi-layer approach, we don’t need to wait until the application is ready, stable or released to start testing, because we have been developing scripts to test each layer separately. This approach reduces dependencies between testing teams and cuts out the time in which testers you are blocked on other teams for delivery. This, in turn, can help you to deliver a higher quality product in less time, and ultimately with less rework from defects which you might find once your application is in the hands of your customers.
Leandro has shared with us five key practices that might lead us in the right direction to improve the quality by changing the way we introduce testing and changing the balance and use of tests across our application.
Don’t expect your application ever be 100% defect-free, instead try to catch defects sooner by combining many different tools and practices across your engineering and QA teams. This, in turn, can decrease isolation between teams and promote skill-sharing, which leads to a higher quality product that your customers will enjoy using.