Agile Testing – Moving out of the Comfort Zone

•March 6, 2018 • Leave a Comment

Hurricane Mike: Urciuoli Storms JPMorgan Asset & Wealth Management” is a great read on what it takes to change the culture of a large organisation.

Resistance is expected on such a path.

Solution – fly the “entire management team” to the West Coast, so that management grasped the concept and benefits of agile, “automated testing and unit test code coverage, rather than relying on feedback from groups of manual users.”

Game Changer 🙂

Centre of Expertise Software Development: Shift Left

•January 25, 2018 • Leave a Comment

Looks like ABN AMRO is embracing software quality 🙂

Introduction:Happy flow programming is easy, taking into account everything that can go wrong is difficult. There are many theories on how to properly take into account non-functional requirements such as maintainability, reliability in early stages of the software development life cycle. Shift left testing is an approach to software testing and system testing in which testing is performed earlier in the lifecycle (i.e., moved left on the project timeline). It is the first half of the maxim “Test early and often.“ Why is it that transferring these theories into practice is so hard? What is it that more often than not a software engineer does not tackle what can go wrong earlier in the process? Problem:ABN AMRO has a long history in software development and certain processes and procedures have become habits. For instance validating quality at a very late stage, by having the bulk of tests in the acceptance environment. Although most stakeholders are aware of this and see the need to move a lot of this work to the development and test phases, the pace of adoption and practical implementations is still too low. Research questions:The main problem is the adoption of proper testing at development time. As a result, the main research question is:What are the best practices for shifting as many tests as possible to the development phase? Other underlying research questions might be:

How can the quality of Unit Tests be validated and improved?
How can performance tests be implemented in the development or test phase?
How can availability tests be implemented in the development or test phase?”

Actionable Metrics

•January 12, 2018 • Leave a Comment

I’ve always been a fan of KanbanActionable Agile provide an interesting read on how actionable flow metrics (Work In Progress, Cycle Time, Throughput) are used to reduced Cycle Times, which leads to faster delivery of business value stories to the end users 🙂

Finally,  “no more estimation” (story points) using instead predictability 🙂

Testing and Metrics

•January 11, 2018 • Leave a Comment

Executive Summary: testing provides confidence that requirements have been implemented (acceptance criteria/tests) prior to delivery into production, metrics provide a steer on confidence that the product/service/application is delivering as per the objectives, in production.

 

Writing code has become easier in recent years with the improvements in IDE’s, build and deploy chain tooling, GitHub and tutorials and samples available on the web. In many cases it is possible to find code lying around the web which may solves part of the problem you are attempting to code. That said, writing good code is an art. Code that is well structured, tested, and that delivers a solution to the problem statement is continues to be a high bar.

 

Testing is, and will continue to be, a debated topic, with multiple divergent approaches being common, for example:

  • Unit vs integration vs end to end
  • Code then test, Test Drive Development (TDD), Behaviour Driven Development (BDD), or other.

 

Any testing is better than no testing; and in most cases, an individual’s viewpoint on testing is strongly influenced by their notion of what makes a quality product, and how quality is measured. Improving upon a viewpoint, however well informed, requires articulated hypothesis and data points of validation found in collected metrics.

 

AWS’s recent blog posting on the roulette wheel reminds us of how a data-driven culture is driving productivity and innovation at Amazon. Amazon has embraced metrics in defining objectives, and ensuring that products, services and processes meet expectation and can be optimised without reliance on “point of view”. Testing, backed by metrics, provides confidence that the delivered service will meet the expected criteria.

 

We can think of metrics and testing as providing a solid basis for confidence in application code as it progresses through the Software Development Life Cycle (SDLC), indeed, in the case of Amazon, Metrics Driven Development (MDD) are at the core of the SDLC. Metrics that validate the Definition of Done (of a story), not only validate software during test but provide real-time data-driven evidence of performance to specification in production.

 

Returning to testing: software engineers who prefer not to follow the agile path of acceptance criteria/tests, as a required part of a story, risk failing to codify the story in a way that evidences how the requirement has been satisfied.

Mocking with Data in a GDPR World

•January 3, 2018 • Leave a Comment

General Data Protection Regulation (GDPR) is going to impact a lot of software.  Not least test data.  A few articles provides some guidance on this particular thorny subject:

  • How GDPR Impacts Test Data Management
  • Test data management and reactive automation
  • Test data management: the hidden GDPR challenge
  • How To Create Your GDPR Compliant Test Data Management Strategy

AI Driven Retrospectives

•December 3, 2017 • Leave a Comment

With the drive of AI and chatbot recently, its of no surprise to find ScrumBot.  What I think would however be more interesting is to hook the bot into a wider array of data outside of the Slack/Hipchat/Microsoft Teams world, maybe levering product metrics, as well as SDLC metrics.  Standuply appears to hint at this via the third party metrics integration.  I suspect if the bot could leverage a appropriate metrics, its would be powerful not only from a retrospective, but also from a pair engineering experience as well

Agile influences Behavior Change

•November 15, 2017 • Leave a Comment

There is often debate around what Extreme Programming (XP) / agile practices work, and what doesn’t – hotly debate are often pair programming and test-driven development.  What is often missed is that agile has an underpinning, which is the drive for behaviour changes to deliver improvements (quality) in the deliver of software.  This may seem obvious, but its worth calling out explicitly – Connection and here.

Whichever agile techniques you find that work for you and the team, just remember, the need for behaviour change is an ongoing process to drive quality improvements, its not that adoption of any particular agile technique itself will improve quality.