If you happen to be in a meeting full of IT specialists talking about a project, designing a new product or feature you are bound to hear the word test coming out at some point.
No one disagrees that tests are important, no wonder we spend so much time building different environments to fully check our changes. However, even though we all agree that we must test, it is quite hard to agree how we will test.
We all know different tests we can do, I will not talk in this article what is a unity test, or stress test, or integration test, etc. From testing our code in isolation to testing our whole infrastructure, today we have technology to build and run all possible test dreams our organisations might have, but why are we even doing it? What are trying to achieve?
Confidence, according to The Oxford Learner's Dictionary it is defined as the “the feeling that you can trust, believe in and be sure about the abilities or good qualities of somebody/something”. While in IT terms I define it as "I am sure I am not gonna be paged this weekend”.
Jokes aside, confidence is something we build to bring evidence that what we deliver is fulfilling what we have previously agreed with someone. Let’s break down some concepts here and, together, try to find some sense out of it.
We create things for our customers, and these customers can be external ones like other organisations or our society. They can also be internal customers like other teams and departments. The role of a customer can be played by a myriad of different people. However, for our discussion, it does not matter who is our customer but actually what expectations we have established with them.
When it comes to agreements, the tests we build will collect the necessary evidences that we are meeting what was promised, therefore if our agreement is unclear that might directly impact us.
Figuring out what the customer wants is hard, especially because most of the times the customer also does not know all about its needs.
Agile plays a critical role here as it taught us that, by iteratively building the product and putting the customer in the centre, will lead us to a feedback cycle which will positively impact the product. Therefore, if we design tests following this flow it will validate the feedbacks our customer gives and will be the evidence that we are going in the right direction.