top of page
  • Writer's pictureCraig Risi

Transitioning non-technical teams to be technical – Part 4 - Measuring success and continued change


Now any transition would not be possible, if it were not able to measure how you are performing in that transition. You can put systems in place to get there, but unless you can actually measure these you will never know how well you are doing in this regard and whether anything needs to be changed to better adapt to the planned transition.


The secret to this though is knowing what an end-goal might look like and, indeed, even if one can easily be defined as all, because in a world of continuous improvement, that goal post is constantly moving and evolving. So what and how do we measure progress to ensure we are moving in the right direction with regards to technical testing?


Well, the following areas should provide some good perspective in the journey, though are by no means the only things to look at and serve as more of a guide than anything else. And this is not simply just a check sheet to ensure your team is moving through the required training sections of some plan, but rather a way of looking at actual contributions towards technical testing. It's also not an exhaustive list of things to look at, but simply a guideline to help you along the way. Your teams may have different inefficiencies or issues that you may want to measure separately that will help determine you are moving in the right direction


Activity in code repositories and growth of code coverage

I guess the easiest way to often tell that your team is starting to get more involved in technical testing is by seeing an increase of activity in automated scripting across your code repositories. It’s easy to increase activity though without adding value, so this need to be paired with an increase of actual code coverage. While code coverage is not a perfect metrics, its growth does show that not only are your testing covering more through their tests, but considering code coverage is best measured in the build cycle, ensuring that these tests are getting automated at a lower level, which is effectively what you want.


Reduction in regression time

With an increase in test automation, the amount of time to regression test will naturally come down. However, this is not just to ensure automation, but also whether your testers are getting involved earlier in the build process. The more effort spent on unit tests and mocked environments reduces the need to have a regression phase in the first place and is again another indication that your team is transitioning to technical testing.


Increased number of production deployments and reduced development cycles

Not only should a more technical testing team help in the design of more efficient and testable software and creating automation suites that reduce regression effort but they will also remove barriers of dependencies that allow teams to release to production more often. This will obviously look different depending on the size of the company and team, because some companies can generally release to production quite quickly as they operate mostly independently. Most companies making the transition to technical testing though tend to be big corporates with complex systems that make release to production independently difficult. Technical testers will help remove these through design and mocking systems and you should be able to measure this by the increase in productivity and production deployments that are evident.


Improved communication and reduce requirement defects

This might be a little bit of a surprise because highly technical people are typically associated with introvertedness and an unwillingness to communicate, but that’s only because we mistake communication for communicating more. Communicating well is actually all about efficiency and a lot of the lost time that occurs in software development is in translating business wants into technical needs. As testers play a vital role in ensuring the quality of both the requirements and system stay in check, an improvement in their technical understanding actually makes them more efficient at doing this. They will more immediately understand how the system work, therefore being able to help analysts and developers design the right systems with less need for rework.


Another aspect or benefit that comes from this is that testing is thought about in the design process and means that testers can ensure this gets documented and designed right early on, further adding to the efficiency and proving why measuring this helps to measure if you are moving in the right direction. Software quality is also about defect prevention more than defect discovery and technical testing is where you see this best come into effect.


Reduction in defect turnaround

It’s not all about just building and testing software, but also fixing it. Technical testers are more than likely to not only find defects, but identify what might be causing them as they understand the system more intimately. They can do this by either making better sense of the different log files or perhaps even understanding the underlying code and system configuration and you should tart noticing these things coming down as your team evolves.


Increase in tech people apply to work for you

Lastly and perhaps less measurable, but still easily noticeable is that you will naturally know you are moving in the right direction by the type of talent you are attracting. Technical teams attract technical people and if you notice an increase in highly skilled people from other big tech or start-up companies all of a sudden interested in working for you – then you are doing something right. It also helps to ensure that your future pipeline remains strong and sets you up for the future.


So you see, transitioning to technical testing, is not just a smart move in response to a changing industry, but almost a key point to future survival for many companies and so there really is no reason not to move in this direction. Now, just measuring these metrics doesn’t mean you will get there, as you will more than likely struggle in certain of these areas and some take a long time to get it right. As long as you know where your growth areas are though, you can continue to develop and improve. 

0 comments

Comentarios


Thanks for subscribing!

bottom of page