tools

Day 4 (of 30 Days of Automation in Testing)

/ jankka / Leave a comment

Day 4: What kind of testing can automation support you with?

Unit testing comes to my mind as the first one.It helps me as a tester in a way that I let developers do the deeds and learn to trust they do things right. Even reviewing the unit test code is actually a neat learning experience, once you get to understand the unit test logic.

Functional testing during or right after the build, can also be done by same unit testing approaches, which is also a neat way to verify the functionality. The benefits on that one is that the code is readable by the developer who wrote it and (in case it’s not made with Perl) even with other members of the team or company. To have the tests usable and readable in the same IDE developers use, leads also to easier debugging. What usually lacks is decent reporting, but then again, all we need to know that it fails when it should and passes when everything really is OK.

Mocking the test environment and harnessing the SUT. They walk hand in hand. There’s plenty of nice mocking tools, wiremock for example. One might also re-invent the wheel here. I mean the mock can be just a file you fetch from another system or write yourself. Does not sound too much automating, though 😀

Load testing is also one of the standard ones to be used with automation. Given the powers of the servers, new container technologies and distributed load testing services, you can build your own solution or use a ready made service, like blazemeter or octoperf.

Repetitive functionality tests, regression tests and release tests in any step of the development process are good to automate, given that you are going to use the automation more than few times.

Then the whole world of Continuous Delivery and Continuous Integration. It will not happen properly if you do not have the right tests put in right places. Well it might be OK to let the users test the product, but that would mean that you should have an automated monitoring system that gathers the data you will need. That’s also one way of automation that will help.

And of course all of the test data generating tools, self-made or otherwise, bash- or python -scripts for setting up the environments together with containers and their managing tools (docker, docker-compose and kubernetes to start with).

I most likely am missing something here, still. I mean where do you draw the line when it comes to automation in testing? Is it only the testing tools (like jMeter, Robot Framework etc.) or the tools that let you yourself automate mundane tasks to ease your testing process.

 

 

Advertisement

Running with the hammer

/ jankka / Leave a comment

 

There's no hammer here.

There’s no hammer here.

Tools are tricky. Well not all of them and to be honest after a while any tool what so ever is easy to maintain and handle as the user experience has gained. The learning curve of course varies a lot.

Let’s take such as a hammer. A somewhat blunt instrument for hitting. Anyone can use it. Anyone can hit with it. Anyone can hurt themselves with it without any particular training. Nevertheless it is hard one to master. I’ve watched the master carpenters hammering down floor boards in such speed and accuracy that I doubt there’s no way of me getting there. Well not at least by watching. As a friend of mine used to say: You learn to run by running. The same applies to hammering. No, you don’t learn to hammer by running, even for some of it might sound tempting, but I doubt that’s the way it goes. What I ment – for those who still are running with the swinging hammer – is that you learn to hammer by hammering. A lot. They say it takes 10000 hours to master something. Or was it 10000 repetitions. Give and take a few. So as far as I see: there’s no way I can get hammering that much. I already have this writing and working to do.
And that’s the normal excuse on not mastering anything. The road is long, I don’t have time and besides the next guy does it already so well; the Polish (or Estonian, Mexican, you name it) do it cheaper and faster.
But consider this; the road ahead starts from the first step. That’s all you have to take. Once again, drop the hammers and stop running. I’m all metaphores here, the action comes later. Yes, I know, boring. But pay attention.

We here are proud owners of knowledge, gathered knowledge. We’ve done it at work, at customer premises, while killing time in between the assignments, on courses or in the evenings when you could do something else with your lives. You name it. We all have it.
Now let’s imagine that we could have a vault of combined knowledge. A stuff we could get into and read and contribute and flourish with our knowledge. Actually, you might kindly point out, there is. Some might call it the internet. The googlepedia, whatever. The truth is out there. And in here, too. It’s inside ourselves. And we do use it, don’t we.

So the trick on knowing more and spreading the already gathered knowledge is not that hard. Not at all. And that’s precisely what I’m trying to point out in here; don’t just take the first step. Take also the next. And the next. Keep on going. Hammer down the obstacles of your mind (there! You see, there was use of that hammer after all!) and walk on. But most of all spread the knowledge, don’t sit on it. The more you give the more you get. Really.

And that’s what this blog is about to be. A forum for me to boast myself (as always, I’m the most humble and modest guy of the world) and spread the word on the tools I’ve used and evaluating to get some order to them.

Soundtrack: Pink Floyd – The Wall

Blunt Instruments Of Testing

/ jankka / Leave a comment

Welcome to my blog. This blog is attended to be a placeholder of thought concerning Software Testing and test tools particularly. Most likely – so far as I know which kind of writer I am – the blog posts will vary somewhere around the big topic.

As a professional tester and a wannabe writer I see writing as part of the thought process in order to organize my ideas. It’s kind of similar tool than discussion with colleagues or friends sometimes can be. So at least for me that’s one of the professional tools a software tester can use. For me writing a test journal is a crucial part of working, and it helps me to organize my memories on my work assignments, which sometimes can come and go and change rather rapidly.

I will be forming this blog every now and then and most likely to write as often as possible. We’ll see how far I get with this approach.