Please login or join to subscribe to this thread
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...
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.
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.
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.
let the experts talk for you: For example
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.
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.
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.
Please login or join to reply