“High” in Software Testing

My first exposure in software testing was through a diploma course in computer science. Then, fresh from Java Bootcamp in one of the IT Consultancy firms in Manila, the first project that I was involved with was a Maintenance project — meaning the system is already working/deployed, it’s just the releases that the team had to “maintain”.

The team will receive change requests from clients which the dev would work on and the testers will test. The team’s requirements “documentation” is the same as the team’s test case. Columns were added by the tester to track the status of each test phase e.g. UT1, UT2, QA1, QA2, Dev , Pre-Prod, and lastly the Prod environment. It was never explorative, we had to follow the test case thus I was a Tester.

Next project, as a Test Analyst for a big retail company in the U.S. It was a server migration project but we were limited in testing due to privacy concerns of the company. Medical and client information confidentialities were in place. That project was more of a Test Coordinator and Test Case creator role. The analysis part came into application by looking into all possible dependencies during server and application start ups. We had to track the servers that were decommisioned and work with the infrastructure team to make sure that the servers were in place before the application testing proceeds.

The exploratory testing experience, which was the best one, happened here in Sydney. This is for a website creation and testing project. I created the website using Kentico and implemented the testing based from the test case that the U.K. counterpart has provided. At first, I was unsure of testing outside of the test case. But, as other testers in the U.K. are logging bugs that cannot be expected from the test case I gained the courage to do the same. I had to think how a customer would use a cart and from there I started uncovering bugs depending on how I think a user would behave.

IT WAS AMAZING.

As a developer, you get a thrill when finally the code works! And then, you move on to the next requirement then again you are on a roller coaster ride. With software testing, the high of the experience happens when you see a bug in camouflage!

It’s like discovering an island! EUREKA!

However, there might be boring instances when you are limited to a test case that you did not create. I think this is where automated testing can be beneficial. Multiple testing iterations without a fresh eye to check or feeling boxed on testing is not really efficient.

Efficient and successful Software Testing for me requires business knowledge, application familiarity and know-how, creativity in thinking of what if’s, storytelling, scepticism, inquisitiveness and eye for detail. “Railed-in” imagination and creativity helps.

For example, how would you test a flying AND driverless car? (I’ve been wanting this to become a reality!) First would be to plan. Would the testing be done by a separate team or by the developers as well? Or, we could have both actually. The UT1 and UT2 can be done by the devs and QA1 and QA2 by the Testing Team. Then, after the QA environment, both dev and QA will test on the Pre-Prod env.

Test case creation or none? Agile or Waterfall? Would it be beneficial to have both automated and manual testers? What are the components to be tested? Risk Mitigations? Schedule? Deadlines? Milestones?

ASK. ASK. ASK. What if I do this? What if I do that? That is what software testing is for me.

Then, you will find that your personal life will be affected by it as well. What’s the use of goint to Point A when we could go to Point B? What if Point A is ugly, how can we go to Point B from Point A? Is it worth it? What if there are no cafes in Point B? Haha. Don’t forget to… “rail it in”.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.