QA Team Formation Wins The Game!

ZAPTEST helps enterprises to achieve testing goals either for testing formal way (Waterfall) in COE or Agile in DevOps …

 

QA Team Formation 2

 

Reality

Organization of the software testing process is the key to productivity of any QA practice in today’s Enterprise. Many organizations are lacking productivity due to the poor organization during consideration of their application development structure, change management and skills of their personnel.

Problem       

Lack of productivity in testing departments leads to the poor quality of software that result in the loss of company revenues. This leads to companies downsizing and playing it safe by outsourcing their testing to dev teams that are not quality assurance oriented. As a result, enterprises are still NOT achieving desired results in the quality of their software.

Solution

One of the keys to successful QA practice is the right organization of testing processes. Like in Football, the right team formations lead to winning the game, QA leaders have to understand what formation of their teams will suit their play the best. There are many different combinations of the team formation, but I’d like to talk about the 2 most fundamental ones.

Don't Write Test Documentation!

 

ZAPDOC man in chair

 

ZAPDOC allows QA professionals to create test documentation … with just one click!

Reality

Test Documentation development is the essential phase of any Quality Assurance process.  For many Enterprises having test documentation is imperative in order to comply with various regulations. Enterprises are spending approximately 30% of overall time creating new written test cases and maintaining existing ones when application requirements, or test objectives change.

Problem

Development and maintenance of test documentation is very time consuming and expensive, an initiative that involves greater headcount in the organization. This is becoming a problem for test automation processes where personnel that create test documentation and where the test automation teams are members of different groups don’t have clear and direct reporting.  Pretty often there are times that test documentation developed with manual testing in mind has to be updated in order to correlate with test automation objectives, and to represent test automation coverage. This correlation discrepancy increases when test automation scripts are being updated due to architectural changes, but test documentation remains unchanged since there is not enough time or it has been lost in the change management communication.

Another problem is ability of QA engineers to support Agile development in DevOps where they usually have fewer resources (one-man-show). QA in DevOps do not have enough time to develop proper test documentation, automate test cases and execute them. Not to mention that Agile development presumes rapid change in the application functionality that has to be reflected in the test coverage. Considering that the test automation is the higher priority, in order to save time, engineers often skip test documentation development altogether.

"Show me the Money!" / Test Automation ROI

As you can see with ZAPTEST used by just one engineer Execs will increase test automation ROI 3 times (i.e. $16,800 vs. $50,400)!

 ROI

Reality

Software test automation is an expensive initiative that involves specific skills and technologies that result in high investments in the tools and man-hours. Many organizations are reluctant to invest, due to lack of experience, bad past experience, and/or more often lack of measured ROI of test automation processes. Many IT executives [Execs] prefer to use low cost or open source test automation technologies [Tools] and are engaging consultants, who are promising these Execs test automation heaven at the lesser investment.

Problem

In many cases test automation processes in these organizations are failing due to budget overages and low ROI. The main reason for this budget overage and low ROI is that the selected Tools require more man-hours to implement and to deliver testing results, therefore test scripts development; maintenance and execution are becoming unbearable overhead even at the lower hourly rates.

Test Automation Spider-man in the Matrix - ZAPTEST Fairytale

ZAP MULTIRUN gives Test Automation Spider-man the Matrix super power to make sure that all application test environments are properly tested with one execution!

ZAP Multirun1

Fairytale

In EUT-city there was only one building and the legendary Old-Runner was running stairs making sure there were no Bad-Villains disturbing tenants and destroying the building. Old-Runner was great at running around this building only in  EUT-city. He knew every single stair and every room to precise detail of this building only in EUT-city. 

However, the Mayor of EUT-city, in order to compete with other cities and to attract more residents into EUT-city, started to build more buildings with modern layouts and new stairs. The Bad-Villains started to populate the new buildings in EUT-city because Old-Runner didn’t have enough time to run around all the buildings by running stairs. New buildings had unique and complicated layouts, making it difficult and timely for Old-Runner to learn all of the layouts while looking for the Bad-Villains.

DevOps - 100% QA Time

Blog Image Continuous Integration

 

This approach allows the QA to have 100% QA time (vs 20%) and to always be ready for testing Just in Time (JIT) when the AUT is released. 

 

Reality

The Software Quality Assurance role in the current development process has been demoted due to the fact that QA engineers (QAs) are very late with the testing within time aggressive development cycles. Many DevOps teams are using short iteration dev cycles (2 or 4 weeks), overall QA time in the cycle is ~20%, and within this time QAs have to develop test cases, automate them, and of course to run it at least once in order to find defects (bugs). Not to mention that definition of Regression testing is to verify that found defects have been fixed and are not reproducing new ones, and therefore in the good testing processes Regression testing phase usually is when QAs are going back and forth with developers on the bug fixes. But those good days are fading, because teams don’t have time. Developers would rather do testing themselves…
 
Risk

Let’s step back and look at the global picture. Testing is inevitable for any modern organization that would like to communicate with their customers through software. Software is designed to meet business and end-user requirements. Software Quality Assurance as part of SDLC was established about 20 years ago in order to make sure that software developers implement application requirements as defined. And therefore the QA role is to police developers and to advocate end-user (business) interests. There are many methodologies and theories of software quality engineering that have been developed for the purpose of assuring that the end-user will get software that adheres to business requirements and functioning as expected. In the situation where developers are doing most of the testing, using unit testing (verifying mechanics of the software) organizations are risking overall quality…

Page 2 of 11

Contact Us

Tower Place 100

3340 Peachtree Rd NE #1800 

Atlanta, GA 30326 USA

(404) 814-5227