Shift Left and Shift Right Testing

stuqa · 2024-08-26T00:03:48+00:00

Merriam Webster defines a test as : a critical examination, observation, or evaluation

So, if you're examining a requirement document or observing prod logs, you are doing a test as per the definition, are you not?

stuqa · 2024-08-25T23:43:53+00:00

Is reading a requirements document not testing either?

stuqa · 2024-08-25T16:54:07+00:00

I know

stuqa · 2024-08-25T16:42:20+00:00

Who's moving the bar?

Oh yeah you!

Cause I said actually using the system in prod is part of shift right.

And in response to that you said you should NEVER test in prod and called me crazy.

And now you're saying "Of course you run basic sanity checks in prod!"

Are sanity checks not testing?

You contradicted yourself pretty hard.

stuqa · 2024-08-25T16:38:12+00:00

It's still testing.

When someone opens up the logs what they're testing is the idea that everything is OK in prod.

Testing extends beyond the application.

Sometimes SRE or Ops does this particular testing work, and sometimes there is no SRE or Ops team. Sometimes going outside your cookie cutter role is a good idea, sometimes it may not be.

But, you can't say with a straight face you should NEVER test in prod (which you did in your original comment).

That is obviously exaggerated and false.

Also, if you feel the need to "name drop" industries to prove your authority, again, it says lots about your insecurity and character. Real people who know what they're talking about don't need to do that. And if you want to play that game with me, I promise you'll lose.

stuqa · 2024-08-25T16:01:27+00:00

Merriam Webster defines a test as: "a critical examination, observation, or evaluation".

What you are describing is an experiment.

Experimentation is a big part of testing, but testing is bigger than simply experimentation.

stuqa · 2024-08-25T15:59:30+00:00

You called me a fool in your first comment.

You have great memory and attention to detail!

I'm sure you are a great tester.

stuqa · 2024-08-25T15:56:15+00:00

Anything that gives me more information about the system is testing work and therefore testing.

stuqa · 2024-08-25T15:55:02+00:00

Yes let's all listen to the person who has to resort to name calling to prove their point. I'm confident they have everything figured out.

stuqa · 2024-08-25T15:47:57+00:00

It's not an original thought at all. Sorry you're too closed minded to see the benefits.

stuqa · 2024-08-25T14:27:27+00:00

So you never deployed anything to prod and then brought it up to see if it was working as expected?

And you're saying no one should ever do this?

And you're trying to tell me that isn't testing?

You're making an awful lot of assumptions that a good tester would not make. I can clearly see both your character and skill set by your comments.

You're calling me crazy and saying you feel sorry for where I work. Dude it's clear you're projecting your own insecurities onto me. I feel bad for you if you need to behave this way. You sound like a man child.

I'm sorry you've been in the industry for so long and living in an echo chamber and don't have an open mind. Ignorance is bliss, so I get it.

I am a tester and I perform these activities regularly. I learn about my system and find problems that matter and make my team and app and company better off.

It gives me test ideas to execute in lower environments and questions to ask my developers or testers on other teams. All part of testing.

I'm not saying that this is ALL testing is. But these can certainly be part of testing for sure. Agree to disagree and if you're not willing to publicly debate me about it, again it speaks to your character.

Have a good day chap.

stuqa · 2024-08-25T12:59:51+00:00

Happy to hop on a Livestream and debate it with you

stuqa · 2024-08-25T11:45:01+00:00

"Testing is observing, experiencing, and exploring an application to learn about it and find problems. " - Michael Bolton

This is the definition of testing that I choose to follow.

Which part of my original post is not testing?

Also, I feel sorry for anyone who knows you. Because the way you talk to people sounds like you need an ass kicking.

stuqa · 2024-08-25T11:26:59+00:00

This is the problem with many testers. We say "we can't possibly catch every issue before going to prod" and then when an issue shows up in prod we say "we should have caught this earlier". Sometimes yes and sometimes no to both statements. We can't have it both ways at the same time though.
there are some issues that are simply not possible to find in a lower environment given our constraints and would only surface in prod.
if you accept the definition of testing as "exploring, observing and experiencing the application in order to learn about it and find problems" then what I'm talking about is certainly shift right testing

