With numerous test automation tools and frameworks available today, many in the software testing industry are focused on learning them all. It is important to stay updated with new technology. But are testers losing something in the race to become more technical and equipped with automation skills?
In my article published at TestRail blog, I examine ways to see if your test automation is becoming so technical and code-intensive that it’s in danger of alienating the subject-matter expert testers who best know the core of your business?
Technology should serve people
It is important to understand and remember that test automation tools have been designed to make testers’ lives easier and better. They are not intended to replace testers or overpower them. They make tests execute faster, with more accuracy and fewer errors, so if they eliminate anything, it is redundancy and repetitive work. This technology is meant to serve testers — to save their time and effort and give them more freedom.
To this end, the first intent behind adopting any technology must be its fitness for use in the project, not its popularity in the market. The skills needed to adopt the tool and begin using it in the project should be easily obtained by hands-on learning or training. Read full article ->
Testing is creative
Testing is a creative job, and it always has been. The advent of new tools and technology has not changed this fact. Tools can do part of a tester’s job, but they still cannot test. Although some people may argue on behalf of artificial intelligence and machine learning that can take over many actively creative aspects, we are not there yet. We still want and need a human to capture the creative tests, discuss the pros and cons of design aspects, peer-review test cases, and report problems.
Everyone can contribute to test automation
When we look at testers’ resumes, the tendency is to look for tools they can work with. But the more important skill we need is their ability to contribute to test automation in one way or another. We cannot judge this fact just by asking if a person is able to write test automation scripts or knows a certain programming language. They may be able to learn the Gherkin format to design and write feature files for Cucumber tests. Or if you decide to adopt a keyword-driven framework, they could pick up the keywords and begin writing tests so that the same test cases can double as test scripts.
A look at tests in Quadrant-2 – Business-Facing tests
On an agile project, the customer team and the development team strike up a conversation based on a user story.
Business-facing tests address business requirements. They express requirements based on examples and use a language and format that both the customer and development teams can understand. Examples form the basis of learning the desired behavior of each feature and we use those examples as the basis of our story tests in Quadrant-2
Business-facing tests are also called “customer-facing”,”story”,”customer” and “acceptance” tests. The term ‘acceptance tests’ should not be confused with ‘user acceptance tests’ from Quadrant-3.
The business-facing tests in Q-2 are written for each story before coding started, because they help the team understand what code to write.
Quadrant-1 activities ensure internal quality, maximize team productivity, and minimize technical debt.
Quadrant-2 tests define and verify external quality and help us know when we are done.
The customer tests to drive coding are generally written in executable format, and automated, so that team members can run the tests as often as they like to see if functionality works as desired.
Tests need to include more than the customer’s stated requirements. We need to test for post-conditions, impact on the system as a whole, and integration with other systems. We identify risks and mitigate those with our tests. All of these factors then guide our coding.
The tests need to be written in a way that is comprehensible to a business user yet still executable by the technical team.
Getting requirements right is an area where team members in many different roles can jump in to help.
We often forget about non-functional requirements. Testing for them may be a part of Quadrants 3 and 4, but we still need to write tests to make sure they get done.
There are conditions of satisfaction for the whole team as well as for each feature or story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. They also help identify risky assumptions and increases team’s confidence in writing & correctly estimating tasks needed to complete the story.
A smart incremental approach to writing customer tests that guide development is to start with a “thing-slice” that follows a happy path from one end to the other. (also called a “steel-thread” or “tracer-bullet”). This ‘steel-thread’ connects all of the components together and after it’s solid, more functionality can be added.
After the thin slice is working, we can write customer tests for the next chunk.
It’s a process of “write tests — write code— run tests — learn”
Another goal of customer tests is to identify high-risk areas and make sure code is written to solidify those.
Experiment & find ways your team can balance using up-front detail and keeping focused on the big picture.
Quadrant-2 contains a lot of different types of tests and activities. We need the right tools to facilitate gathering, discussing, and communicating examples and tests.
>>Simple tools such as Paper or Whiteboard work well for gathering examples if the team is co-located.
>>More sophisticated tools help teams write business-facing tests that guide development in an executable, automatable format.
I got a chance to present a talk at the World Test Engineering Summit organised by 1.21GWS @ Bangalore last week and it sure was a great opportunity! My talk title was
“Layers of Test Automation” wherein I presented about test automation framework creation and best practices on creating a sustainable framework. The talk was appreciated and I had great personal feedback and chats with many delegates.
It was amazing to share the stage with renowned speakers like Mrs. Renu Rajini, Mr. Mostafa Awadh from Egypt, Shivaji Raju , Sanjay Kumar and many more.
My team at Sahi Pro also decided to partner with the event and setup a demo booth, where my colleagues Pratik and Satish showcased an informative demo of Sahi Pro tool and all of its awesome capabilities. The Sahi Pro booth was a hit, appreciated by the inquisitive participants. We also held a Quiz for people visiting the booth, and the winners were awarded with fun goodies at the end of the day!
Here is a glimpse into the event-
My Talk —
Sahi Pro Booth–
Felicitation for the Quiz Winners and honoring the organizer Nitin Naveen-
So much fun and networking–
Overall this was a great experience! We would love to collaborate with 1.21GWS again in the upcoming events!