Seven Tester Rules

“At first, your attempts had to fail, so that you were ready to grab onto the lifebuoy that you would be thrown.”
E. Herrigel
"Zen and the art of archery"

Are you a manual tester?
No time to automate testing?
What you need to test, can not be automated?
You have already reached the heights, but you want to see someone else's path?

Then I ask under the cat!

')
I began my career as a tester in a small company that tests aircraft software. There was only automated testing, all processes were already built, in general - not very difficult work. I was shown the basics of writing code in Visual Basic, showed how to run tests, and sent off to a long journey.

Then my student body ended, I wanted more interesting work, and I moved to another company as a simple manual tester. Here you need to make a small digression - in small campaigns / departments, the tester sometimes performs a whole bunch of tasks that are not directly related to testing. For example, deploying a test environment, maintaining several branches of a product in source control, support for released products, etc. I got into exactly this situation.
At first everything was fine - we did our 1 project, I did everything with my hands, and I still had a lot of free time.

But gradually the projects became more and more, programmers constantly fixed bugs, it was necessary to roll builds almost every hour. At some point I noticed that I spend only 40% of my time on testing. The rest of the time is occupied by some kind of left activity. Then I understood the first simple rule :

1. If you are a tester, then it is possible and necessary to automate not only testing

It was then that I made a simple table in Excel, and noted all the tasks for which time was wasted. And I found what was most likely to survive - the banal display of builds (updating files, ekzeshnikov, etc.). In the evening, I buried myself in Yandex, and found how to remove this activity at 0. I looked at the build syntax on our build server, and made an automatic calculation of this whole economy. After that, I tied the launch of the build to the check-in at the source control, and was delighted with life - I had free time again! Then I understood the second simple rule :

2. Automate what will give the greatest gain in time

Gradually, projects grew, and systems appeared on several servers. And, oh, horror - the configs of the developers did not work on the servers! And programmers for some reason (!) Did not want to edit them. Again, I climbed into the build machine and found that configs can be easily changed at the build stage. Then I understood the third simple rule :

3. Fully study the work of the build machine

At about the same time, the first virtual farm on Hyper-V appeared at my disposal. After a couple of months, I no longer imagined how I had lived before. It was so easy and simple to lift test benches! Hence the fourth simple rule :

4. Lift the server virtualization

At that time, the company grew very much, and suddenly it turned out that for a simple institution of registration in the domain, you need to write an application to admins with a justification and confirmation. For a while we tolerated, and then I made my test domain. After a month, I realized that not only was the virtualization server needed. Hence the fifth simple rule :

5. Finally make your test domain.

When I raised the test domain, I found a funny thing on the server - Power Shell. As it turned out, a lot of things can be done without an interface - get users, configure IIS, make firewall rules, install services, etc. In addition, I learned that this can be done not only on my car!
And if you need to do some task on a remote machine more than three times, I always write a script - saving time is huge.

In general, the sixth simple rule :

6. Understand PowerShell / cmd / bash

At some point, I realized that even without starting to automate testing, I automated everything else!

Then I undertook to do my first huge (as it seemed to me then) project on automated testing of one huge monstrous business function. I did it for a long time, painfully, but I still did it. It was only there that there were so many crutches, implicit dependencies, hardcodes and other good things that somehow it was impossible to support this creation of the inflamed mind. It was then that I understood why these smart programmers admit so many jambs ... But this was not the last monstrous system in my performance - there were many more. In general, the most important seventh rule :

7. Want to automate? Learn to program correctly ! Read books on program architecture.

It was here that the quotation made in the epigraph showed itself. Only having made a few terrible projects, breaking off a bunch of teeth on the support of my creations, I began to understand what these clever guys wrote in their books. Only the total lack of time and the dullness of the work of copying files from one place to another pushed me on the path of automation. Only having fully integrated into the development team did I start writing relatively normal code.
And then I got involved. And the next few books in terms of reading - about programming. And I will not go to the programmers, this is not mine. Well, I already became a programming tester.

And most importantly, do not be afraid of automation. These are not always great works that can bring mythical profits in the future. Look around! Can something be done with a mouse? With a probability of 95%, this can be scripted. Are you performing manual operations for the fifteenth time? So it was necessary to script them yesterday.

And one more wish. I learned myself, enlighten your colleagues - you will agree, it is more interesting to work with people who make beautiful, complex projects, and do not go in a dirty sweater and suffer from their work.

I wish you interesting bugs, good projects and friendly fellow programmers!