30 days of testing

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

30 Days of Automation in Testing

/ jankka / Leave a comment

Once again it is summer, once again Ministry of Testing comes up with interesting 30 days challenge.
This year I spent my vacation already in May, so that excuse for not doing this won’t do; I’ll have to tackle this one.
The challenge is about test automation, sponsored by SmartBear (I do not like their products, but what can you do except not to use them 😉 ).

Day 1: Look up some definitions for ‘Automation’, compare them against definitions for ‘Test Automation’

Whereas automation definition in Wikipedia (the source of the sources) is actually handling a wide range of different mechanical and programmatical approaches, Test Automation is considered only to be software related and listed as part of software development. I do consider that one could test things mechanically and control the checkers, tools and results by machine, at least when it comes to simple checks. Wherever you’ll need human interpretation, it is actually easier to get a fellow human to make a judgement. Machines are good to make repetitive tasks easy, but they are also well capable to repeat an erroneus step several times automatically, unless someone controls the situation.
But anyhow, the biggest difference between automation and test automation according to wikipedia is the narrowing of test automation on something that’s done with software.

Day 2: Begin reading an automation related book and share something you’ve learnt by day 30.

Agile Automation and Unified Functional Testing by Rajeev Gupta

I’m also trying to make it through this course:
REST API Automation testing from scratch-(REST Assured java)

Day 3: Explore the automation thread on The Club and contribute to the conversation

Added my contribution to https://club.ministryoftesting.com/t/when-to-start-automation/11743/10

Install Secure Lab Tools in Fedora 26

/ jankka / 1 Comment

I am working my way to dive in to the world of security testing. We have been going through the tasks on 30 days of security testing from Ministry Of Testing Dojo. The themed tasks is actually a really good way to keep up in learning new topics and deepening your knowledge on different issues at hand. Ministry Of Testing has a nice series of themed months on the catalogue and I warmly recommend to check them out.

We have been doing the themed months a bit differently. First of all, we accept the fact that there is weekends and people do not have to live, breathe and urinate testing. Even though it does help from time to time. So, our approach has been mainly to do 30 days of testing during the weekdays. Which means that instead of 4 weeks, we’ll accomplish it in approximately 6 weeks.

Anyhow, one of the things beside the security testing challenge has been us having a course on Ethical Hacking. The course is available in Udemy and it is reasonably priced, so I recommend that, at least if you’re not familiar with penetration testing and hacking techniques in general.

So, we go through tools and techniques and use Kali Linux for that. Which seems to be powerful to use. As I am running Fedora 26 on my workstation, I am running the penetration test stuff on Fedora Boxes (more stable than VirtualBox), but I noticed that it would actually be nice to have the tools on my actual workstation, too.

So I went and googled a bit and as I knew, someone had already solved my issue.  As I am using Finnish language on the laptop, my installation command was like this:

# sudo dnf groupinstall Turvallisuuslaboratorio

For most of the people who do not have the capability to understand Finnish, it would make sense to use something more, how to put it, understandable language, like English.

So, in that case I suppose the command should work like this:

# sudo dnf groupinstall security-lab

By the way, while writing this, I did write the Kali Linux on a USB disk. It actually feels better to have it there than fooling around with virtual machines (in this case). Even though I’ll have to reboot the computer if I want to run it.