Enterprise Boozang: Team support and access policy
In this article we do a deep-dive on Team work support in Boozang. We talk about why web-based solutions are ideal for team collaboration, and discuss best-practices around access policy.
One of the advantages with running a Cloud-based solution as opposed to desktop software, is that team collaboration becomes much easier. Even though some desktop tools, that requires local installation, have collaboration capabilities, it is never quite as good as fully web-based solutions.
Boozang is truly a web-based solution. The Boozang extension is only 30 KB large, meaning that the vast majority of the functional code is all dynamically loaded from the Cloud.
Doing this opens up for great team-work functionality, including
- Representation of tests as URLs
- Instant test sharing
- Collaboration, semaphores (locks)
- Fine-grained access policy
Let’s dive into some of the teamwork functionality of Boozang.
The Team View
The team view can be accessed directly from the IDE or from the management interface. For most purposes, simply click on the “Team” icon from the IDE. Here you can invite team members to the project and select a number of pre-defined roles.
To invite a new member to the team, simply enter an email and the team member role. The new member will get an invitation email, and as soon as the team member confirms, they can be a productive member of the team from day 1.
Test Representation and Sharing
In Boozang, all tests are completely maintained in the Cloud, and loaded on-the-fly in the browser. If you go into any test in Boozang and study the URL you can see that each test has a unique URL.
http://ai.boozang.com/extension?id=5f09ea102d175d4361005148#5f09ea102d175d4361005148/master/m12/t1/actions
As you can see, the URL is comprised of
- Branch: master
- Module id: m12
- Test id: t1
In order to share a test with a team member, simply copy the URL from the browser window.
Remember: If you have the test and module id, a test can be found by using the search and simply typing the module and test id separated by a “.” (module m22, test t3 -> Search: m22.t3).
You can also create a sharable URL by using the function “Generate tokenized URL”. You will have to enter your password to generate this, as the URL contains you user credentials.
If you access this tokenized URL in a browser, it will automatically log you in as the user that generated the URL. Also, the URL will have a few more components
http://ai.boozang.com/extension?token=c3f72763aec4580d8f4c79e6ac7517c65f09ea102d175d4361005152&env=0#5f09ea102d175d4361005148/master/m12/t1/run
As you can see, there are two more parameters
- Token: Secret access token for authentication
- Env: The environment id
This will allow you to reference any of your tests directly from the CI server. Note that by changing the token, you can change the user which is running the tests (we recommend having a CI user setup for the project with read-only permissions).
Note that you can also simply change the environment id parameter to switch between execution environments (going from pre-prod to staging, for instance).
Collaboration and locks
Since Boozang 5.x we have implemented auto-saving. This means it’s usually seamless to work several people on the same project. In some cases, when you want to make sure that no-one else is modifying a test while you are working on it, you can lock it.
Simply click the “Lock”icon to make sure no-one else can edit the test. In the below picture you can see a test from the perspective of the person locking the test (left) and another team member accessing the same test (right).
As we want to make sure the team stays productive, any team member can force the lock by clicking on the “red lock” to enable editing the test.
Access Policy
In Boozang we also have access policy based on roles. In the team view in the IDE you can assign new team members to a certain pre-defined role. In order to further customize the access right for an individual user, you’ll need to access the project from the management view.
We support the following pre-defined roles
- Owner: All permissions, including inviting team members
- CI: Read-only user for CI execution
- Viewer: Same as CI
- Developer: Create tests
- QA: Create tests and TRs (trouble tickets)
- Architect: Create modules and tests + edit project settings
- Team Leader: Create modules and tests
The access policy is done directly in the data model, and can be a little abstract to grasp. We support a number of pre-defined roles with a certain sets of access In the IDE view you can customize these down to a single policy. Here is an explanation of some of the policies
Version System management:
- Modify version settings
- Import data
User System management
- Modify team user setting
- Add team user
- Modify team user setting
- Remove user from team
- Import user
Project System management
- Modify project
- Email the Fragment to Team member
- Export data
Version settings means all settings except user preferences. This might be counter-intuitive, but makes sense from a data model perspective. By storing most settings on version (branch) level, it allows for branches to maintain different settings, which is usually desirable.
There is also a column call “self-control”, that means control (edit, delete) to items that the user has created. Use this to divide up access rights between modules. Let the owner of a module create it, add “self-control”, and revoke edit and delete privileges for all team members. This way, only the team member that created the module can edit it, and other team members will have read-only access.
Audit log
In working on a project it is sometimes useful to know who did what. There are a couple of reason where this might come in handy
- Track who is working on what in the team
- Find out who edited a test that is now broken (blame!)
This functionality can be very powerful in understanding project evolution, but can also be a policing tool. We encourage you to use it to allow the team to work as freely as possible, allowing for learning opportunities and mistakes to be made. This allows for a highly trusted environment, where everyone can change anything, as changes can be traced.
Conclusion
Having a Cloud-based test automation platform offers many advantages in terms of collaboration. Boozang offers up ways to limit access right for different team roles to prevent mis-use and protect project integrity. Remember that having a trusted team where everyone has full access is not necessarily a bad thing, and even though we support granular access levels, we encourage you to use this functionality with caution.
Introducing too much red tape often stifles productivity, and it’s usually better to give the team a lot of power, and full accountability. As a general recommendation we believe it’s good practice to allow anyone to change anything in the project!
