In this series of blogs, "Developers Opinion", developers that actively work with integrations and Frends share their peer-to-peer opinions and experiences. This time, Paweł Kowalski from HiQ Gdynia shares his honest and casual observations on old vs. new ways of monitoring and Quality Assurance (QA) processes.
Imagine for a moment that you are a developer. It's easy. Just drink much coffee and put some matrix wallpaper on.
So... Now you are asked to constantly make sure that whatever functionality you developed some time ago is working as designed (Quality Assurance aspect). Let's say it's one of the core functionalities of your platform, and without it, your business will surely collapse.
Simplifying it a bit more: let's say it is a login functionality (in more complex cases, it might be a happy path, data entry, and more). It might be a closed environment or an internal network. Easy right?
What do you do?
- In most cases, you would create a separate tool, code it, compile it, maybe use some external library, prepare documentation, hand over it to support, and pray IT does not forget about it... because what if the tool built 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-something" just monitor Central Processing Unit (CPU) and Random-access memory (RAM). And here, you deal with multiple browsers and the simulation of an actual user.
Usually, what happens is that functionality eventually breaks, and nobody notices it because the 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.
- Now imagine you have some magic tools. Or a friend. Or Frends. With the help of which you just draw something like this:
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 your 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 surprises;
-
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 already know Frends;
-
Already have some test suites? Integrate them inside Frends or add new ones. You can launch the command line so you might even use JAVA, nodeJS, C++, Selenium ;) Whatever is your weapon of choice;
-
Then you might run it in a testing environment in seconds with different environment variables;
-
If you want to run it manually, you just click this:
- And you will be able to see a complete history of processes as well.
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 the 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 the first option in today's modern world anymore :).
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) involves people from support watching your monitoring tool, they don't know the code or a process, you need to purchase an additional machine to monitor the state of your app, and 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 kinds 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 ;).
Get a free 1 month trial to get to know frends and see how it can help you with projects.
