QAshido – The path of the tester. Virtue # 1 – Technical skills.

Reading Time: 6 minutes

Link to: QAshido – The path of the tester.

Why technical skills are important?

I think this is a pretty obvious one, that’s why I start from it, but I more often see testers believing or at least having a “good excuse” to pretend that technical skills and abilities are not essential for the job of quality assurance engineer. I won’t lie if I say I find this ridiculously wrong, we are working in the tech area and it’s near to impossible to be good at it without having the proper knowledge of what we are dealing with. Think of it as a doctor saying it’s not a important to have a good understanding of anatomy in order to be good surgeon.

Of course as stated in the introduction article it’s not just the technical skills we need to be a good testers, but yet they are the bread and the salt of our business, so don’t even try to omit them. May  be there is some people working in our area that lack essential technical knowledge but they for sure are not the future of QA and they better start evolve asap or they will disappear.

So I will state the skills I believe are essential, starting from the ones that are more general to the more specific ones:

Databases and basic SQL scripting skills.

This is totally a must. Almost every application that you are going to use, test or even just explore will have some form of database to interact with. So in order to understand how stuff works on the inside and what can go wrong under the hood it’s a good idea to know some stuff concerning databases. No one says you have to be a database admin to know it, it just basic stuff that are useful. So here are some of these:

• General description of databases – this is what is a database in general, what it consists of, what is a relational database, respectfully what is a non-relational database, what’s a table, a view, what’s a primary key, foreign key?
• What’s normalization of a database?
• What’s a stored procedure?
• Some basic SQL scripting skills – and by this I mean really basic ones, at least knowing what is what in a query. No one wants you to know the exact syntax, it’s there you can google it anytime.
• Some basic maintenance skills are useful, too – how to backup DB, how to restore from a backup, how to create a table, how to edit user rights, allow remote access and so on.
• What’s collation of database and what are the data types used in it.

Networking.

This is a very wide topic and it’s not easy getting familiar with it, it’s more of a administrator area of development, but if we need to know some basic stuff in order to do our job without being confused by terminology we simply don’t get. Some of the items we can cover here are:

• It’s good to know what OSI model is, what it consists of, what is what in it – just the basic stuff is enough, no need to dive deeper in it.
• What is a DNS server?
• What is the difference between IP v4 and IP v6?
• What’s a router, what is a load balancer, what is a VLAN?
• What is a protocol, which ones are commonly used and why, which ones are secure?

And really some of these might seem irrelevant to QA, but if you decide to dive in security and penetration testing, then networking and protocols is the part that you will practically have to memorize before you even start doing any testing.

Services.

Same as databases almost any application that’s more complicated than “Hello World!” will communicate with some sort of services, will get data from them or update some data to them. So few important items to know are:

• What are RESTful services?
• What’s a “header” and what’s in it?
• What’s JSON and XML, what’s the difference?
• What do these all error codes mean – 3xx, 4xx, 5xx?
• How to test services without having the front end consumer build yet?
• What’s a “cookie” and why it is used?

 Knowledge of operating systems, Linux in particular.

In your testing career you will have to adapt to many different operating systems, if you are more than just a regular user you will probably know Windows good enough, but than it comes Linux and Mac OS, and if you are going to get involved in the mobile development you have Windows mobile, Android, Blackberry OS, iOS.

So there’s couple of essential “good to know”s:

• How does an operating system start in first place, what is the BIOS, what’s it for?
• What’s the difference between 32 and 64 bit architecture – believe me I’ve heard such an incredible bullshit on this one. 🙂
• What’s a kernel?
• What are the main differences in operating systems?

And I put importance on Linux, because it is an item which very often pops up in interviews and in job descriptions – not just because it’s so different and at some point complicated, but because knowing how to deal with a server is 75 % Linux – the reason, well, many servers are preferred to use Linux, it’s light weight it’s fast, it’s free and it has large abilities to scale, plus it’s fully configurable and customizable.

The thing is you need to know how to do all the stuff you do through command line. And honestly I don’t know better way to do it, than just installing Linux and play with it. So here are the items valuable for you as a QA:

• What’s the folder structure in Linux, how it differs from the Windows’ one, where are systems files stored, what do folders like /usr, /boot, /home used for.
• How to navigate in command line, how to copy, rename, delete files, how to make backups, how to create/extract archives.
• How to use package management systems – yum, apt-get, pacman etc.
• How to start and stop services, how to adjust networking.
• How to compile software form source code on our own.
• Some basic knowledge on what are logs for, which will lead to – how to use text editors like vi and vim.
• Basic shell scripting skills.

 Programming skills.

This is quite a controversial topic – whether or not is important for QAs to know programming languages and in general programming concepts. Well, I say yes, it’s a must. Why? In first place, it’s much easier to figure out or predict what’s the internal logic in an application of you know how to construct one, also you can always do a white box testing if you know some programming language, but I am afraid you can not if you don’t. Not to mention, many of the principles in programming are used in software testing, too.

So important items that we could harvest from programming are:

• Basic concepts of programming like functional programming, object oriented programming.
• Data structures.
• Good practices – open/close principle, DRY, SOLID and so on.
• Differences between strongly typed and type-less programming languages.
• Differences between compilation and interpretation of a programming language.

In general, it will be useful if you just learn a programming language from A to Z. It’s not obligatory to get everything at first time, or even at all, in programming there is concepts that are bugging even experienced developers – stuff like recursion, dynamic programming and so on. My suggestion for a language appropriate for QAs, is Python. Why? It’s modern, it’s easy to learn, it’s designed to be highly intuitive, it implements modern concepts like OOP and it is supported by Selenium Webdriver which is one of the most useful open source tools for automation.

The good thing with programming is, in general it’s a concept, and once you get it, the syntax of the language you use is just a detail, and you can easily switch languages if needed.

Automation.

The elephant in the room, is it? 🙂 Well, yes. Automation is important. And as I stated in my previous article “Testing is a mental process”, I am really not a fan of the division – automation and manual testers. To me, there’s good testers and lazy testers – the ones who don’t want to learn automation.

Why is it so important? Well, in first place it’s that modern thingie that everyone is talking about, everyone wants to know automation. Not that everyone knows why, but anyway. Knowing automation in testing is like buying a Lamborghini in real life, you only mention it and the chicks go crazy. 🙂

But being serious – automation is a huge advantage, because you always know you have another, easier way of doing trivial tasks that take more time. And not only, automation is the future of software testing – as more and more complicated applications appear, there will be more automation created for them and companies like Google ans Microsoft already started to automate a lot of the tests that are executed on their products. But it’s important to know that automation should not be considered as a silver bullet, it is only useful for minimizing the time spent on doing trivial tests, so you could spend more time on design and execute complicated ones, I made the same point in a comment under the brilliant post of a fellow blogger – Dave Edwards here: TEST AUTOMATION SOLVES EVERYTHING!.

So here are the important takeaways from automation:

• What tests are eligible for automation?
• When are we doing automation?
• Some basic tools, recorders frameworks for testing automation – there’s plenty of them, but start with Selenium for sure.
• Page object model for using the OOP as our advantage of creating abstract test cases.

And many more…

And the list goes on and on and on… There’s no limit of maximum skills that a tester can get. I mean, you can’t get too good and know too much stuff. So this list could change, extend or vary depending on what your needs are or how you decided to develop in your career.

I hope it was interesting for you reading it, as it was fun for me writing it, and if you want to share your thoughts, opinions or critics to me, you can do it in the comments.