There’s no denying that the world is in constant flux. Thanks to the web, automation, and the data processing abilities of modern computers, the border between humans and machines has become fuzzy. How does it affect IT and QA testing in particular? And finally, which QA skills make great QA testers well, great?
The ideal set of QA skills
As we become more dependent on AI and automation, the role of QA testers has changed too. Does an ideal QA tester even exist? Probably not. However, here are the QA skills commonly shared by great QA testers:
- Database skills – the ability to check or extract data from databases without anyone’s help
- Coding skills – understanding source code and looking for edge cases more efficiently
- The ability to write automation tests using Geb or RestAssured which allow the tester to assess the user interface as well as the API
- The ability to look through logs, or even use SSH to log in to a server, analyze changes in code, and find the reason why the error occurs. That is not to say testers should be able to analyze problems with transactions or race-condition issues. Still, being able to find a missing exclamation mark in the if statement is definitely a benefit
- The ability to run a business analysis of requirements or perhaps even take responsibility for them
Do monkeys have QA skills?
I’ve heard mixed opinions about the role of manual testers. Some people believe the role could easily be filled by trained monkeys. Others think the job requires a specific set of skills.
Where does the truth lie?
As usual, as with all IT-related things, in the middle.
Some people think that testing can be carried out by your average app users. They believe that hiring 20 junior testers is just as good as using Amazon Mechanical Turk. The question is, can “random” clicking through an app to find problems be effective? I really doubt that. Although it can cover positive paths (as this is how most people use apps), some serious mistakes will likely remain undetected. We could very well ask our kids to do that, right?
QA skills in action
A good QA tester has great, very specific analytical skills. Good testers are inquisitive and look for problems, or nitpick, if you like.
Currently, analysts usually don’t get involved in IT projects. For that reason, some of their responsibilities have been taken over by testers. That’s because QA skills involve being inquisitive about requirements and questioning them all the time.
Let me explain this using a hypothetical conversation between a QA tester, a customer, and a software developer. When looking at a simple requirement, say “free delivery when ordering 5 books,” the software developer sees a simple “if” statement. If the number of books equals 5 or more, set delivery cost to 0. End of story.
A good tester is likely to say: “That’s a very short requirement. It doesn’t even cover most of the scenarios.” And then they start asking uncomfortable questions.
TESTER: “What if only 2 of the books ordered are currently in stock? And the remaining three will be sent in a second parcel? Are both parcels eligible for free delivery?”
CUSTOMER: “Erm, no. A total of five books has to be delivered in one parcel.”
SOFTWARE DEVELOPER: “That’s another “if” right there.”
TESTER: “What if I order a dishwasher and five books? Does my order qualify for free delivery?”
CUSTOMER: “No, of course not. The offer is only valid if you’re ordering books.”
SOFTWARE DEVELOPER: “Excuse me, that’s another ‘if’”
TESTER: “What if I get 4 ebooks and one book?”
CUSTOMER: “The offer is only valid for printed books.”
SOFTWARE DEVELOPER: “I think we might need to do the estimations again.”
As you see, the QA testers and software developers have different mindsets and different skill sets. For that reason, it’s impossible for developers to take over QA in entirety.
Will computers take over QA testing?
It now takes next to no time to go from building a package to taking it to production, as little as a 15 to 60 minutes. This practically rules out a manual quality assessment. In the past, testing large projects took weeks. There’s no way to compress that into a couple of hours unless testing is automated.
How can computers help with testing? Well, all regression tests are repetitive and when it comes to repetitive tasks, computers come with their own benefits. They’re fast, reliable, and consistent. They don’t make mistakes. After all, to err is to be human, right?
Machines don’t have bad days. And they’re never hungover. It’s also easier to estimate how long it will take them to complete a task.
Who should build automated tests?
Automating testing really is the way forward. Therefore, the right question to ask at this point is who should build automated tests? I believe they should be built by testers who have both QA skills and at least basic coding skills, with an emphasis on the former.
In fact, this desirable skill set usually follows a common career path:
Manual tester -> Automation tester -> Software developer
The shift towards software development is often caused by burnout or salary dissatisfaction (which is slowly becoming less of an issue as employers are starting to value good test engineers). That said, I believe the first transition from manual to automated testing is mandatory.
Many testers are able to write queries for relational and non-relational databases. The next step is to learn basic coding skills. There are a number of resources which allow people to learn Python, Java or Groovy. There are free and paid courses, tutorials, conference presentations, books, ebooks… You name it.
Creating a comfortable acceptance testing framework for a project requires many more skills and much more experience than you need to write scenarios with it. Great testers keep learning to expand their perspective and are also naturally inquisitive. This makes them the best people to build the frameworks. It’s that unique combination of skills and qualities which makes them so valuable.
Without a doubt, automation will take over some of the work of QA testers. The important thing though is it will complement humans, not become a substitute for them. In essence, it will free testers so that they can focus on the human (creative) part of the job. This way, they can focus on the overall product quality rather than “just” remove bugs.
Testing QA skills
Tests assessing QA skills are based on a simple principle – the candidates get a fully functional system with a set of business requirements. They need to write tests to prove that the system meets all of these requirements. We then check that those tests are able to catch all potential bugs introduced to the system.
If you want to start testing QA skills, I have great news for you. We’ve just released our tests assessing QA skills. You can find them below and in our coding test catalog:
- テストされたスキル
- 期間
- 85 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 .NET, .NET Core, ML.NET, 品質保証, テスト, 単位, エヌユニット
コードギャップ
の知識を評価する。 エヌユニット, 品質保証
プログラミング・タスク - レベルミディアム
QA | .NET | NUnit | ドキュメント管理システムAPIのテスト - ドキュメント管理システムのドキュメントAPIのビジネス要件をチェックするNUnitテストを実装する。
- テストされたスキル
- 期間
- 64 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 JUnit, 品質保証
コードギャップ
の知識を評価する。 JUnit, JUnit4, 品質保証, JUnit 5, ジャワ
プログラミング・タスク - レベルミディアム
QA｜JUnit｜ATMサービス｜認証・入金検証 - ATM（現金自動預け払い機）ソフトウェアを検証するためのテストケースを作成します。
- テストされたスキル
- 期間
- 66 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 品質保証, テスト, 単体テスト, 手動テスト
コードギャップ
の知識を評価する。 JUnit 5, ジャワ, 品質保証
プログラミング・タスク - レベルミディアム
QA｜JUnit｜ATMサービス｜認証と入金検証
- テストされたスキル
- 期間
- 36 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 .NET, エヌユニット, 品質保証
コードギャップ
の知識を評価する。 エヌユニット, 品質保証
プログラミングタスク - レベル：簡単
QA、.NET、NUnit、コーヒーマシーンソフトウェアのユニットテスト。
NUnitExercise.Tests/CandidateTests.csクラスを検証する。コーヒーマシン・メインクラスである。
- テストされたスキル
- 期間
- 48 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 品質保証, セレン, .NET, C#
コードギャップ
の知識を評価する。 ジャワ, 品質保証, セレン
プログラミング・タスク - レベルミディアム
QA | .NET, Selenium | データ抽出 - すべてのテストを成功させるために、SeleniumTask.SeleniumExecutor クラスのメソッドを実装します。
- テストされたスキル
- 期間
- 51 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 .NET, エヌユニット, 品質保証
コードギャップ
の知識を評価する。 エヌユニット, 品質保証
プログラミング・タスク - レベル: ハード
QA | .NET, NUnit | Eメールサービスのユニットテスト - Eメールサービスクラスを検証するために、NUnitExercise.Tests/CandidateTests.csクラスにテストを記述します。
- テストされたスキル
- 期間
- 52 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 .NET, 品質保証, エヌユニット, テスト, C#, セレン
コードギャップ
の知識を評価する。 品質保証, .NET, エヌユニット
プログラミング・タスク - レベル: ハード
QA｜.NET、NUnit｜ビジネス・データ・ジェネレーター・インターフェイス - ビジネス・データ・ジェネレーターのためのNUnitテストを実装する。
IDataProcessingインターフェースをNUnitDataProcessing.Tests.DataProcessingTestビジネス要件を検証するプロジェクト。
- テストされたスキル
- 期間
- 73 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 ジャワ そして 品質保証
コードギャップ
の知識を評価する。 ジャワ そして 品質保証
プログラミング・タスク - レベルミディアム
QA | Java, JUnit | 自動販売機 - 自動販売機の検証のためのユニットテストを書く。
- テストされたスキル
- 期間
- 39 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 ジャワ
コードギャップ
の知識を評価する。 JUnit 5, ジャワ, 品質保証
プログラミング・タスク - レベルミディアム
Java｜JUnit｜フライトマネージャー - フライトデータを管理するアプリケーションに不足している機能を実装します。
- テストされたスキル
- 期間
- 81 分以内。
- 評価
- 自動
- テスト概要
-
選択問題
の知識を評価する。 品質保証, .NET, C#, セレン
コードギャップ
の知識を評価する。 品質保証 .NET, C#, セレン
プログラミング・タスク - レベル: ハード
QA｜.NET｜Selenium、C#、JavaScript｜ホームページテスト - C#を使用したSeleniumからのCookieとJavaScriptメソッドのテスト、およびSeleniumからのブラウザタブのチェックに関する知識に基づいたソリューションを実装します。
When you narrow down the number of candidates you have, you can drill deeper into their skills sets in a skills assessment interview.
TLDR
Are QA testers going extinct? Absolutely not.
Do they need to change to survive? They definitely do.
Can the average software developer substitute for a QA tester? I really doubt that.
What are your thoughts?
