Should testers have access to view developers code? What are pros and cons of this?

Question

I am working as a manual and automation tester for a financial company.

Testers in my company don't have access to the source code of our applications, we have limited access rights to our version control repositories (git). This is due to confidentiality and security obligations - a general rule says that each employee in the company should have only a minimal access to resources (information, systems etc.) which are essential to complete her work, but access to information not related to her work should be limited.

Someone has decided that testers have not needed the access to the source code to complete their work. It was long ago, at a time when we were using a waterfall model, and QA team was separated from development. But now we are transitioning to Agile, testers and devs are now combined into one scrum.

I have discussed this topic with a few developers that have worked for other companies in their careers, and they have told me that this is a "strange" rule, and testers have the access to the codebase elsewhere.

---

I am going to convince management to relax this rule and give testers at least the read-only access to the source code, and I am looking for arguments for this change - and also if there are any potential disadvantages or threats?

Some arguments for I can imagine:

• Tester can do code reviews and find some bugs directly in the code
• Tester looking at the code learns the architecture of the product, this helps her to design better test cases
• Tester can write unit tests and integration tests instead of developers
• insight into the code can help tester to better diagnose a bug
• Tester looking at the code can propose some changes that make UI automation easier
• Tester can support developers and make same small and easy changes, letting developers to stay focused on more complex things
• ...
• what else ?

Answer 1

In my personal opinions,

Pro

• White box testing is made possible by giving testers access to source code, and comprehensive testing techniques such as MC/DC testing, condition decision testing can be applied.

Questions you may need to consider:

• Is every tester working with you able to read source code? If they are able to read source code, do they want to? If you happen to be one of the few testers who are willing to take up extra responsibility, having access to source code will not have a profound impact.

• Can all testers do code review properly?

• Code review takes a long time to pay off its dividend, does your management expect short term gains? Does your management understand technical details? Does your management want to wait to see long term gains?

• Your management will be looking at major gains after they grant source code access to you, the risk they are taking is confidentiality. If there are no major gains after a while, your management may need to answer to their management regarding whether granting source code access is a correct decision? You and your management will risk losing trust if this happens.

• You mentioned I have discussed this topic with a few developers that have worked for other companies in their careers, and they have told me that this is a "strange" rule, and testers have the access to the codebase elsewhere. Please keep in mind this is their opinion during a perhaps rather casual conversation, the companies they have worked for may not have as much confidentiality as your current company. I do not think this should be a valid factor you should take into consideration.

Conclusion:

• Your approach is to improve overall quality of your software and you actively seek new ways to do it. This is exactly what QAs are for, well done!
• Without having access to source code, there are still a lot ways QAs can execute test with.
• More than you expect, most companies are more likely to limit source code access to a need-to-know basis only.

Answer 2

To answer this, I think it is better to first look into why they have code access restrictions set. The fact that it is financial software is a valid reason. Minimizing risk of a security breach by minimizing exposure to source code is very important. This is maybe not the best comprison, but if during a snow storm, you don't need to travel, don't do it, this minimizes the number of possible accidents on the road.

A few points on how to have a conversation with your company to let testers have access to source:

• agree that not every tester needs access to code (any black box type testing roles)
• company leadership needs data and stats to convince them of anything usually. analyze the list of bugs that have slipped through the development and release process and point out issues that could have been caught by white box testing
• look into what the Software Developer in Test role consists of
• in the present day, most students coming out of any computer degree have had some sort of coding training and would be able to comprehend the idea behind whatever functionality the developer is trying to cover
• from experience, a lot of questions, holes, and new test cases have been discovered when a developer walks through the code changes

Answer 3

Testers having access to the source code and testers doing code reviews are completely separate things. More often than not testers are not that technically competent and also from my experience not even all developers can do code reviews.

Having read access to the application source code is useful for testing, if you are able to read and understand code.

