What software testing models do you use to help with your testing?

It would be amazing to know or see what models you use to help with your testing work. Any particular ones you have found useful to shape your work or ideas?

There’s a nice thread of ‘software testing pyramid’ themed models - The Software Testing Pyramid - #6 by danashby

1 Like

For testing models, I typically start with the HTSM from James Bach

I think that HTSM is, on the surface, simple and easy to present. It can be applied to all levels of software development, from testing a specificatie to the finished product… from testing a unit to testing end-to-end… from structured testing to less structured testing… and whatever testing type.

Then when I peek under the hood, there’s information, ideas, possibilities, just enough to send me on my way in most contexts.


I’ve never seen my methodology as a formalized model, to be honest. Since I’m the only tester in the organization and mostly I work on a massive classic ASP web application, my options are GUI automation and manual testing.

I start with steel thread/happy path tests - does it do what it should do?
Then I check the less common scenarios - the boundaries, the odd configuration settings, and so forth.
Then I try to find the breaks - low level hacking, can I force the thing to do something it absolutely should not do, ever.
If time permits, I try to automate the most crucial pieces and try to get some form of load testing however minimal.

So I guess it would be a risk-based model, starting from the most common scenarios and moving out to the least common with manual, mostly exploratory tests around user personas.


I recently blogged an update to the HTSM model, to help me with a deeper test strategy for projects: https://danashby.co.uk/2017/12/13/a-new-model-for-test-strategies/


I’ve been creating models galore recently.
Here’s one that I created to help formulate a discussion about continuous testing throughout an SDLC with a particular focus on feedback loops:

And here’s another that I’ve been working on to help testers think about breaking down the thing they are testing into different properties, purposes, states, etc… And then thinking of the variables within them in order to help generate more ideas about risks, which in turn helps stem test ideas. (rather than testers just jumping straight to test ideas from the “thing”…)

Keen to get feedback on these 2 models!

I’m working on some more, but they are a secret for now :wink:


All you have to do is doodle this, and then it’s like a ‘proper’ model :wink:


Tester, there’s no need to feel down.
I said tester, there are models around.
I said tester, 'cause you’re in a breakdown.
There’s no need to get frustrated.

Tester, there’s a place you can go.
I said tester, when you need the download.
You can use it, and I’m sure you will find
That your flow is streamlined.

It’s good to utilise HTSM
It’s good to utilise HTSM

It has everything for testers to deploy
You can hang out and test with joy.


In the past I’ve primarily used my own home rolled gut instincts and personal heuristics based on risk/reward/time. My org had Michael Bolton come out and do his RST which provided a lot of great information on other heuristics and solidified the hows and whys of things like HSTM. Overall I think when one jumps into a new org or project starting with something even just conversations with product owners gives goods hints where to look and what to avoid and eventually some products necessitate customized models. One area I would like to make a model or guide for a when a product has reached extreme feature creep.

Hi Rosie,

I’ve been using my Periodic Table of Testing for a while and the associated scoping categories to help me set out my approach/strategy. I’ve also had some decent feedback on it, but bear in mind I’m definitely biased :slight_smile:

Is “all of the above” an option? Like Kate, a lot of my testing doesn’t follow a formalised model and a lot of the planning isn’t written down due to the small size of some of the projects (minor enhancements to legacy systems) there are times when a more formal approach is needed. The models Dan’s sketched out are certainly familiar!

I think there is a linear progression here of ‘newer’ tester to experienced. A newer tester would be interested in models, heuristics, checklists etc. to help them get going. An experienced tester might have clear goals but can be helped by the same, perspectives, exploring personas and more. ‘All of the above’ is definitely an option as everything has its own context.


There are various testing models available these days and in use by top software testing companies. Starting from Agile, to Waterfall, V-model & Spiral models. Each model has its own unique structure and it is important to choose the right methodology before the project gets started.

  • For a large project, that is to be developed over a longer timeline would obviously require a lot of documentation at each phase and to fulfill these requirements Waterfall or V-model are going to work. Whereas, for changing requirements and faster delivery where the phases progresses quickly, Agile is going to be a good option as it is based on minimal documentation.
  • Waterfall model of testing assumes that the project requirements have been frozen and there is no much scope of changes at any later stage whereas V-model provides some flexibility in change of requirements at later stage. For projects with constantly changing requirements, Agile plays a good role and allows its product to reach to its customer in short time period.

As for current project on which I am working, Agile methodology is used.

Hope this information is helpful for you.