How do you manage errors in your Test Specifications & I messed up

🗄️ Archive
1

Hello, Hope you’re doing great today.

Any thoughts on managing and also coping mentally with making mistakes when writing your Test Specifications?

Usually writing Test Specifications is one of my strenghts but Im making a million mistakes at my new job. I think that the reasons for this are these:

  • Tests come from requirements that arent specific and still open.
  • No manuals or guides to use the tools.
  • No information about how the system works.
  • The developer is always busy and there is a terribly, terribly tight schedule for all testing activities.
  • No other projects have Test Specifications that I could use as reference.

I looked horribly in front of my manager because we reviewed the TS today and everything was going fine until we got to a couple of huge errors that pointed out that I dont know how that area works (I had created my own theory of how it worked and it was not like that).

In my defense, I’ve been asking for a review of the requirements and the TS review for months. At the end I told them I was not going to record the results until there was a peer and lead review.

I would really appretiate your thoughts!

2 Likes
2

I think you mentioned it yourself

And this:

This is a No-Go zone for me. It reminds me of:

neverAssume

When you don’t know what it’s supposed to do, don’t assume what it’s supposed to do, just ask.
Testing is about facts and expected results. We can’t test if we don’t know what the end result should be.

I get that developers are always busy and are not interested in guiding or talking about testing but just book a meeting. Try force them because how else can you do your job?

Keep in mind that messing up is a human thing, it’s normal and everyone does it. Learn from it and adapt to your environment. Like you asked for reviews of the TS, that’s good but make sure people do it. If nobody does it, perhaps mention it at the retrospectives if you have those? Or tell them you are blocked until somebody reviews it.

It kind of sounds like a bad environment where everybody blames other team-members? – “without being a real team”. So make sure you do your part and cover yourself as much as possible. Kind of weird advice but just making sure you don’t get the blame for trying to do your job … if all hope is lost … :smiley:

2 Likes
3

I understand where you are coming from, but personally I do a lot of testing where I don’t know what the end result should be. It happens to also be in those areas that I tend to find a lot of “bugs” in the form of “wrong” or “incomplete” assumptions made by the development team.
There is, however, one condition for that kind of testing: you cannot make assumptions about the expected results, so you have to use something else.
In Rapid Software Testing, I learned I could use heuristics for that: fallible methods that might be useful for providing information, for instance to determine whether an actual result was correct or not. Note the word “fallible”: heuristics are useful, but not always “correct”.
An example:

  • You can test input fields in the user interface, and see if they can accept “normal” input, long strings, a copy/paste of a document, a numeric value, a numeric value expressed in hexadecimal, …
  • If any of those values you try make you go, “huh, strange”, or “huh, I didn’t know what to expect but it certainly wasn’t this”, you can show these results to the development team and ask them if that might be a problem
  • If the development team cannot help, you use heuristics. For instance “an old version of the application does it differently”, or “I, as a human, will not expect a number to be expressed in hexadecimal”. Remember: these heuristics might give you the wrong conclusion, but they might give you a better story to tell your development team when you try to determine whether something is a bug or not.
  • Each of those tests will inform you which other tests might be useful
  • You can even try to get the team to do something with your actual results, like documenting them as acceptance criteria, for any future reference where someone might have to retest this

References:

1 Like
4

If you got any experience I’d start searching for better opportunities, if you’re still learning the trade (less than one year of working) it might be good to stick around just for a little while so your resume gets you past recruiters and HR more easily, work experience has a magical effect on them.

1 Like