In a development environment where developers are freely given root / admin access to their personal development VM's is there a need to prevent integration testers from having root / admin access in their personal testing VM's?

The environment will use continuous integration and continuous deployment and aims to follow DevOps.

Naturally anyone who has root / admin access shouldn't log in as root / admin all the time. This question is about who is allowed access to both accounts when doing their work.

Developers have root / admin access so they can configure their personal vm's to meet their needs. Should a tester who is creating tests be able to do the same?

This question is not about whether a test should be run with root privileges. It's about whether a person who writes tests has to ask someone else to configure the personal VM they use to create the tests.

By testers personal VM I'm referring to the VM they use to create automated integration tests. The ones a developer should be able to run on their own personal VM before checking in code.

  • Why do you think testers would need root access? Unless your software has additional features when running under root, or requires root, I don't see the point. And even in such a case, it could be emulated through a VM without giving them actual root access on the physical machine. Mar 30, 2017 at 3:26
  • @ChrisCirefice The point of the question isn't why anyone needs root on a VM. It's asking why testers would need to be treated differently than developers. Mar 30, 2017 at 3:30
  • Ah, that wasn't immediately clear to me. I don't see any reason why testers should be treated differently from developers, but that's just an opinion based on anecdotal evidence. Mar 30, 2017 at 3:32
  • 1
    If you have technically inclined testers, they can add value by having root with the ability to use tools like ptrace or wireshark to debug or find issues that are normally not visible to normal users. IMO, this is beyond the expected capability of most testers, so I'd not advise giving testers unrestricted root access as a default. But if you have highly capable testers who know how to use these tools, and you trust them enough as an employee, and your application testing could benefit from such low level debugging, then I don't see why not.
    – Lie Ryan
    Mar 30, 2017 at 10:05
  • 2
    Be aware that DevOps is a buzzword to make important-sounding speeches and sell consultant jobs, not a true methodology. It means absolutely nothing to the agile community (or, any community, to be honest). It's just a fancy word to say that you have a process in place to deliver software. It's not different from those scammers that sell "agile processes" but don't have a clue of what scrum or XP are about.
    – T. Sar
    Mar 30, 2017 at 12:20

5 Answers 5


The situation looks pretty simple to me: people need the tools to do their job correctly. If they need root access, they should be given root access and they should be trusted (and trained, if necessary) to use it responsibly.

Similarly, if they don't need root access then there is no reason to give it to them.


While root/admin access to the machine may be useful for setting up the environment, tests should be run in a way the "normal" user of the product does. In most cases, this will mean that a "normal" user account should be used (that does not exclude an additional root account for setup/configuration). If the system under test has its own user rights management, tests with low user rights are extremely important. In my experience, the worst and hardest to find bugs involve problems with user rights.

From the point of view of testing, the access rights typically granted to developers are irrelevant. Granting root/admin rights to testers is only relevant if they have to perform tasks requiring such elevated rights (which might be the case for setup and configuration). And they should be aware that when tempering with the machine configuration, this may have influences on their test results and may yield reproducibility issues. Hence, not granting elevated rights should normally be the way to go.

  • In other words: Integration testers (and developpers) should have two different user accounts. The admin account is only used for rare setup/config tasks.
    – k3b
    Mar 30, 2017 at 8:52
  • Yes but the question wasn't about the good practice of not always logging in as root/admin. It was about testers having access to both those accounts when developers have access to both accounts. Mar 30, 2017 at 9:37
  • While it's true that tests should be run as a "normal" user sees the system, testing requires that assertions be performed while the test is running, and for some systems you will need root access to perform those assertions. Mar 30, 2017 at 11:44
  • DevOps considers deployment and operations to be part of the software's job. So admins who'll have to get the software running (e.g. Configuring/launching new docker container) are also some kind of the users, a kind who may need root access for carrying out their daily duties
    – Christophe
    Mar 30, 2017 at 13:28
  • Normal users use root all the time. So your software is going to be run as root. (I don't mean this is a good thing, just a fact of life.)
    – Pieter B
    Mar 30, 2017 at 14:43

DevOps integrates the full software lifecycle, including the system administration required for the operations.

As operations may include deployment and system configuration activities (including activities that require root access), some integration testers may need root access (including to test servers) in order to test the quality attributes intended for operations (e.g. operability).

Of course a system has not only operations, but also end-users. Some integration testers must therefore test that end user features work as expected (i.e. without root access: some times, things do not work as well without root access as they should, and these issues must be caught during the tests).

So in short: nothing speaks against root access for some integration testers, but something advocates that at least some integration tester have only end user access (i.e: no root access, neither on their vm nor to the server)

N.B: the fact that developers have root access or not is IMO irrelevant for the answer

  • I wouldn't say that "some testers" should or should not have root access, rather that some tests (basically all of them, really) should be done without root access. And nobody should conduct their daily business while logged in as root, they should work as a regular user with sudo privileges. Mar 30, 2017 at 7:51
  • @Michael Borgwardt: if your application have customized installers, your testers would need access to a machine with administrator privilege to test the install process. However, this probably shouldn't be root access to the tester's workstation, but rather root on a virtual machine, both to reduce the impact of abuse and because VM can be easily rolled back which is useful when testing installers.
    – Lie Ryan
    Mar 30, 2017 at 10:14
  • @MichaelBorgwardt we've been trying to fight that uphill battle, but our customers basically demand working with elevated privileges. ("Because they've always done it that way and it never was a problem.")
    – Pieter B
    Mar 30, 2017 at 14:46

I would say testers definitely need root access, more even then developers.

If you want it or not, your program is going to be run in an elevated environment. Users are just like that.

The possibilities for your software to break things in spectacular ways are much greater in an elevated then a restricted environment.

So yes, testers need root to test whether the application doesn't do naughty things while running as root.

In the end: you must test in both a restricted environment and one without restrictions.


If the majority of customers runs the software not as a root user, then the tester should not run it as a root user. There may be bugs that make your software work only as root, and you want to find that before you ship to customers.

If you suspect that some customers might run as root, you might have one machine where you run the software as root - in case the software does something stupid that is prevented by lack of privileges, but causes damage as root. On the other hand, people who run as root without a very good reason have no excuse.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.