Handover & Client Testing

How to test the system we have developed for you

📆 Testing times

When we hand a system back to a client to test, a period of 7-14 days (dependent on the contract) is initiated for the client to conduct their own testing and sign off the system.

Our developers will provide explicit instructions to test specific functionality and logic.

👍🏼 Correct expectations

We think we have built what you asked for, as detailed in the brief provided to us by you.

Cards on the table / 🐘 in the room : If your brief had holes, so too might your system!

It’s actually surprising when one realises how much ‘tacit’ knowledge businesses operate on – i.e. things that they don’t know they know, and which form a part of their operational processes. You know your business 100% inside and out and the things you need to do in the course of your workflows. These are likely the things you may not have mentioned because they are second nature to you.

We know the things about your business that you’ve told us – but not 100%.

🕳 Gaps in your system

If you realise your system doesn’t behave as you think it should, it could be because you assumed we would know something that we did not. Or because your explanation of ‘a thing’ was open to interpretation in a way you were not aware of. Normally this is around decisions which are made during workflows.

This is your business logic.

The opposite to tacit is explicit. Explicit means “stated clearly and in detail, leaving no room for confusion or doubt”

🌱 Emerging logic and scope extensions

It is common that as we build a system to automatically replicate what an intelligent person does, we discover that aspects of your business logic were not disclosed.

But they only become clear as we tried to codify (i.e. make explicit) your logic when automating it.

Don’t worry – it’s normal to discover things as we go ... we call it emerging logic. It happens and is a natural part of automating a business.

Worked example of emerging logic

You might have told us you needed an if this then that workflow (a TRIGGER then ACTION type of thing). For instance: When a web form is submitted (TRIGGER) create deal in CRM (ACTION), i.e.

if TRIGGER then ACTION

But now you see that automation working, you realise it wasn’t as simple as that: There are actually multiple outcomes you might need depending on some other conditions (VARIABLES). So you actually need something like this:

if TRIGGER (and VARIABLE A) then ACTION A

if TRIGGER (and VARIABLE B) then ACTION B

if TRIGGER (and VARIABLE A & VARIABLE B) then ACTION C

So now you realise that you need it to do something that we did not design it to do!

FYI we have written a doc on flexible logic here.

🚨 So is this a bug?

In this case, you could say that the automation doesn’t operate as you would like, and even use the term ‘bug’ or error, but in fact it’s just missing functionality that wasn’t specified.

We do our best to help clients know how to provide a detailed brief to our developers, but sometimes our clients are in a rush and forget to properly explain their process and they got exactly what they explicitly asked for.

So we do not refer to these as bugs.

We explain what we mean by bugs here:

⁠

Bugs & Issues

⁠

🛠️ I need to change something

No problem.

We are happy to extend your system to incorporate new logic and complexity, we just please request that you provide a detailed description of what you need to happen.

As we state in our rapid support brief / client help request forms, the best way to explain this is TO SHOW US. Record a narrated Loom video where we can see your screen, hear your voice and watch your mouse cursor.

All subsequent changes are deemed as additional scope and will be added to your final bill.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.