18

I noticed that when you start on a project with a beginner mind (for that particular product) you have a fresh approach and start noticing a lot of bugs.

After a while and some experience with that product you stop noticing many new bugs and start being habituated with the product and eventually noticing less and less faults. And I think this "effect" could affect everything from API testing, automation to making an all-encompassing test plan.

What would be the best approach to stop this psychological mechanism and obtain a "fresh mind" approach on the product?

9 Answers 9

11

You could setup personas which are designed around real world of users. We have found this quite useful and it really helps to provide a fresh perspective e.g.

Today I'm going to be Andy, the super user of the system. Andy is very sharp with numbers and is the user that is responsible for the administration of the system. He enjoys watching sports on the weekend and long walks on the beach with his dogs. He likes to dabble in some code on the weekend as well.

Some additional reading:

Personas: Theory & Practice - Microsoft Research

10

Being QA Manager with about 3 years of experience, I just give my team mates testing tasks, which are NOT related to software, e.g.:

  1. Compose test cases for blender / vacuum cleaner / etc. - any kind of familiar device / equipment. This results in brain refreshing, and for the cost of 2-4 hours I get team "reloaded"))
  2. The same is applicable for testing such things: office IP phone, coffee machine, etc. Actually, they find some bugs - coffee machine supplier was happy to know and fix them and even once provide "free coffee weeks" as bonus!)
  3. Swap workers between projects for a while works the same way - routine change matters here.

One may continue the list, but the idea is here. Hope that was helpful!

2
  • 1
    Testing coffee machine is a really nice trick)
    – Ksenia
    Commented Feb 27, 2013 at 21:56
  • @Ksenia ;) all brilliant things are way too simple)
    – Peter L.
    Commented Mar 1, 2013 at 16:16
7

I think the simple answer is, do something else for a while. Our jobs require a lot of repetition, and we automatically develop habits in response to repetition. That behavior is a deeply ingrained survival technique; habits allow us to do things quickly without thinking them through. Sometimes those habits allow us to discover new things, but other times they prevent us from questioning assumptions.

Swapping assignments is one way to break those habits. It can also help to do something that isn't technical when you aren't working: read a novel, or get some exercise, or socialize with some people in a way that doesn't involve talking about your job.

7

You could try the 'tours' concept and try out different tours of the software.

I'd also disagree somewhat with your premise - the more you use a program the more you notice any slight changes. You also understand more how all the parts interact which in turn gives more ideas. I think at the start you may notice more but they are shallower than ones you find as you understand more

5

Maybe an indirect answer, but one way would be to get actual fresh minds. This is the idea behind usability testing, bug bashes, alphas, private and public betas, etc. Another idea would be to rotate from a staffing perspective to different products/features.

3

One approach is to actively recruit team members and other stakeholders for testing of the product. I have found that it is useful to try different approaches and use whatever works best with each person, which can include:

  • Paired testing with a code developer (emphasize the thrill of having a function work on the first build :) )
  • Asking a content developer to independently look at some new admin functions because it could affect their job. Prompt them to suggest changes that could make the function easier.
  • Contact the product manager and ask her to take a quick look at a function because there might be some confusion on business rules.
  • Contact a user that complained about a function and go through the proposed changes on the phone. Many times, users would be thrilled to have input to the change process.

And it goes on ... Note that the key skill is to inspire passion in the people you recruit. That approach keeps testing fresh and inspires the entire team to produce a quality product.

1
  • As a developer myself, I just sat in on a two day session where users flew in from all over the country to test (and break!) my code. I had my laptop and was firing off bug fixes left and right. My wife thought it was a punishment and it would make me look bad because of all the bugs. I said "Honey, most people aren't lucky enough to get this. All these bugs would have got found, I got to find them before they went live." I can't upvote enough the benefit of pairing a tester and developer together for a few hours! Both gain an appreciation for the other.
    – corsiKa
    Commented Feb 27, 2013 at 23:01
1

You could also change your testing approach.

In my experience, 90% of time spent testing is Exploratory. this tends to get dull and repetitive. What I then started doing was changing my point of view or testing strategy.

Try something in the lines of BVA. (Boundary Value Analysis). Obviously certain test strategies wont work on all types of software. It won't help using BVA on a website for instance that does not make use of any currencies, dates, times, and things like that. , so do some research into testing methods. (If you Google Rex Black, You are sure to find some interesting info on testing and aspects of.)

Another option, and one that I am fortunate to make use of, is actually viewing how the end user uses the software. All our software is built for in-house use. Simply seeing how one person uses the software vs. another opens up a world of testing possibilities.

5
  • 1
    I must admit I am confused when you say Exploratory is boring ? Why can't BVA be part if that ? ( answer - it is ) same with end user testing, isn't that part of an exploratory approach ? Commented Feb 26, 2013 at 12:43
  • 1
    @PhilKirkham I did not mean Boring in that sense. Exploratory testing like previously stated, is highly effective when you have new blood in the team, but the more you work with a product, the more specialized it becomes. To the point where exploratory is in fact regression. Either way, Human nature has proven to me that the more detailed things are, the better, but you tend to forget legacy... Correct me if I'm wrong, please..
    – Kamakazy
    Commented Feb 26, 2013 at 13:02
  • 2
    Doesn't tie in with my experience or ideas about exploratory testing at all, hence my comment Commented Feb 26, 2013 at 13:39
  • 2
    @Kamakazy I agree with Phil, I think what you're thinking of as exploratory testing is wildly at odds with how the rest of the community uses that term. You did ask for correction so I'd suggest you start reading here: kaner.com/?p=46 and then take a look at testingeducation.org/BBST . Cem Kaner coined the term 30 years ago, so go to the source! :) Enjoy, there's some great stuff in there.
    – testerab
    Commented Feb 27, 2013 at 10:49
  • @testerab Great stuff, thanx for the reading material..
    – Kamakazy
    Commented Feb 27, 2013 at 11:41
1

In my view as a Test Engineer - I have to be more detailed oriented with requirements and clear in understanding of product vision, goal & business values.

Psychological - keeping mind fresh is more important task for tester, I suggest you follow this idea:

  1. Think a product in 3D view, you view more dimensions. (3D can be any new dimensions)

    • (Short Term Product Goal, Medium Product Term Goal, Product Long Term Goal)
    • (Product, Product Clients, Product Services)
    • (Old UI/UX, Current UI/UX, New possible UI/UX)
  2. Do some research in online about similar product or clone product & use them (you may get new idea).

  3. Divide the all product in smaller parts while testing, so you cover all parts in automation or manual testing.

1

This is called The Hallway Test. Also curse of knowledge. In short: you cant. You ask the cleaning lady* to try to use your software. Or a colleague from a different team.

In role playing games there's such a concept; it can be trained over only several years of hard training. To some degree. Just ask the cleaning lady.

* - she is not getting payed for this - at the very least buy her a lunch. Although the cost of that dwarfs the value she is producing by having a look at it!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.