The Future of Software QA and Test Automation

According to Tricentis, this is the current state of test automation.

Most software testing right now is done by manual testers, while automation represents no more than 30% of testing. 

Also notice that of the automated testing done, the vast majority of it is UI testing. 

By definition, automation engineers design test frameworks and are skilled developers. They automate, maintain and run test cases. Manual testers also define test cases but execute them manually. They identify the required test data objects and also do a fair amount of exploratory testing.

Enterprise companies are continuing to increase the amount of automated testing done to keep up with market demand for quality software delivered quickly. As this evolution takes place, manual testers will run out of tests to execute. These manual testers will learn to automate. As they encroach into the space of their senior automation cohorts, automation engineers will evolve as well. 

What do you think about this illustration of the future allocation of manual, automated UI and API testing. Do you agree that this is the direction we're going? The direction we must go? 

In terms of job roles and responsibility, should developers divide their attention between production code and building an automation framework? I agree with Tricentis' statement:

Testing will not become a developer's discipline because it simply can't. You may be aware of how hard it is to find suitable software developer talent these days. The sheer number of developers that would be required for Continuous Testing simply does not exist on the market. Not to mention that software developers themselves are not usually too fond of testing. If we were to ask software developers to do 85% of the testing, the testing would either never happen, or distract developers of their primary job - which is to innovate.

Talk about job security! If you're in the fields of QA and software development - and you continue to build on your skills - you will always have a rewarding career (read: a secure, well-paid job). 

In this last illustration presented by Tricentis, you can see that the future testing team will still be comprised of manual testers. Former manual testers will have an opportunity to become Automation Specialists, while Automation Engineers will be the necessary developers that focus on Service Virtualization, writing the underlying complex code necessary for Automation Specialists to ramp up quickly. 

One of the most popular test automation design patterns, the page object model, is a great example of one of the disciplines I think will be necessary for the model defined above to work. With it, the complex logic is abstracted away from the tests to make them easier to read, understand, write and debug by eager Automation Specialists.

Thank you for reading. And thank you Tricentis for this whitepaper. If you'd like a copy, you can get request one here (I am not affiliated with Tricentis).

The Case for Writing Protractor Tests in TypeScript

If you're reading this not too long after I decided to start this project (January 2016), you may have realized this is a lonely road. A quick Google search of "protractor typescript" pulls up very few relevant results. You'll see this blog, TypeScript-Protractor, one or two other blogs (like this and this one in German), and some Stack Overflow posts. You'll find type definitions on the DefinitelyTyped repo linked on NuGet and others. That's pretty much it. If you look up TypeScript in the Protractor issue search on Github, you'll see Julie Ralph (Protractor team lead dev) has TypeScript (TS) on her radar. She's not looking to rewrite Protractor in TS but she thinks including definition files in the package is a high priority. It still makes me wonder if there's a good reason not many are doing it and talking about it. It seems like the TypeScript-Angular is a thing, so I ask myself what makes e2e Angular testing any different. 

Then why the heck am I doing this? 

1. TypeScript is the language of choice on the development team I'm on so e2e test development in TS would be consistent with their production code.

2. TypeScript prevents trivial errors, makes code more readable, and at compile time will help find simple bugs that might otherwise slip through or be hard to find with a stacktrace alone. 

3. I already know what types variables are supposed to be and I know what types functions should return so I might as well put it in the code, right? How hard could this really be?

4. It's new, uncharted territory - at least from my e2e testing perspective. Writing in TS would be a challenge for me because it's new. I'm forced to figure it out the protractor-typescript link on my own. I used to hate strong types because I felt like it was slowing me down, but I think maybe I just need to grow up. 

5. No one that I know of suggests otherwise. I have the definition files and I've been tasked to create a reliable automated e2e testing framework in a reasonable amount of time - from scratch. If that were not the case - like if I had a framework already established - I might not pursue this. 

This might end up being an utter failure. I might never write in this blog again. It could be a hassle, take too much time. I might lose motivation. I might need the speed and community support of javascript. Who knows. 

However long or short the journey, thanks for reading and riding along.

And please comment!

This is my first post...

Hopefully more to come!