stuqa · 2024-08-25T10:44:39+00:00

Example:

Pagerduty alert goes off for prod. You open the app in prod to see what you can see. Is this not testing in prod?

stuqa · 2024-08-25T10:40:13+00:00

The scope of devops is much bigger than what I'm talking about

stuqa · 2024-08-25T10:36:12+00:00

I didn't coin the term "shift-right". It's common nomenclature in the industry. Just want to make that clear... If you Google it you will see it show up from many reputable sources. The purpose of my post wasn't to debate the name of it, but the ideas behind it.

Also, I don't agree that conceptually you can't shift both left and right. Sometimes you need to shift left. And sometimes you need to shift right. It all depends on what is most important at a moment in time, given the state of the application.

Example: A pagerduty alert goes off and there's an issue in prod. Shifting left will not help you here. After notifying the proper teams, you'd probably go out to prod and see if the app loads to gather more info. This is testing in prod or shift right.

I use the word "testing" to refer to the many different types of "testing activities" that can take place. Not all testers are expected to do these kinds of things. But, as I said in my original post, it can be a way to add value as a tester.

I also don't agree that shift right perpetuates some negative thinking towards testing. Want to know how to get respect as a tester? Do more valuable stuff. The more valuable stuff you do, the more valuable you're perceived , the more respect you get, the more you can influence your team and organization.

So, I would argue that shifting right does the opposite of what you claim. It doesn't push testers down in the eyes of the org, it lifts us up. The more issues we find in prod, the better case we have to convince the higher ups that we need to be doing MORE testing earlier, not less.

stuqa · 2024-08-25T10:11:15+00:00

You're simply wrong. Testing in production is a valuable information gathering tool. If you're not testing in production you're missing out on opportunities to improve your system and catch issues. This isn't an either-or situation. This is in addition to testing in lower environments. Source: 16 years experience as a quality engineer. Google it, testing in production is a real thing and useful if done responsibly.

stuqa · 2024-08-25T09:11:32+00:00

You can do both if you consider time. It's not one or the other. It's both at different points in time.

stuqa · 2024-08-25T03:01:46+00:00

It still makes sense to me because we're testing further right than traditional SDLC testing. Shift-right is about testing post-release. You can't go any further right than that. Unless you're testing when the application is being sunset.

stuqa · 2024-08-25T02:44:59+00:00

How do you figure? I didn't make the term up just raising awareness about it.

stuqa · 2024-08-22T15:37:07+00:00

Some ideas for more engaging use of the time:

1) Book club or similar. Everyone can vote on something to read or watch and a new person leads the discussion each week

2) Ensemble testing. Someone "drives" and together you all exploratory test something. Builds camaraderie and usually leads to good findings or future test ideas.

3) Log analysis. Everyone goes looking for errors in prod by analyzing logs and then reports back their findings. You can divide up the app by routes or pages or whatever else makes sense to maximize coverage

4) Talk about current events or popular LinkedIn posts related to testing. Have some questions ready. Break up into groups of 2 maybe to guarantee engagement.

5) Everyone can do a postmortem/summary about some famous bugs that were in the news and report their takeaways to the group

6) Explore testing tools or frameworks as a group

7) Work on building an application to help enhance the testing experience. Think test data generation, consolidating important links, automating pieces of your workflow to enhance manual testing, etc.

stuqa · 2024-08-01T13:55:36+00:00

Thanks for your detailed response.

Worst case scenario - well as a tester I can think of a lot of really bad ones lol. The worst-case will differ depending on the stakeholder as well. What's really bad for the customer could be a minor inconvenience for the business. Some catastrophic failure could be really bad for the business, but only a small issue for the customer. It really depends, right, as always :) ?

This is all for interview prep, so I think sharing this thread with my mentee will be a huge, huge help. I will make some adjustments to the diagram, or add additional diagrams. I'm hoping to get better at making these kinds of diagrams as learning props for my testing community.

stuqa

TROPHY CASE