How are testers building an understanding/model of the business/company they are testing for?

Questions
,
#1

Happy new year by the way.

I’m looking for some insight into how testers build up an understanding/model of the business/company they work for or test for. Is understanding a companies business model something that’s considered? How do people build this knowledge? Examples of how it’s helped their testing and decisions? Any articles around this topic to read?

I read a book(Business model generation - by Alexander Osterwalder…) a while back about the 9 building blocks of a business model: and using that I tend to try and find out how the company makes money and the rational behind how they create and deliver value.
eg - “Revenue streams” - finding out a companies revenue stream are subscriptions, can highlight wanting to keep customers possibly being important of which “user experience” of their product impacts… Understanding their “customer segments” also highlights their niche market + target customers, their communication channels… etc are all useful to know.

IMG_1422
IMG_14224032×2542 2.98 MB

NB: Redhats model has probably changed now, this is outdated. Only using as an example.
Key Partnerships [KP]

Key Activities [KA]

Key Resources [KR]

Cost Structure [C$]

Value Propositions [VP]

Customer Relationships [CR]

Channels [CH]

Customer Segments [CS]

Revenue Streams [R$]

3 Likes
#2

Hi @rforjoe,

That’s a great question! It’s key to understand the business drivers and make them explicit. Where is the company now and where is it heading. What movement is being driven? (conversion, subscriptions, transformation).

I’m currently exploring Wardley maps for this, and wrote about it recently here:

cheers

5 Likes
#3

After being a tester for about 10 years now, I’ve started taking this business goal driven side into consideration too. I was working at a company when we had a VC investor come and talk to us about software project risks, and made it sound like product risk is a thing testers should report on. But. It’s tricky ground to get into because you open yourself up to looking into risks that have nothing to do with the software creation process that you have any control over. But it’s not our job to tell the business where ALL project risks lie. Please do read the brilliant blog post that @jesper has shared, to improve your “visibility” across the business above.

My biggest useful example here of reasons to be keeping track of what the key product selling point is and focusing test around it, instead of testing a feature that has been in the product a long time and is about to be replaced by a newer feature. So getting “usage” data is something you often need to go searching for around the business.

5 Likes
#4

Hi @jesper , Thanks for that. That is very true, making them explicit will benefit the whole team. Is this something you often do? Any feedback given when you’ve done this?

Just looking into Wardley Maps. Very interesting. Found this on youtube a video by Simon Wardley: SEACON:UK 2019 An Introduction to Wardley Maps - YouTube

I’ll explore it a bit more and get back to you, sounds super useful. Thanks for your input

PS: This is great: Visualize the Test Strategy | Complexity is a Matter of Perspective

2 Likes
#5

Great to hear @rforjoe!

I’m experimenting mostly :slight_smile: Obviously maps get even better with collaboration, but I’m not there yet. I often remove the mechanics/scaffolding and draw elements and their relative positions. So that the other people involved doesn’t have to understand all about mapping before getting digging in.

Looking forward to hear your experiences!