Hello, my silent audience! Let me break the long silence and share a short essay about the project that I have been working on for the last year.

I’ll start with a lyrical digression, that is, with gratitude. I am incredibly grateful to this project of mine for the opportunity to fully experience what a mother-in-law feels when her beloved son-in-law tells her – spin as you please, but tomorrow is the deadline. My gratitude also knows no bounds towards the people with whom I work on this project – without you, my dears, I would probably have remained an ordinary project manager. Now I know for sure that I am the most ordinary manager. Because…

.. only an ordinary project manager will take into account the project plan from his predecessor and will not try to delay the deadlines, cut the scope, or throw out features – in general, do at least something to increase the likelihood of delivering what is left by the end of the project. Well, do you remember those swings that were somehow tied to a branch with a rope?

.. only a narrow-minded manager will believe the developers, their words that tomorrow they will definitely do what is needed, and it will work.

.. only a suicidal manager would believe that the project team may not have a tester at all.

.. finally, only dumb$#% (you can insert different letters here – all this will be true) can agree that you can work without a version control system, only because the development environment that is used on the project is incompatible with the corporate one system, and setting up, tweaking, tweaking something requires a gigantic amount of effort.

Here. Yes, in our project there is no architecture framed behind a piece of glass, no Coding Convention, in short, real Cowboy Coding.

At the same time, oddly enough, the project is being completed, coming to an end, with stable quality and predictable deadlines.

How?..

Automated testing came to the rescue.

Soon after the project began, we as a team realized that we were missing something that would be an impartial quality controller for each delivery sent to the customer. Those. Each delivery must contain at least the same functionality as the previous one, with only those changes that were requested by the customer. All refactorings are technical debts – the customer does not care. I received the delivery, checked it, and sent it to continue. All.

We looked at our system as a black box, to which certain files (input) are fed as input, and certain other files (output) are expected from it at the output. We started making a system that automatically feeds these files and then checks what happened. Here are the metrics – the output file came out or did not come out, how many seconds it took, how many pages it contains (output files are documents), how many pictures, what indentations, what text is inside, and is it the same text that was in the files generated by the previous version. What if it’s not the same as here – inserted or deleted text? What if there were 3 pages, but now there are 4? Then we sent reports for the customer – a list of documents supported by this version, and a list of changes in these documents. Then came the generation of input files based on formal descriptions of documents to ensure completeness of testing. Then – analysis of the logs of our system, whether anything fell there during the generation. And along the way, we did some refactoring, so much so that the customer didn’t even notice.

Well, that’s all, that’s the end of the fairy tale. The moral is simple – if you feel that something is missing “out of the box” – there is always a chance to make it and stick it on, it will be better!

PS Help me choose a beautiful picture for this post!🙂