I work as a quality engineer at a mid-sized firm, where I was recently instructed to remove the repository from my machine and avoid accessing the codebase altogether. Until this point, I had relied on local copies of our repo to run the front-end for testing pull requests and handling bug fixes—bread-and-butter QE tasks like bug classification (logical, UI, etc.), testing scope (where else the code is used), and other typical quality engineering responsibilities. But now, I'm barred from accessing the very tools that make these processes efficient.
I will refrain from passing judgment on the decision itself, but given the project’s architecture, I suspect it is a costly one. Here are some reasons why:
- It severely hampers my ability to debug, troubleshoot, reverse-engineer, scope, reproduce, and isolate issues—essential functions in QE.
- Additional layers of communication are now required to manage shared resources, which translates into time wasted asking developers to check things in the codebase.
- Given our continuous integration pipeline, testing pull requests will now necessitate either competing for limited resources or sinking thousands of dollars annually into securing my own dedicated testing environment.
- Front-end deployments take about 10 minutes; the back-end, 40 minutes.
- When our CI pipeline breaks down, there are no backup methods for testing.
Thus, the question arises: why would a company, explicitly aiming to reduce expenses, introduce what seems like an arbitrary increase in operational costs? I don't believe they would, at least not without reason. Below are some additional breadcrumbs that might help in contextualizing this decision. To maintain confidentiality for both myself and the company, I’ve deliberately omitted identifying details, though it would likely be transparent to any colleague who reads this. This is not driven by any malicious intent, nor do I believe anything expressed here is defamatory. On the contrary, my aim is to clarify the situation, assess my understanding, and solicit broader input to better inform my decisions and prepare for possible outcomes. I acknowledge that, by omitting certain specifics, I may risk an incomplete representation of the scenario—but for now, it should suffice to provide enough of a framework for discussion.
{MOVED TO COMMENTS}
The question remains: Why was this decision made? Is it:
A. A misguided perception on my part—this is standard procedure and nothing unusual.
B. A decision made by someone lacking technical knowledge.
C. An early sign the company is preparing to let me go.
D. A precaution because the company perceives me as a cybersecurity risk.
E. Some combination of the above.
F. Another reason entirely.
Any and all thoughts, suggestions, and comments are welcome and greatly appreciated.
From the details you do provide, I can see how a non-tech person would interpret many of your actions as "concerning".
But the key issue remains: Do you have a technically competent CTO you directly report to? If so, that person should be responsible for resolving your issue. On the other hand, if you have a tech team without a competent technical manager overseeing operations, then things are likely to get screwy from time to time. Misguided attempts at cost saving being just one of many.
reply