Shouldn't the type of users fit in to SFDPOT?

🙋 Questions
1

This is more a philosophy type question.

In HTSM, there is talk about users in test techniques. Shouldn’t the different types of users be part of the SFDPOT section and not so much a test technique (or both)

1 Like
2

Both.

They are part of Mission of the Testing under Project Environment.

To fulfill that mission, you will have to apply test techniques where you would have to consider them.

Ex: Localization Testing for “X” user persona.

3

Is it specifically listed in the Project Env.

1 Like
4

Yes it is :slight_smile:

Example mindmap here: Test Strategy - Netflix (OTT) | Rahul Parwal - Xmind

5

What should I look at

6

Project Environment Node on this Mindmap.

Also, the first MUTT Node.

7

I see now.
Where did MUTT come from?

8

Attended a workshop on Test Strategy by Paul Holland. Got to know from him.

9

What is the chance that by just using TLA’s we can include more ideas more quickly be being brief? Always have been wary, because anyone with a heuristic (or a TLA) is really using it as an abstraction and even to reduce volume of things going on in their minds. And everyone starts with a disclaimer, to first look at how the heuristic fits your team or org anyway.

What are your specific (in theory) questions about the Structure/Function/Data/Platform/Operations/Time heuristic? Are you just worried about end-users finding defects here for example, or wanting to actually get user feedback as a quality driver?

10

Worry not, because they are.

Users are in Product Elements > Operations > Users. This is for consideration of the kinds of users that will interact with your product.

They’re also in Test Techniques > User, as in User Testing. Interacting with the product as if you were a particular type of user, with an understanding of their wants, needs, how they behave, and so on.

11

I want to map users/personas to make sure they are covered in testing.

1 Like
12

Our product team recently re-wrote our personas, which were pretty useless before. and mapped them to roles, which are largely security groups. It’s more granular but I have it boiled down to 3.

  • Purchaser or account manager
  • End user
  • Administrator

But because most of our target is power users, the last 2 roles merge a bit messily in terms of how much of the product they touch every day. But now I’m keen to map these roles to the components/functional areas, this has been a good question all round Nilanjan.

1 Like