I am sorry for the delay in publishing. Currently, I’m in Bath. It is an amazing city in Somerset distribution of United Kingdoms. Most of the people come here for vacation or lovely cider (really, really lovely!), but I am here working on-site with our client. I was so excited to come here again especially due to the reason of my travel – I am here to support our client in live release!
I am mentioning it because while working so close to the client I am working on something I call “business language”. In my opinion understanding the business background is as important for tester as understanding the application itself. It gives us the proper context for both development and testing. In my career, I found myself often in the place of translator between business and development, when today I am working the other way around – as a source of development knowledge for business.
Business to development language
One of the basics of developing the piece of software is understanding the business needs – what problem will be solved by this code. This allows us to design a proper solution. Knowing the process it will be used in – both triggers and steps – allows us to build a good test plan.
Many of the issues I found in my career were only found due to the knowledge of business context – e.g. my favourite hyperlink, which worked perfectly in PDF file, but not after printing:
Of course, the knowledge how it is expected to be working for raising an issue. We must be sure what is the expected result, not suspected one. Lastly, knowing the business background is helpful in managing priorities. This comes handy when we are overwhelmed with work and need to decide what is more important.
Development to business language
This also works the other way around. Knowledge of implementation, dependencies and system connections can be translated into risks. Testers can also serve in issue investigation to find the potential source of them and possible workarounds. And as I mentioned it at the beginning – this is my main role for incoming two weeks.
I’ve heard a lot about working closely with developers and gaining more knowledge about the code and implementation. I agree we need that. But at this same time, we should reach to the other side – business side – and work with our customer as well. Requirements in the user stories might not be enough sometimes. Understanding processes and needs might come handy when planning our tests or during the planning of implementation itself.