I absolutely love Testability as a topic and to my delight, Ash Winter wrote a great post recently where he posed a series of questions – Naturally, I jumped all over these to see how my team measures up against these questions. In fact, I was a little too quick to react and came up with a score that wasn’t actually on the page (Blame the typo on Ash, not my poor reading skills).
I wanted to write this post to try and explain where I feel my team is at right now and give my answers to the questions. Some people may feel that I haven’t really answered the question correctly but I can only answer them based on my current team and in our current context.
1 – If you ask the team to change their codebase do they react positively?
For me, that all depends on what the change is you’re being asked to make and who is requesting the change. No one in the team is massively nervous about making changes to the codebase but the change has to be something that we, as a team, all agree on and believe it to be the right thing to push us forward. With any change, big or small, we will always plan it out together as a full team and walk through the changes to assess any risk that this may introduce, based on the current information and our understanding of our services. If there are gaps in the information during the walk through, we will spike ahead and try to uncover the answers to the known unknowns.
2 – Does each member of the team have access to the system source control?
I believe this is a fundamental part of being a member of a development team. In our team, as it stands today, only the Product Owner doesn’t currently have access. That’s not to say that he doesn’t because he’s not allowed, he just feels that he doesn’t really need it. Everyone apart from him has checked in “something” to source control over the last 18 months. This could be production code, a utility script or a testing tool, a JSON template for one of our monitoring Grafana dashboards etc.
3 – Does the team know which parts of the codebase are subject to the most change?
Every member of the team has been on the project from Day 1, the collaboration and communication are something that I feel we excel in. Everyone is capable of working on any aspect of the project, we identified certain silos forming early on and made changes to spread the knowledge amongst the whole team so we don’t have a single point of failure. People will always be stronger in some areas but we all have a collective understanding of the changes being made at all times. We do a 3 Amigos on every story before starting the work and as we are quite a small team this generally involves every team member so everyone knows what changes are being made to what area.
4 – Does the team collaborate regularly with teams that maintain their dependencies?
Our API was released as a pilot a few months ago to a selected amount of customers who are giving us valuable feedback, as the project matures the data available to them is becoming a lot richer, which is of benefit to the end user, we are always constantly aware that our changes are not breaking ones as the API is being used to create custom integrations. Over the last few weeks, we have picked up some internal consumers that are creating an integration based on the data we provide. This has been very collaborative and it’s awesome from a testing perspective as we get super quick feedback and can react to this and make changes where necessary.
5 – Does the team have regular contact with the users of the system?
Before the internal consumers started their integration we were only dealing with 1 or 2 main external contacts who were providing us with feedback. For me, this could have been better or more structured. The customer was based in the States so there were time zone issues to address and the general information passed back to us was hard to decipher and not clearly presented so it just ended up being a bit too much back and forth. It’s a lot better now but it could always be improved. At the end of the day, we’re creating software for our customers/end users so they should be involved as much as possible.
6 – Can you set your system into a given state to repeat a test?
This is one that I’m extremely happy with, as a tester, having the ability to control the system and put it into any state you want and at any point, is a priority. We have built Testability in from the start, there are hooks in place to stop a specific service, we can easily spin up or tear down services to get to a set point. We have also created a suite of tools to allow us to achieve many things, one favourite of mine is a tool that grabs all the events from any live interaction and replays these in a local environment as if they were happening in real time. This can be done in seconds and helps with debugging issues to get to a solution quicker.
7 – Is each member of the team able to create a disposable test environment?
We use a Vagrant development environment which is just awesome, the instructions are clear and well laid out which allows anyone in the business to bring up their own environment within a few minutes. There are a few requirements for certain applications and languages to be installed but a script has been created to pull down all of these items, this is also attached to the set of instructions. Each service has a set of rake tasks, so building the C# .Net services or the Node.js API and starting them up is just a single line in a terminal. Our team has created an events Simulator that will mimic a live Contact Centre (The core service of NewVoiceMedia) and feed these events into the locally running services. At this point the endpoints are available and requests can be made to get the data. I’ve not timed the installation but it’s pretty bloody quick to go from nothing to seeing a response from the API.
8 – Is each member of the team able to run automated unit tests?
Of course! This goes hand in hand with being able to access the source control and spinning up your own local development environment. I would have serious concerns if this wasn’t the case.
9 – Can the team test both the synchronous and asynchronous parts of their system?
This is very closely related to question 6 in my opinion, knowing what control you have over the system in order to put it into a specific state. More important than being able to test these parts, you first of all need to know where and when they occur in your system.
10 – Does each member of the team have a method of consuming the application logs from Production?
We mainly use Papertrail (we also have other tools available) to aggregate the logs (All Staging, Pre-Prod and Production environments) I have set up groups within the tool to make it easier to see what is happening on all our boxes in one central place. I’m all for consistency and the group names are the same in each environment, apart from the environment identifier. Papertrail is great at what it does but I find the UI not amazing to look at so I use a Chrome extension called Stylish to present it in a way that works for me. It just manipulates the CSS to present the page in a way that you want, I tend to use colour to show specific pieces of information.
11 – Does the team know what value the 95th percentile of response times is for their system?
We have gone a bit mental in this area, the team loves monitoring and performance based metrics. We’ve invested a lot of time and effort so that we are answering questions about the impact of increased load and stress on the services, with data rather than a best guess finger in the air measurement. Not only do we cover performance but we have also exposed the state of the resources (CPU, memory and disk space, etc.) on each box. We have multiple different Grafana boards giving us constant real time feedback.
12 – Does the team curate a living knowledge base about the system it maintains?
At NVM we use Confluence from Atlassian, each team has its own space as well as the wider department spaces. Our team has built up a wealth of information about all aspects of the project. We did this from the start to document our journey but this has grown and improved as the platform has matured. It’s full of useful information about our architecture, environments, how-to guides, team culture, deployment and release information etc. We periodically curate the content to ensure that it’s still relevant and the space is just not full of dead/redundant information.
Hope my answers provide some information about how we function as a team and gives you an insight into things that we feel are important. For things that I would add, currently, we also deploy our services to multiple regions around the world so having a team based understanding of how that all pins together is very valuable. We are still learning and growing as a team, we started out on this project with the intention of having Testability baked in from Day 1 – I personally think we’re doing pretty well but we haven’t stopped yet so maybe I will have an updated list of answers in a few months.
Any questions you would like me to answer based on my responses, please leave a comment below! Cheers for reading!
Danny Dainton 