Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Change Management, Quality, Stakeholder Management
Explaining the importance of testing
Hi Friends, I've just been challenged by colleagues who think that testing database scripts is optional and unnecessary. In my career, the only time testing is skipped is when the system is down and there's an emergency change request to document the change.

I'm looking for a simple, non-technical, but also authoritative document that I can share with them to explain why testing must never be skipped, even for simple scripts.

Thanks for your ideas :)
Sort By:
Page: 1 2 next>
Brigitte -

Have you asked them why they think it is optional? If you understand the root misconception, it might help you address it effectively.

You could also consider using the power of analogy - ask them whether they'd be comfortable having their medical data stored in an EMR database which had not been tested...

Kiron
...
1 reply by Brigitte Fortin
Jul 28, 2022 1:18 PM
Brigitte Fortin
...
Thanks Kiron, and all the others who asked, the main concern is the speed of getting changes into prod, and the conception that testing is unnecessary for simpler changes, and adds an unneeded step arbitrarily for no real purpose. In other words, it's being perceived as a blocker, not a quality assurance mechanism.

Consistent testing is long held ITIL and SDLC standard. We are all human and can make a mistake - forgetting a commit, thinking we know what needs to be updated, but actually missing something and introducing further issues. This is why testing, as a best practice, is considered mandatory for all database changes.

And I'd love to get into a conversation with our team about this, but right now time doesn't allow. However there's enough noise around this that I expect we'll be talking about it again, so I'll be trying out all the great suggestions people here have made.

Again, my humble appreciation.
I agree with Kiron. My follow-up question is what is your policy and work standards in your department/division esp in terms of Quality Control/Assurance, Change Management which basically would provide guidelines on the how-to’s of the division or dept or organization.
Brigitte

I agree with Kiron as well. It is important to know the root cause before you address the issue.

I am not too experienced in IT but I know that probably not doing testing might accumulate technical debt and cause other quality issues.

RK
Thanks all, I'll give these ideas a try. Right now the focus is on documentation that walks a non-technical person through the importance of not skipping testing.
I have a few exploratory questions. You don't need to give me the answers, but think about them if you haven't already.

- What level of testing do they feel is unnecessary? Are they unit testing as they change the scripts and saying that no integration testing or UAT is needed?
- How much and what type(s) of testing are you expecting for each change?
- How complex are the data sources and queries? Is your data complete and accurate?
- What are the script changes doing to the data?
- Who needs the data and what will they do with it?
- Is your testing approach one-size-fits-all?

Before you tell them how and why they need to test, you have a great opportunity to understand their perspective and lead them to a mutual understanding. Maybe they're resisting because they feel there's too much testing required for minor changes. Maybe they're more concerned with delivering quickly, either because of organizational pressures or because that's just how some developers are.

It's possible they don't understand the value of testing, but chances are that there are deeper reasons for their expressed opinion. It's worth understanding and figuring out the right approach to testing in your organization. Different changes may be satisfied by different levels of testing. If you can quantify the differences, you may not only satisfy your colleagues, you may also be better prepared to explain the consequences when there is pressure to skip or shortcut testing.
Brigitte,

let the experts talk for you: For example
https://youtu.be/LA5B5g1kLkM

Thomas
...
1 reply by Brigitte Fortin
Jul 28, 2022 1:33 PM
Brigitte Fortin
...
Yes, I may have to paint the picture of the costs. Thanks, it's a good video, but not something that will keep my target audience's attention ;) Maybe I can find an explanation of the graph at the end, showing - well proving - that quality goes up with consistent qc measures.
Ok, why do they think that is optional?
Anyways, being mandatory or optional is the planning team's choice. It generally comes from the company policies, etc. Having said that, I am a fan of "do a little, test a little" for similar settings.
Jul 27, 2022 6:20 PM
Replying to Kiron Bondale
...
Brigitte -

Have you asked them why they think it is optional? If you understand the root misconception, it might help you address it effectively.

You could also consider using the power of analogy - ask them whether they'd be comfortable having their medical data stored in an EMR database which had not been tested...

Kiron
Thanks Kiron, and all the others who asked, the main concern is the speed of getting changes into prod, and the conception that testing is unnecessary for simpler changes, and adds an unneeded step arbitrarily for no real purpose. In other words, it's being perceived as a blocker, not a quality assurance mechanism.

Consistent testing is long held ITIL and SDLC standard. We are all human and can make a mistake - forgetting a commit, thinking we know what needs to be updated, but actually missing something and introducing further issues. This is why testing, as a best practice, is considered mandatory for all database changes.

And I'd love to get into a conversation with our team about this, but right now time doesn't allow. However there's enough noise around this that I expect we'll be talking about it again, so I'll be trying out all the great suggestions people here have made.

Again, my humble appreciation.
Jul 28, 2022 11:16 AM
Replying to Thomas Walenta
...
Brigitte,

let the experts talk for you: For example
https://youtu.be/LA5B5g1kLkM

Thomas
Yes, I may have to paint the picture of the costs. Thanks, it's a good video, but not something that will keep my target audience's attention ;) Maybe I can find an explanation of the graph at the end, showing - well proving - that quality goes up with consistent qc measures.
Sometimes it may be OK to not test, but first you need to ask what is the consequence of finding an issue.

If a change doesn't affect the customer's functionality such as it is limited to your own internal data collection on the SW performance, then it might be acceptable to not test, but then you also don't know if your internal data is any good. Another example is if the functionality changed isn't needed now but we are inserting it early to gain practical experience, and it is isolated from other systems

Otherwise, the change may adversely affect the intended function, or inadvertently impact functions either within the changed module, or other modules with different owners who interface with the prime group.

In a safety intensive industry, if someone wishes to avoid functional or regression testing, then they must justify their rationale. That is treated on a case by case basis and reviewed with cross-functional team of equipment owners to ensure potential adverse affects were not overlooked.
...
1 reply by Brigitte Fortin
Jul 28, 2022 1:58 PM
Brigitte Fortin
...
Good point, we can ask test resisters to define the consequences when something goes wrong, that may get them thinking differently. Usually, the consequence is "we did it wrong" and "they have been jilted" by our failure. So you can see, this gets pretty touchy. So we end up in a bit of a tug of war, with customers saying, just put the data in Prod and no we don't want to test, but if anything goes wrong, it's because you failed. Not that we as a wider team failed to take the few minutes that is required to run a quick test.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"There's a Mr. Bartlett to see you, sir."

- Graham Chapman, Monty Python's Flying Circus

ADVERTISEMENT

Sponsors