Hello, I’ve been a tester for 1 year now but I feel out of sync with
What I learned theorically and what I see in social networks, here (Agile, Test automation for exemple…).
I’m not entirely sure but I think it’s because : I work in a regulated / classified business domain and it this alone causes many constraints :
Project feel very big, I’m working on almost all business areas in a ERP system (Industry, Financials and so on). I’m on the customer’s end, so in that regard :
1/ Organizational :
I test almost all the time with future key users from the company. Which I think is a good thing !
On the contrary I have almost no communication with developers, only through consultants from the Editor.
Their work is difficult because they can’t access to our environments and for help, they can only use anonymized data. They also have a hard time to understand bugs that I uncover. Because I can’t share classified documentation. (They can only work from the specification).
All our apps are on-premise, consequence : Can’t automate test (?) don’t know any test automation tools that can be deployed while respecting those constraints : Must work on premise without transfering data outside the network. (So at some point, we gave up about test automation). In that regard, even if I’m insterested in learning about test-automation, I wouldn’t be able to use it in my current job.
2/ Testing itself :
Most of the test I write are to check if the program is working as specified and have little room “test outside the box” such as : Seeing if I change a parameter, it still works as intended. But I hear so much about testers “trying to break things”. In my job, I don’t want to break things, they are hard enough to figure out without trying to break them !!
As you may have concluded, All our test are manual, which is a time-killer, but feels good because by doing manual tests, I feel like I’m learning by using everyday the app (almost like a future user) ^^.
One day, I’ll get another tester job in an other company, but when I say I feel out of sync, I don’t know if my tester experience is up to date with today practices.
Well … I worked in a restaurant and did social sciences before becoming a tester so I’m partly answering my own question… but still !
I don’t have all in my mind, but mostly wanted to know if some of you are also working in classified/regulated companies, and maybe share our experiences ?
Thank you all for reading, and sorry for my bad english !!
I spent fifteen years testing in a regulated environment (utility regulation) and also did contract work later on embedded systems for biomedical analysis devices, so I understand where you are coming from - though I never had to cope with bug reports not being able to go to developers with observed behaviour because those observations were themselves classified material that could not go off-site. Our dev team was wholly in-house.
The testing I did on data collection systems for regulated utility industries involved confidential information, so I was certain to build a wholly anonymised dataset that could not be linked to any external company. Indeed, we actually identified an instance where a company was falsifying their data return to us because it looked too much like my dataset! (I developed time series data using some rules-of-thumb for year-on-year changes to the dataset based on my knowledge of company activities.)
The emphasis in that job - and indeed, the organisation’s definition of “quality assurance” - was based around confidence in the data and in the outputs from the system. The results from the data collection tool and some analytical calculations the tool performed on the collected data formed the basis of regulatory decisions, and so had to be sufficiently robust to stand up to legal and political challenge.
This resulted in a set of workplace objectives which were very different to the sort of software testing that I’ve seen since in pure software development environments; but the fifteen years I spent doing that and the sort of companies I worked with as data providers, was sufficiently impressive to other employers for them to engage me as a more conventional software tester in later life. The same goes for the experience of performing very highly scripted tests on medical equipment software.
Your experience is different to a lot of other testers’. Somewhere, there will be an employer who will look at that experience and say “Wow, no-one else we’re seeing has this sort of experience. We need this person’s perspective and specialist knowledge - they can probably learn on the job as much of the mainstream testing stuff as we need. Knowledge like this may give us the edge we need.” You may have to look a bit harder to find that special employer - but believe me, they do exist and they are out there.
Thank you ! I’m relieved to read your answer ! And it made me think deeper about the context of my work. I’ll add some details and some corrections to complete your answers. Maybe there’s a slight difference between medical where you worked and military where I’m currently working. And even if it were true, I cannot say if it’s my company only or the same for all military companies.
I see a difference between your context and mine. Even if I test in an isolated environment, the data is still very close to what can be seen in the production environment. This causes the following problem :
– There are only some of our test in the customer’s environment that use anonymized data. That’s when the data in a table did not exist before (new functionnality, evolution). So most of the time, when I report a bug, I can tell what I observed, but cannot share screenshots unless the data is anonymized.
– I see that it’s a good thing to have developers around. In our project, developers are people subcontracted by the Editor. It would have been easier if they were working hand-in-hand with us.
When I read about your experience :
I didn’t know that a company could falsify their data return… I’ll try to be careful about that in my next job. In mine, since all apps are on-premise, within the company’s infrastructure, the information is sent and received most of the time by users / people from the company.
Your third paragraph really sums up what I think my experience now is. “Confidence in the data and in the outputs from the system” is one of the most important thing. Maybe since our tool isn’t destined to the general public but to workers, we care less about user’s experience, design (we think of it, but not as a critical thing). Security is also at the top, but It’s not in my test perimeter but the IT department’s, so I might learn about that later.
You wrote a bit about how you developed and changed your dataset based on your knowledge of company activites. I think I’ll also focus on that, because in my context, that’s the area in which I can improve the most with the most gain on the value of my tests. When I look back 1y ago when I started, I didn’t know much and it made writing tests very difficult. 1y later, I write tests that I couldn’t even imagine when I started. I also have this feeling that my head is overflowing with informations and the biggest challenge is to make the link between them !
I’m still learning but now I understand why I felt “out of sync”. I really thank you because now I see that’s not necessarily wrong nor a bad thing.
Now I also have some angles I can work with when I’ll be looking for a new job. I found out that I’ll still have to keep an eye to the trends of testing. I’ll also keep in mind that my experience has some value even now or later.
I’ll also be happy to read more from all of you !
Very much of the work done in regulated industries is not talked about online just because of the very nature. Financials is just one end of a long continuum, and talked about online even less. Probably because it is really dry. I have worked in industrial control (not as a tester, but as coder) and the QA game there is very varied too. Some of our system was often used alongside medical and other life critical systems, so we always had to prove some security at the least. New players in industrial control don’t have to play to the standards until they start selling into ISO**** companies or start exporting broadly. We had to deal with a mix of that all along and had to go ISO at the time.
A thing I learned from my industrial control stint is that “mission” is the main focus. You can never ever crash, and that in itself drives up the quality bar just by having that one rule. (I prefer to call it a constraint, as that a better understood word.) Financials systems probably crash quite often, but they recover or resume quickly, that was not ever an option in industrial control systems where sometimes the testing of a system used to take an entire year before customers would start deploying. I mean a watchdog in an industrial control system often exists, but if it triggers everyone on the floor asks you a million questions, because that outage gets recorded in every single data-point.
I mean even operating systems have a high quality bar, which also does not compare to medical, regulated or financials industries… but in reality those all rely on an operating system. So in reality a lot of the good testing practices may well originate from those regulated or mission critical systems. I have used lessons from my time in the industrial control area as a coder, to drive a lot of what I now do today as a tester in a less regulated environment. That said, my new manager has booked us on a short ISO27-something module coming up, not looking forward to it. Big respect to those who have it.
I see some similarities between my experience and your second paragraph. We’re a team of 8 testers now and we’ve been testing for more than 1 year. I think there’ll many months before the new ERP is fully deployed. Now, only a few key users are using it to test alongside us, but we feel like we’re advancing in very little steps at a time.
Now that you mention it, I spend a large portion of my time understanding why something crashed, why a transaction could not happen, why a business rule could not work in the system. When it does crash for an unexpected reasons, I tend to receive many emails from every key users.
I try to see when there are obvious security issues but I am not trained to test security. In my project, it is in IT department’s scope and not our testing team. And I don’t know much about ISO, that sounds difficult ! I have to keep those topics in my mind so I can learn about them later. Thanks ! I’ll try to look for ressources or documentation.
I’m really glad I opened this topic because I feel that when I’m reading about others I can reflect on what I’m doing myself without beeing able to see it. Maybe the thing I find difficult now is that I don’t have a second point to compare my ongoing experience with something else.
Conrad’s second paragraph actually explains why a large proportion of the UK banking sector’s code base is actually very old - in both computing and real-life terms! (At least, as far as the traditional High Street national banking chains are concerned.)
It’s a two-edged sword; on the one hand, it’s tried and tested and has reached a stage of immense maturity and stability. On the other, it’s written in coding languages long since consigned to history in other sectors, and so is reliant on an ever-dwindling number of people who know that language to maintain and patch it. And the implications of switching to something more modern are potentially terrifying in terms of the scale of such a project and the potential for stuff going wrong at switchover,
Hi everyone,
I am currently considering leaving my current job so I can learn new things somewhere else. I’m still going to be a tester. I’m not reading every topics but from time to time I find some great post and tips here.
The answers I had here helped be build some confidence to do so.
So I wanted to say thanks from the bottom of my heart !
