Very often we work on a code-base that has been written by others, and some time ago. This code-base could be for the product code, or Test Automation code. 

As the product life increases, evolution of the code-base is a natural process. However, there are various catalysts to speed up this evolution process:

• More features / tests to be added, including increased complexity
• People writing the code evolve - their learning, skillset
• Delivery pressure means it is quite possible that correct decisions for implementation may not be taken. In other words, it is possible that short-cuts were taken in the implementation leading to spaghetti code / architecture

People move on to different roles, new people join the team. Each has different opinions, perspectives and experiences.

Am sure there are more reasons you can think of.

Regardless, the challenge for a new person who starts working on such a complex code-base is enormous - as the person needs to start delivering "value".

In this session, I will share various examples and experiences and as a result of being in such situations, the factors I looked at when enhancing the code-base to decide - should I refactor or rewrite the code-under-consideration to be able to move forward faster, while moving towards the long-term vision.

Though I will focus on various examples of Test Automation, this session is applicable for any role that writes / maintains code of any nature.

Sprint retrospectives were designed to make the process of software development empirical. An approach where you can make mistakes but also reflect and learn from those mistakes.

They possibly are the ‘A’ in the Deming’s Wheel (Plan-Do-Check-Adjust) that served as the origin of iterative development methods. Unfortunately, that is not how modern retrospectives work. They are rife with boredom, failure to admit mistakes, and lack of follow up if somehow two or three action items were identified.

My interest in organizational behaviour and keen research links each of these problems to a cognitive bias.

In this talk, I will list all of the biases that make retrospectives ineffective and ways in which we can mitigate them.

For example, Recency bias is the tendency to focus on the most recent time period instead of the entire time period. Having retrospectives at the end of a sprint or maybe once a month makes people forget most of the problems they faced or the mistakes they made early in the sprint.

But how do we fix this?

Radical idea but how about a custom field called “Lessons learned” on every ticket you work on. Everybody keeps filling their observations per ticket during the sprint instead of waiting for the final retrospective.

We can call them micro-retrospectives spread across the entire cycle that can be the fodder for the actual retro meeting.

There are also other biases like sunk cost fallacy and halo effect that I am going to discuss in this session.

Traditional software delivery teams are layered with roles like user experience, project management, business analysts, developers, QAs, DevOps, etc. With the translation of business problems at multiple steps, each role induces a fitment drift in the devised solution. As part of this talk, we would like to present our experience from the last 7 years building products for clients delivered by teams with ZERO roles (No PM, BA, QA, DevOps). It presents the argument and evidence of why the notion of needed depth in every skill, every single time is an overkill, and how a small team of people who dabble with code and product thinking both can deliver solutions that are faster and better with minimum fitment drift. We outline the practices and rituals required to establish, operationalise and sustain skill-based teams. We also intend to discuss delivery objectives for software teams and how teams that organise themselves around business objectives deliver better products compared to one's setup with superfluous roles for analysis, testing, and management, etc. 

Have you heard of “flaky tests”?

There are a lot of articles, blog posts, podcasts, conference talks about what are “Flaky tests” and how to avoid them.

Some of the ideas proposed are:

• Automatically rerun failed tests a couple of times, and hope they pass
• Automatically retry certain operations in the test (ex: retry click / checking for visibility of elements, etc.) and hope the test can proceed

Unfortunately, I do not agree with the above ideas, and I would term these as anti-patterns for fixing flaky / intermittent tests.

We need to understand the reasons for flaky / intermittent tests. Some of these reasons could be because of issues like: 

• timing issues (i.e. page loading taking time)
• network issues
• browser-timing issues (different for different browsers / devices)
• data related (dynamic, changing, validity, etc.)
• poor locator strategy (ex: weird & hard-wired xpaths / locators)
• environment issue
• actual issue in the product-under-test

In this session, with the help of demos, we will look at the following techniques you can use to reduce / eliminate the flakiness of your test execution:

• Reduce number of UI tests
• Use Visual Assertions instead of Functional Assertions
• Remove external dependencies via Intelligent Virtualization

Demo will be done using the following and sample code will be shared with the participants

• Specmatic
• teswiz
• Applitools Eyes

Designing and planning for enterprise-scale initiatives is a tedious process, especially when the organization is big with 20k employees. Having different verticals to run different business functions like IT, marketing, finance, sales, engineering, etc. poses an additional challenge. Preparing for change that affects the whole organization impacts hundreds of systems and business processes.

Fortunately, I had an opportunity to be a part of such an initiative. I would like to share how drafting data flow and process diagrams as per value streams helped us to articulate the current picture of different systems and processes. How it helped in identifying business-critical pain points and proposing solutions for those with ease. 

In this session, you will also get a behind-the-scenes glimpse of Archimate and how I used it effectively in an enterprise-wide initiative.