How Do You Select Tools In A Regulated Environment?

I remember working in regulated environments, many moons ago now but I remember the process.

“Oh look, this tool does exactly what I want it to do, let’s use that.”

IT department

“No no, that’s not on the approved list of software, you can’t have that.”

I was fortunate that one of the IT people was very friendly and sped up some of my approval applications by months (typical wait time was 3-6 months!) :grinning:

I wanted to know how things are now in regulated environments.

How do you select tools for your team? Do you have visibility into the approval process for tools? Are there tools that you want to use but you’re not permitted to?

2 Likes

I think a lot depends on the regulation model. For example, when I worked in Ofwat (UK Government), our IT kit had to be approved by GCHQ because we were connected to the Government Secure Intranet, and GCHQ disapproved of apps that ran executable software across our internal network. (Hence my failure to use test automation tools back in the 1990s because IBM Rational did just that.)

On the other hand, I had a contract with a company that produced software for biochemical analysis machines. Although our formal test programme (script execution) was drawn up according to the appropriate Government Regulations set out by the Medical & Heathcare Products Regulatory Authority (MHRA) using the (then) current regulations, I never saw any evidence that the company had strict lists of what was or was not allowed, just that they had a methodology for testing that met the requirements. (But then again, I was only in on the last six months of completing a big project, so thinking up new ways of testing wasn’t high on the list of priorities.)

From what I see on the Government website (https://www.gov.uk/government/publications/report-a-non-compliant-medical-device-enforcement-process/how-mhra-ensures-the-safety-and-quality-of-medical-devices), MHSA aren’t going around enforcing the regs except in the event of an allegation of non-compliance. (Like most UK Government safety regulators, they don’t have the resources to follow a proactive programme of inspections.) And I also expect that software testing methodology is just one area where they are expected to have a role. So I suspect that a lot of instances where IT managers throw up their hands in horror at a suggestion from a tester as to how the process can be improved arises out of self-imposed restrictions and possibly a misunderstanding of the purpose and role of regulation generally.

3 Likes

I think your right in the summary at the end, most “restrictions” are caused by self imposed internal process or procedure rather than external regulation. Personally I’ve found this can be with the purpose to try and stop “sprawl” of tech and or vendors within one org so spending can be negotiated by procurement teams, licences & renewals, managed easier, people being able to move teams and get going quicker etc.

Frustrating though when it seemingly for no good reason and it stops innovation!

3 Likes

Did a brief stint at an open source vendor where any applications and any code we used was controlled rather more strictly than I was accustomed. Their main concern was as a Open source vendor not to be seen breaking the law by using freeware programs for business purposes. My takeaway from that was to be much more mindful of supporting freeware and fully open source apps in the unregulated jobs since.

This did generate a lot of in-house toolmaking, as did being strict about bringing new software in where if there was time to do it, we would write bespoke apps for loads of other workplace things rather than wait for the guys in IT to run it around the houses.

1 Like