Falsehoods testers believe?

Recently there was a discussion about Falsehoods Programmers Believe, there’s even a GitHub repo.

One of my favourites is “Street addresses contain street names”. I recently had an experience where the piece of software didn’t allow you to alter the country you lived in so e.g. I’ve lived in the UK for over 4 years but previous to that I lived in Ireland. Ireland doesn’t really use postcodes or street names once you get outside of the towns so the format of my previous address didn’t match the expected format of the software. I couldn’t adjust the country in the hopes it would then make these fields not required, a previous address was required so I just had to abandon the software.

The conversation got me thinking, are there falsehoods that testers believe? Maybe you previously believed a falsehood but now you don’t, would you be willing to share that?

I previously believed that security testing should be done by a security tester, performance testing should be done by a performance tester, etc. That’s fine in certain situations but not all. I soon learned that as a lone tester you pretty much have to cover those areas yourself and then contract some of the bigger stuff out if you can.

3 Likes

“Developers can’t test” is definitely a falsehood that many testers seem to believe

9 Likes

A few I’ve run into, and some I’ve learned better about myself:

  • There are best practices that apply in all situations. (It doesn’t take much thought to see where this one falls apart)
  • You need specifications or use cases to be able to test something. (You don’t. Your testing won’t be as effective without them, but you can use common sense and the application itself as implicit specifications.)
  • You can test everything completely.
  • You can automate all your tests.
  • You need to be able to write automation to be a good tester. (there is so much wrong with this I don’t know where to even start)
  • Any statement about testing containing the words “tester(s) must”.
7 Likes

I’ve been hit by assumptions about previous addresses, etc, too, having lived out of the UK for 5 years. Generally, it’s on insurance quote forms you get questions from different companies that are supposed to mean the same thing but don’t:

Have you lived in the UK since birth?

Well, yes, but … isn’t usually an option

When did you first enter the UK?

Well, 1975, but what do you really mean here?

So I generally try and answer such questions truthfully but in a way that is likely to get me a cheaper quote :wink:

2 Likes

I blogged about it some time ago but related to the Name field.

http://www.gustavorivera.com.mx/index.php/blog/32-field-validations-more-specific-name-field-validations

2 Likes

That the world is populated with objects and concepts and models and systems that have intrinsic borders and properties rather than these things being dependant on our inventing the world rather than discovering it.

2 Likes

The “given” section of a gherkin feature file must include every single step to reproduce it starting from turning the computer on

A bug report needs to include every single step to reproduce it starting from turning the computer on

A bug report must always be filed if you saw a weird thing happen just once

A bug report should NOT be filed if you saw a weird thing happen just once

X wasn’t written down in the signed-off requirements therefore it isn’t a bug

6 Likes

Testers need attention to detail

False - testers need to be aware (spatially and otherwise) - attention to detail is less relevant if you can just see that something is different- you have time to work out what

3 Likes

Off the top of my head:

  • “We’ll make sure you have plenty of time to test next sprint.”
  • The tests written according to the original acceptance criteria will be valid when the product is ready for testing
  • Testing can wait until the whole feature has been developed.
  • There is no point in respecting developers. They cause all of the problems.
3 Likes
  • You have to test everything
  • You make the release decision
  • You can’t release something without testing it
3 Likes

Some teters believe that everything can/should be automated

3 Likes

Hopefully Developers can test, especially at the unit level. Unit testing, by definition, are tests written by and run by Developers (although it’s common in the U.S. to see Tester job description wanting them to write unit tests).

Developers may be able to test at a higher level, but it’s definitely a different mindset than testing. If a Developer tries to test their own code, this will typically be ineffective, as it’s like proofreading your own work. You skim over things and miss them.

To see how well Devs test, you can look at the defects logged by testers. That would be an objective way to measure the effectiveness of their testing.

1 Like
  • Testing improves the quality of the product
  • It’s possible to be finished with testing
  • It is possible to test everything
  • Requirements are never ambiguous
4 Likes

Testers are the goalkeepers. If a serious defect reaches production it’s all our fault and we’re useless.

100% requirements test coverage is the same as 100% quality.

The future is that all testing everywhere will be automated and all manual testers will be unemployable.

5 Likes
  • Developers create bugs
  • Developers don’t like testers
  • Tests never contain bugs
  • Testers don’t make mistakes
1 Like

This is a good pair! Knowing whether something is (or might one day be) significant or not can be a real test of how well you understand what you’re working on. I’ll add another similar one that I’ve seen in action before:

  • If that weird thing happens every time, it’s probably supposed to do that
2 Likes

These are falsehoods about testing that business managers believe :angry:

1 Like

“If that weird thing happens every time, it’s probably supposed to do that” - then isn’t it a tester’s job to challenge that, either with the product owner (“Is it really supposed to do that?”) or with the business (“I’ve noticed the app does this weird thing. The devs say it’s supposed to. Do you agree? Is that a problem for you?”); or even to follow it up with someone else, such as the UX designer or the technical author (“The wiki needs a section that says 'If you see it do this, don’t panic - it’s supposed to…”)?

Absolutely! But I have seen testers – especially junior testers working on an unfamiliar product – believe that.

2 Likes