Also you did not mention what type of testing you are doing, is it functional black box? If that is the case you would benefit more if you liaise with the developers and ask them to tell you a few more details about the features/functionality they implemented and about how they designed things to work. That can be just a high level and not necessarily a technical discussion. If you start with that you will be able to read their code and understand the way the think without actually looking in the source code they wrote.

Hope that helps.

Answer 4

Ofcourse testers should have access to the code that is being made by the developers.

In an Agile development testing should be an parallel activity. If you have dedicated testers they should be able to add automated tests during development and or do exploratory testing on builds they build them selfs from the code.

To quote the Less framework:

Separating testing from development often leads to a conflict between programmers and testers. Testers–hunting for bugs–try to prove that part of the program is faulty. Programmers–with their ego in their code–defend themselves, their code, and the program.

In a Scrum team, ‘testers’ are no longer testers but ‘simply’ members of the team–with testing as their primary specialization . ‘Programmers’ are any members of the team who can code. Every member of the team has a shared goal and is held–as a team–accountable to that goal. Team members with different primary specializations have to cooperate in order to reach that goal.

Read more here...

If you can program you need access to the code in an Agile team, no discussion. You only have cons in not doing it.

Even security is a half-baked pro to denying access. What makes the difference between a tester and a developer security-wise? If they sit in the same room, they can steal the same stuff, with or without direct access. It is so easy to get access into someone's account and steal their code if you really want to. For example with an USB-keylogger.

I would also expect tester todo pair-programming and pair-testing on the development machines every now and then. What if the programmer goes to the toilet?

But to add some bullets to your (already pretty complete) list:

• Testers can create their own builds and explore
• Testers can be self-organising cross-functional team-members!

Just make sure you do not accept "That’s how we’ve always done it here".

Answer 5

Pros

• If you are testing safety, or other, critical code then your testing requirements will include 100% Code and Decision coverage - this is often impossible to achieve without seeing the actual code.
• The specifications which you cannot test without are usually easier to understand & steal than the actual code so confidentiality is only an issue if your code has some proprietary methods to implement what is in the specification.

Cons

• If the testers look at the code they are likely to test the code as written rather than the functionality of the code as required.

Suggestion

Many companies split the test teams into functional, (black box), testers and coverage, (grey box), testers. The divide can be based on skill set and clearance for the information contained.

Answer 6

Usually I try to win battles the postive way by proving a point, but in this case why don't you try attacking it from the other side, ask "why not ?"

Most of the big software companies I know of or worked at do not restrict READ access to the source code for people working on the product, and few exceptions like when outsourcing work to remote sites, or super secret projects.

Your managers might try and argue about the above good arguments, not because the arguments are wrong but because managers are in a habit of protecting their decisions.

Answer 7

As with so many questions, the answer is, it depends. As other people have pointed out, depending on the methodology being used, such as Agile, source code access may be a given, because there isn't supposed to be any difference between test and development. So, certainly, if you're on an Agile team, yes, you should have access to the source code, you should take part in code reviews, you should commit fixes, and so on.

However, there are tradeoffs. The sort of testing you're talking about is known as white box testing, where the tester has access to the source code, versus black box testing, where they don't. And agile development is predicated on being able to break everything down into small, consumable parts that are easy for everyone to understand, which is usually possible on a component level, but not on a system level.

If you're doing integration/system/acceptance testing, you're more interested in the behavior of the system as a whole, not on individual functions. And if you have access to the source code, there's going to be a temptation to test the source code, not the API/spec, which is what's needed. As an integration/system/acceptance tester, you don't care how individual functions work, and on a code base of any size, you aren't going to be able to understand it all anyway. What you care about is understanding use cases and expected system behavior.

And, as others have said, there are sometimes questions of trust, or legal liability, and so on. Those are business decisions, not technical ones.

Answer 8

"Agile values working code over comprehensive documentation". If the testers don't have a comprehensive, up to date spec, they need to see the code. If testers don't get accurate statements of what has changed in each revision of the spec, they need to diff the code.