So firsts things first, imagine you’re the developer. It’s easy, just drink a lot of coffee and put some matrix wallpaper on.

So… now you are asked to constantly make sure that whatever functionality you have developed some time ago is working as designed (Quality Assurance aspect). Let’s say it’s one of core functionalities of your platform. And without it business will surely try to murder you.
1

Let’s simplify it a bit so it’s a login functionality (in more complex cases it might be a happy path, data entry etc.). It might be closed environment, internal network. Easy right?

2

What do you do?

In most cases you would create separated tool, code it, compile it, maybe use some external library, prepare documentation, handover to support, and pray IT does not forget about it.. because what if the tool to check the tool breaks? Should you design a tool to check a checking tool? And usually it needs to be a tool because applications for IT monitoring as check-smth just monitor CPU and RAM. Here you deal with multiple browsers and simulation of an actual user.

3

Usually what happens is that functionality eventually breaks, and nobody notices it because server with a tool is down, support is late and you are likely to end up being chased at 3:00 am being asked why it’s not working for a week.

And now imagine you have some magic tools. Or a friend. Or FRENDS. Then you just draw something like this.

FRENDS

As a result you have designed something that is understandable by both business and support. You did it in 5 minutes (actually I did, and it was 5 minutes literally). And it comes with the additional features to ease up you work:

  • If something fails or breaks, you can notify the team. You can use SMS, e-mail, or any other provider you use. As a result, support will be aware of an issue in a timely manner and act fast. You might even add yourself in 1 minute by using Graphics user interface (GUI), save and publish;
  • Then you might connect it with Jenkins or other automatic releases to production so it runs every time you deploy. No more suprises.
  • You might want to update JIRA test tasks, easy! Use JIRA API.
  • You can use low-code in a task. There is nothing FRENDS specific so if you know your .NET you know FRENDS;
  • Already have some test suites? Integrate them here or add new ones. You can launch command line so you might even use JAVA, nodeJS, C++, Selenium 😉 whatever is your weapon of choice;
  • Then you might run it on testing environment in seconds with different env variables?
  • And if you want to run it manually you just click this:

manual

  • And you will be able to see a complete history of processes as well.

processes

And what comes to the documentation… Well, it has already been done automatically in a design phase.

And here comes the question: Why are not people doing it the second way?

The second way offers so much less ambiguity, it’s self-documenting, saves so much on down-time of an application. Better customer experience.

Speaking for myself?

I’ve been myself there a long time ago, and I was building processes the first way myself. Believe me or not, you do not want to follow anymore the first option in today’s modern world :).

Why the first way of doing things still prevails, you may wonder. Well, I think it’s not that developers would not like to do it a smarter second way. Usually, what I have noticed, it’s the business that does not provide the right set of tools. Maybe it’s due to the lack of awareness or a learning curve (which is almost non-existent)? I don’t know.

Please notice that this example was only a testing scenario. Imagine how many more processes related to your business you might do this way! For example, informing operations about a new lead opportunity, or synchronizing your business applications… Sky is the limit.

In summary:

Option (1) involved people from support watching your monitoring-tool, they don’t know the code or a process, you need to purchase additional machine to monitor state of your app, write documentation separately. And it still might break.

Option (2) involves DEV tooling where you outsource a part of monitoring responsibilities. It’s pay as you go, or license-based, and it always works: One place. Multiple environments. Production and User Acceptance Testing (UAT). Unlimited processes. Multiple applications. Almost immediate service level agreement (SLA). Great support. Large community. Compliant with security and internal environments (closed/self-hosted).

And please note that those kind of tools actually do not take job from your developers. Such tools help them succeed, instead, but if you really don’t have time, we have a team that can design and deploy processes for you ;).

Want to know more? Write us a line.

Categories: Wait but IT?