Menu Menu
QA role in the team

QA role in the team

Is testing dead?

I was browsing through lots of articles on Internet discussing the role of tester (QA) in some companies. They were discussing if tester is necessary, or if developers can do the job instead. Moreover, they argued if testers can be replaced by automated tools and removed from IT world. Basically, all these articles had very good "for and against" statistic why a company should have a QA team, at least when you are looking at them as statements and letters on paper (in this case: on screen). In some of the blogs I have previously read, Alberto Savoia, who used to work for Google and now is an educator at Stanford University, said that "testing is dead" and that "focus is on building it right at the highest speed". You can imagine how many critical reactions were born in the testing community…

QA in the team

As a QA engineer I daily ask myself if my role is important, if my job is worth. It is possible that you can replace some of my tests by integration or unit tests. Surely, you can use some automated testing tools, maybe you will have to pay the fee for some of the tools, but there are quite a few good ones that are open source. I am using some of them for a few of my test cases, why wouldn't someone just record what's needed and press the button in specific moment… First of all, someone actually needs to create all those tests, think about them, design them properly, and if the tool is used, record them, execute them, report issues… It seems to me that you need a human role in this process. QA is the one who should say when something needs to be tested manually and where additional automated tests should be written (by developer or by QA engineers).

Mistakes can cause serious damage

Let me just share some examples referring to a very expensive mistakes that some companies made by not testing their products. In 1992, Pepsi ran a promotion in the Philippines where customers could win a million pesos (approximately $40,000) if they bought a bottle of Pepsi and found number 349 stamped on the underside of the bottle cap. Unfortunately, due to a software error, 800,000 bottle caps were produced with number 349 instead of one, which was an equivalent of $42 billion in prize money. Cahoot, Abbey National's online bank, was launched June 2000. On its first day of operation, within 90 minutes of trading, the system failed, causing the website to crash. The system could not handle high volume of concurrent users. The registration application and its integration with the network were not fully tested. In 1994, Chemical Bank from New York managed to allow $15 million to be withdrawn incorrectly from 100,000 accounts - a single line error in the program caused every ATM on their network to process the transaction twice.

Test to learn

Conclusion: Testing is necessary because we all make mistakes. Some of those mistakes are unimportant, but some of them are expensive or dangerous.  While finding defects/ bugs is one of the purposes of software testing, it is not the most important purpose.

Why do we test?

A completely valid and logical response is: To see if the software works. However, maybe more challenging (well, for me it is) one is: To prove that developers are wrong. Let me be clear, I am not into "QA vs. developer" thing because, we are members of the same team and I like to think that we have the common goal: delivering quality software to the client, at least because it's our job. Next question is: are we testing just because we are told that we should do that or we are doing our job and trying to get the most of it? The point of a test is not to see if something works but to investigate how it works. What will happen to the application if it is exposed to certain conditions? How it performs in FireFox or Chrome? Does it look the same in Internet Explorer and some other browser? Can it be broken by an intruder? Can it be broken by me…

With each test we should learn more about the software, to confirm or disapprove something about the software. If you have test suit that tells you nothing about the software, ask yourself: Why am I running these tests? If you have a question about software, ask yourself: Why haven't I written those tests yet?Test case numbers don't mean anything by themselves. One needs to look at how much exploratory testing was done and how many bugs were found in it. That gives a much better indication of the quality.

"Testing isn't dead, but Bad Testing should probably die".

I read this at a blog, also. Testing is a practice, it's a skill, and sometimes it looks like an activity that can be done by anybody. However, can anybody test software? No.  I personally don't think so.  It takes someone with a good analytical mind-set, technical knowledge, and an innate drive to find things out, in order to be a really good software tester.

Checking is not testing

The founder of Quality Tree Software Inc, Elisabeth Hendrickson, once said:

"testing = checking + exploring."

Automated tests are kind of "dumb". We write them to check scenarios that we already know about. They run and check whether the system still does what we expect it to do. For example, I was testing an application which had some automated test written by developers. His test passed, mine was failing, and we both tested the same thing. How come the result was not the same? Well, in my test case, I added a specific test step which developer did not had in his mind while he was writing the test. His test was expecting certain result and was written in that manner. Mine was a bit edgy… In one of the blogs Ms Hendrickson wrote, you can find that QA stands for: Quality Assurance, Quality Analyst and Quality Ambassador.

So, we, testers, are not redundant. Test automation means that our role is just more empowered. Automation can take care of the repetitive checking we are often stuck with. And it means that we can free our creativity more to explore the ways to test a system. Testers who adjust their skills and the use of those skills to the context in which they work, only they can smoke out bugs that otherwise would have gotten away and provide information that allows others to make the right decisions. So, if you go to the interview for the job and interviewer asks you: why do they need QA in the company, be free to respond.

"Testing is a craft, as is software development. However, developers and testers have different functions, and according to that the way they work is different. The developer aims to build something. The tester aims to find where that thing may be broken. Those are the two mind-sets. If you don't do any testing, how much will it cost the organization to manage and fix all of the bugs that the customers find?"



Latest blog posts
PyCon Balkan 2019 From a Speaker's Perspective
Coordinator with Closures in iOS Programming
Five Books to Read This Summer
How Team Building Activities Bring Us Closer Together
Coding Dojo 2019: Impressions from the Workshop