Thread regarding Wells Fargo & Co. layoffs

QA automation craze

Just a word about the QA automation craze if I may... the big push in IT nowadays is to 'automate' testing.

At an earlier job, I automated a keypunch department. Instead of the requesting company sending paper documents, I had them send a flat file with different 'rec' and 'trans' codes which my program translated into which PF keys to hit. I learned the Attachmate Now! coding language and it worked fine.

At CVS I was entering data into online screens for regression testing, first for the 'baseline' version, then for the 'changed' version, then running comparators on the output files to verify that only the expected changes occurred.

I suggested that they automate the process, found a contractor who knew QTP, and we worked together to successfully complete the automation, which saved considerable time & money. Certain redundant processing you can automate, but not QA testing in general.

If the automated regression test script just enters data into screens and runs, what does that tell you - not much, except that it didn't abend, so every time you make a code change you are going to write a Java script to test it?

The QA 'automation' testers I worked with didn't know how to code the Java Scripts, they just executed them... manually.

by
| 1385 views | | 3 replies (last October 3, 2022) | Reply
Post ID: @OP+1iYHbx9H

3 replies (most recent on top)

Wells Fargo's idea of an automated regression test is to just run thru a series of screens with test data, wasting time, effort, system resources, and actually getting in the way of manual tasks that sometimes need to be run, ie, Mobius reports.

All they have done is wasted a lot of money.

In stark contrast, batch 'Scheduler' was created many years ago to replace the computer operator task of manually entering each batch job, so it serves a very useful purpose.

by
| | Reply
Post ID: @3yzt+1iYHbx9H

Manual Functional and Regression Automation is the best proven methods of testing. But industry is going towards removing the QA resources, so every software engineer/developer expected to develop/test/automate/unit test/sit test/regression test/performance test/maintain test suites/fix issues and so on...the list goes on.

This experiment is already failing. Developers are reluctant/frustrated to test, managers unable to buy a license for each and every person. Exceedingly idealistic; unrealistic and impractical quixotic situation. I think, it is not a great decision and pretty soon they will bring back QA wing.

by
| | Reply
Post ID: @1fgz+1iYHbx9H

I, too, set up test automation in a past life with a different bank. Setting up and managing the automation scripts was nearly a full time job. It was a lot of work, but it was effective for regression testing that gets repeated frequently.

The scripts are only as good as the developers who create them. When the script runs it can only test what it has been programmed to test. There is so much more that good QA resources are looking for. It's subjective/intuitive stuff that you only experience when you're in the middle of testing: "Something doesn't feel right." Then you research it, and you often find a defect.

If we go all in with automated testing, I hope the people making the decisions have some hands-on experience with automation.

by
| | Reply
Post ID: @gfy+1iYHbx9H

Post a reply

: