What’s your current definition of software testing?

Discussions
, , ,
42

Interesting take:
Does this mean that you’re not testing the product from a non-customer perspective?
If you are ‘the first customer’, does that mean you’re biased towards a single perspective?
How do you know that you ‘find all the ways’?
Is software/product ‘break’ ing the only criteria in which the product might fail for the company and customers?
How do you manage to find the things ‘before anyone else does’? Are team mates, department colleagues, or company employees not finding anything?

43

Ah. Good questions! Since the original scenario that Rosie put together was that a stranger asks me what software testing is, I was being honest and sharing a very, very, very simplified answer that I would give as an answer.

It seems like if I said, “I’m a developer”, the implication is that I build things, so when I say, “I’m a tester”, the implication for me is that I break things :grinning:.

But, if said Stranger really wants to dive deep, and to answer your questions:

Does this mean that you’re not testing the product from a non-customer perspective?

I don’t know of any product that doesn’t have a customer. In my mind, the application we build will always be touched by customers, whether that’s the people purchasing our services to the sales team trying to sell the service. I think it was Carter Capocaccia who introduced the idea that when I build automation, the developers are my customers. That was a cool mind shift for me and something I think about often.

If you are ‘the first customer’, does that mean you’re biased towards a single perspective?

With the above clarified, this means I try to take on the perspectives of anyone who could touch the application. From first time users to users who have been using the services for a very long time, in any department in any organization. This may seem too broad and yes, I reach my limits but this is also how I learn. I want to know how someone else sees the application we are building. That helps me test better.

Yeah. Hahaha, again, this needs clarity. “All the ways” really means "all the ways that I can possibly know. This is indeed finite, which is why when building new functionality or redesigning current functionality, team members across departments should be involved. Design, CX, Engineering, Product, all need to be touching the new feature at some point because I don’t have the skill set to cover all the bases. And, as they test and share what’s missing, I can learn along the way as well.

Is software/product ‘break’ ing the only criteria in which the product might fail for the company and customers?

Certainly not. There is happy path testing. There is “how can I break this” testing, and then there is…I’m not sure if there is a word for it but maybe "how can this be better?’ testing. When I’m manually testing a flow and something doesn’t feel right (and yes that’s vague but often, that’s where it starts), I’ll try to pinpoint exactly what doesn’t feel right and then bring it up to the team. It may not matter, but at least we will have had a good discussion about it and made a decision about it at present. We can always revisit when it we have new information.

How do you manage to find the things ‘before anyone else does’? Are team mates, department colleagues, or company employees not finding anything?

Ah, yeah, when I say “before anyone else”, what I really mean is, “before it hits production”. But, even the word “production” can be confusing to people. This is not a race for me. On our teams, it’s encouraged that many divisions touch the new feature before it’s released. Quality is everyone’s responsibility. But, I do enjoy trying to see how many things I can find. And, honestly, that’s when I know when a feature is “ready to go”. If everyone’s looked at it, touched it, banged on it, and I’ve done all that I know to do, the only other option is to release it and find out what we missed. That’s our learning opportunity. The hope is that it’s a “clean” release (nobody dies and there are no software emergencies). The best release is a quiet one. But, if one or two bugs are reported, those are our learning opportunities that we can add into our testing strategy for the future.

Hope that helps bring more clarity.

44

I get it, if it’s a regular person you’re addressing to, a professional tester might be allowed to be a bit more careless or loose in picking the words for defining the profession. Although, many times I hear managers and those leading testing keeping ‘your’ words closely and demanding testers that they do that.

How would you define testing from the perspective of a tester, talking to a development team or a stakeholder?

45

My definition…

Testing is verifying that:
…what should happen, happens.
…what shouldn’t happen, doesn’t happen.
…trying something weird won’t blow up in our face.
…what we expect to work well, works well.
…it’s accessible to as many people as possible.

46

My definition is:

Software Testing is the act of applying critical, lateral and systems thinking, to the development of valuable software. With the resulting experiments bringing visibility to the balance between quality, risk and delivery.

47

Here is my definition:

When we talk about software testing, we are referring to all the activities carried out in collaboration with different stakeholders to ensure that the product in development meets users’ needs, functions without defects, and is pleasant to use for everyone.

48

If I replace ‘software testing’ with ‘product/project manager’ I see a better fit.

49

Is the software tester a specific role in which people apply that? how about developers, software architects, functional and business analysts, ui/ux experts, product/project managers?

50

Testing is a deep probing which requires not only mere code validation but also require smart thinking and great habits.

51

I went through my books and found these two definitions:

  • “Testing is the process of executing a program with the intent of finding errors”, Glenford J. Myers in The Art of Software Testing

  • “The act of designing, debugging, and executing tests”, Boris Beizer in Black Box Testing

52

The two definitions are interesting because they tell us different things. Myers’ book contains a thoughtful discussion on how to define testing

53

I recently just found out the hypothetical example I used a few times with fairly random strangers normally over a beer or a coffee was not actually a true example, so this is both a public sort of apology and also a consideration if its still a fairly okay example to use provided I caveat its not actually true.

Firstly the professional version I like is testing is asking awesome product risk based questions to accelerate the team and product forward but that’s not the one I use with strangers.

In a recent case I asked, if they were familiar with tinder which turns out most people are and expand into a humorous story on how left handed people for a long time were struggling to find love, their natural subconscious swipe often being in a different direction.

So part of my job as a tester was to consider all users, think about the risks and challenges they face and give feedback to those building the products where they could make things better for everyone.

In the mythical tinder example testing feedback encouraged the development of the ability to change the swipe direction and thereby helped people find love.

Yep, I went as far as saying testing is all about helping people find love.

The story was a lead in to talking about the slightly more serious topic of accessibility testing where I discover both challenges and opportunities with software that empowers those building the product to make it a better product for everyone. This bit is accurate, its not all that testing is about but as a casual understanding I’ve found strangers can relate and grasp better what I do.

Unfortunately I recently found out there is not an option to change the swipe direction, so hence my apology.

Yet I stand by this.

Testing discovers both challenges and opportunities with software that empowers those building the product to make it a better product for everyone.

54

Testing is not just about finding bugs, it’s about making sure everything works the way it should, like testing your smart lock before relying on it or double-checking your GPS before a road trip.
With AI & Automation, testers are not only fixing, but also preventing bugs and making a smooth, frustation-free experience.

55

For me, software testing:

  • Is only one piece of the quality puzzle - quality processes and delivery processes are just as important, if not more so

  • Requires the ability to zoom in and zoom out on a problem many times. The devil’s in the details as they say, but a bird’s eye view of the project is one of the details that must be considered!

  • Exists on a spectrum - it’s not only front-end or end-to-end testing when all the code is finished; it must start with the defining the initial problem accurately, and reviewing the requirements to find flaws before a line of code is even written.

  • Is both an art and a science!

  • Applies to testing and validating assumptions also, not just the code or UX itself

  • Is ultimately about taking care of people: users, team members, stakeholders, and more, so compassion and deep listening are a must!

56

In tangible world if something goes wrong, someone reports it & we tend to fix it. Same goes for non-tangible software world.

The person who reports that something can/would/has go/gone wrong is called: Software Tester.
The process they follow is called: Software Testing.

Example: You use whatsApp right? Yes. Testing is to make sure that it works for you.

57

Testing is sampling where we test our software against a few or some sample of data and check the expected behaviour.

Depending on the testing the data quantity can vary like if it is functional or api then the quantity of testing data may be around less than 100-200 something, where as if it is automation then quantity can be upto thousands however at the end of day no matter how we test we just expected behaviour of the s/w against these testing data.

58

This might be oversimplifying things, but..

  • Verifying software meets expectations
59

I started by looking at a few definitions of software testing, then noted what stood out most to me or things that I saw the definitions had in common. My current definition is a mix of what I’ve read - "software testing is the planning, execution and evaluation of testing activities to learn about the application, ensure it meets specified requirements, uncover unintended behaviour, with the goal of ensuring a positive user experience”

60

I’ve thought of a better one, it must have been cooking in my head over the last month :sweat_smile:

  • The process of continually evaluating software against continually evolving requirements.
61

“On the island of the testers, they were doomed forever to search for what could not and should not exist, knowing that to succeed would bring misery to the Gods”
from Cem Kaner James Bach in Lessons Learned in Software Testing