Moving test from cost center to cost benefit

Being Force multiplier

MTer needs to be seen as positive influence

Boiling Frogs

Delta from Idea to deployments is rapid

Get that mvp out with just enough quality to get feedback from customers

“You don’t get value from engineering effort until it is in customer hands”

No one tests your product better than your customer

There are bugs and bugs that customer cares about

The GOAL

Our goal is to accelerate team

its about

Lean Principles

Books to read

Don’t forget MT context

By focusing the MT Practitioner on identifying their role as acceleration”

It’s important cause far to much of The TEST is reverse of this

This mantra is About completion and predictability not about value in order to accelerate you need mechanism to identify what value is and what the next bottleneck

Quality is problem solved to humans being

Fast feedback loop is critical in context of understanding what is quality

By Balancing fallacy of value with failure to launch

“We are going to favour continuously adapting and improving above safety net presentation model.”

It’s wrong that testers feel validated by the fact the developers don’t want to test.

Code correctnes

Safty net is a problem

Continuous improvement

It’s a critical process change directly related to Quality

Testers are well suited to drive continuous improvement

By measuring

Unified engineering

Lots of small changes

Frequent retrospective (only 1-3 action)

A small vertical slices of architecture

Master branch owned by the business they can release it whenever they want

Quality culture and leadership

Testers need to stop being passive

Quality culture

ADKAR Model

The reason is we want feedback from our customers more often

To work in the way we want to function, to keep, retain and engage more users we need the quality culture

to move testing

Unless the whole team has a common understanding of the problem trying to solve it is pointless

Small Batches

Knowledge sharing (software is knowledge works)

Try stuff -> fail -> learn

Reaping the band-aid works only when people are ready.

Brent example on slack TL:DR verion

Definition customer - it is a human who takes a dependency on what you are releasing, and that human can make decisions what quality is

It is not about preventing harm

Customers don’t want software; they want the problem solved.

It is seductive to believe “hey I am doing it forever I know what I am doing

There is a risk in trust that QA belife in requirements doc and PMs , are solving a customer problem

Need vs want

Example of building wrong thing

Ask your self

Requirements from the business should be treated as hypothesis

For each feature request you can ask question:

Leaders ship is disappointing people at level they can absorb

Validating hypotheses doesn’t mean pushing buggy software.

Your reaction time is important.

we need to be able to know

Data is critical to scale

As long as you have good telemetry, you can find and fix bugs

Relaying on telemetry and customer data doesn’t mean it is using the customer as testers

Customer don’t care about test cases run, nor about a code coverage

Instrument the hell out of your software

Use automation as a load generator and let the telemetry be a test oracle.

Data tells you where to focus.

Check episode 82

Once the product ship - look at the data and try to figure out which testing effort was wasted.

Who values your product?

tl:Dr data is important