Testing Checklists

(Andrew) #1

Hi,

Bit of context here, I am a lone QA Analyst on a team of 13 developers and looking for ways to spread my testing capabilities across the team as easily as possible. We have 2 major web properties that are used primarily for marketing purposes. Both are managed through a in-house content management system (CMS).

Does anyone out there have any exposure to checklists for testing. Specifically the dev team has requested a set of standards and “things to test” when checking in their code so we can reduce the amount of time spent back and forth between pull requests. As an example here are some possible categories of testing I might expect them to cover off before submitting a pull request:

Styling/Content Related

  • Responsiveness Testing (does it display as expected in supported browsers)

Form Tests

  • Error conditions (what values produce an error)
  • Min, Max characters
  • Types of characters allowable

Date Selector

  • Date ranges allowable
  • Specific dates not allowable
  • Responsiveness (does it work in supported browsers)

Does anyone have suggestions on my approach? Do you think a checklist is a good start? Any categories you think are a must for a checklist?

Any help would be greatly appreciated.

Thanks
Andrew

0 Likes

(Ola) #2

Hello Andrew,

I have not tried checklists for involving developers in testing. My go to approach have instead been testing tours.I have found them to be a good way to divide the test effort and to help the developers to test different dimensions of the product. Some tours that have been good are:

  • Feature Tour - Map all the features of the product
  • Variability Tour - Change all things that can be changed
  • Claims Tour - See what to product says it can do and do it
  • Super Model Tour - Only look at the superficial elements of the product
  • User Tour - Pretend to be a specific user with a specific use case in mind and do that

For the last one it have helped that we have had personas that already had a description to help with the inspiration.

I can see that the approach with checklist might be better if the requirements on you producing a test report to some external part, since it is easier to keep track on what have and have not been done with checklists. In my case that was not an important factor so I wanted to embrace the fact that developers have information about the product that I did not and I think that tours enables them to use that knowledge better than checklists.

Another approach I have been part of was when we had a lot of domain experts, as in they really new the product, we just needed to provide some focus for them to apply it in testing. There we used Test Charters to inspire them to test with specific goals in mind, and the principles from Session Based Testing to capture the work to facilitate the reporting.

Good Luck!

1 Like

(João Farias) #3

Bach’s Heuristic Test Strategy Model is always handy to have a clear idea of coverage.
I have created a mind-map of this model; you can find it here.

2 Likes

(Faith Roberts) #4

Hi @mirthfulman

Something that sprung to mind is testing XSS strings in your form tests.

I use this: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

There was a really good blog post in the MoT newsletter about testing text boxes, which may be of use. It’s here: http://thethinkingtester.blogspot.com/2019/03/four-reasons-you-should-test-input.html

I hope those resources can help you

Faith

3 Likes

(Simon) #5

This sounds good to me. One thing to be wary of is of making the checks too big. As soon as it becomes a chore the developers won’t do a good job of implementing any check list items that you come up with and you lose the benefit.

What are the major issues causing the back and forth? Can you pull a few things out and make them into more targeted kind of checklist items? Adding value quickly is going to benefit everyone, and hopefully demonstrate the benefit so that people are more happy to help.

Sorry for the vague advice, but I’d really start small and grow it.

1 Like

(Andrew) #6

I agree, I didn’t want it to be too exhaustive as most of the developers know more about the application under test than I do so I want to be less prescriptive and more general. There are definitely key areas I want to make sure they hit so I will be sure to include a small list of where I think they need improvement. A good start I think.

Right now the major problem is developers are not checking against the supported browsers. A pretty basic requirement but nonetheless has brought us to the point where these types of things need to put on paper.

1 Like

(Andrew) #7

I havent come across that heuristic model, thanks for posting. It’s a great way to visualize test coverage.

2 Likes

(Andrew) #8

Thanks Ola, interesting approach. Can you describe how these would work in practice? For Feature Tours, you would map out all the features of the product ahead of time and then get your development team in a room to “demo” it? Or is this more of an exercise for the developers where they map out what they think the features are for a given product?

1 Like

(Ola) #9

The feature tour is more of a preparation tour. In the end you (as in the one testing) will have a better picture of all the different parts of your product. I’ve seen people document this in a mind map or the good old domain trees. Commonly I have had developers in teams that have been working with one part or one page but this helps them see the full picture. So for the follow up tours they now also know that there is a settings page which controls certain elements of a page. Or that when you add some component in one place that affects what happens in another and so on.
So for the Feature Tour the output is not as interesting as the journey, and if you already know the product this is of less value.
I have never tried to do it in a group but I think that is an awesome idea to maybe kick off the testing for the entire team.

2 Likes