Tag Archives: testing time

Help Us Make Sure We Are Ready To Go Live

We are due for the project release very soon. Why do we need to fix this bug?

If the computation’s all wrong, if our clients will be redirected to a wrong page or if they can’t do an action on a control, if the page itself does not load or if there are security loopholes, then by all mean we need to fix those issues immediately. Right now, in fact. Our programmers will even be glad you pointed that out and will be busting their asses as soon as possible to find a solution, no further questions asked (except for the procedure to replicate the error).

But if you tell us to change an element’s alignment, font size or color, if you say to us that we must change an existing copy for one or two scenarios when the existing content actually works fine and we risk breaking the other many scenarios that we have, you’re not helping us do our jobs well. You’re making our heads ache in frustration and then we become more prone to errors because we’re in a bad mood. We know you meant it well when you say that it’ll make the app more beautiful, more pleasing to the eye, but do you really want us to prioritize that issue over maintaining the integrity of the current build when we’re days, hours even, away from the release? Can’t it wait?

Sure, we can make those changes. But please let us do it on a sprint when there’s ample time for proper development and testing, not when we all have our hands full trying to see if everything is working as intended. Help us make sure we are ready to go live, not drown us with bug reports that often we can leave alone for the next cycle.

Do You Need Test Automation?

At this stage of your working career as a software tester, do you feel that the software applications you need to test are becoming more complex after each project release? Are they more time-consuming to test overall now than they were months ago? Have the manual test cases you’ve written before for a specific app functionality increased in number? Do you need to repeatedly test your scenarios in more than one browser? Do you need several days (or weeks) to complete one pass of all your test requirements? I’m talking about testing all non-negotiable software requirements for a successful release, the features that clients frequently use, the things that most need not break.

Do you want your computer to help you go over another round of tests while you sleep soundly?

If you answered Yes to most of these questions, then you need to invest in learning and applying test automation in your software testing toolbox. Your manual testing skills could use some of their help.

About Software Applications And Their Required Regression Testing Time After Each Update

About two years ago, when I was a new software tester in my current company, I started estimating the time I need in performing regression testing on each of the organization’s major products. I wanted to know how much time was enough in order for me to do my tests properly, without rushing and without dilly-dallying, because it helps me prioritize and pace tasks. If asked if I can deliver results after a specified period, I would be able to answer yes or no immediately. If I say I can’t deliver on the initial negotiated time, I would be able to tell my superiors how much more I require to be able to provide the information they want.

For one application, I found out that I have to commit a day, provided that tests are focused, not rushed, without much distraction from everyone else. I got my estimation where I then based all my decisions and made guided expectations. For that product, one day provided enough testing time such that every further project release for that software often went well. There were no troubles in the required testing time. I had no worries in pacing myself well.

That is, until recently. There was a scheduled major release and I told my boss I can finish testing before the deadline but I wasn’t able to, even after giving overtime work. Imagine my surprise: that day, the estimated testing time that I was so sure of looked like it wasn’t enough.

Several days later, I realized two obvious things that I never thought could lead to a disaster in decision-making:

  1. software applications grow in complexity as they continue to be updated, and, because of that,
  2. the regression testing time required for growing applications also needs to increase by a properly factored amount.