Resourcing your project test function

When it comes to resourcing your project team it is essential you have the right roles identified as well as the right number of people for those roles. Not having the right roles will ultimately cause delays due to not having the right skills in place, too few or too many of any one role will likely result in bottlenecks resulting in delays and ultimately unnecessary additional cost. 

In this article we will be examining the Testing or Quality Assurance function as part of a digital transformation project and which steps you can take to ensure you make the right decision for your project and budget. Essentially, you want to be certain you have the right number of resources, with the right skills, sufficient test coverage and a workable testing strategy. There are many considerations to take into account and each will be discussed to understand what impacts these may have when considering your resourcing requirements for testing.

It should be noted that project resourcing is a large topic to cover and won’t be fully covered by this single article, however, additional supporting articles will follow, if you would like to be notified of when these become available then connect with us on LinkedIn, contact us via our website or email hello@nau.co.uk.  We would love to get your feedback and for you to share with us your experiences.

Project Considerations

This section covers the project specifics and how these might impact testing. The project specifics are usually defined as part of a Business Case, Project Brief or Project Initiation Document (PID) depending on the method you are following and should include the desired project approach, budgets, teams, etc. all of which will have an impact on the project’s testing function. 

Project Approach

Project approach relates to how the project will be managed and rolled out, generally this will be either Waterfall or Agile depending on what best fits the project or in some circumstances mandated by the organisation. Quite often larger digital transformation projects operate a hybrid approach taking the best ‘bits’ from both approaches, Agile for iterative development cycles and quick and often releases, whilst using Waterfall for overall governance structure and future planning for example. Choosing the right project approach or sometime known as project method is extremely important not just for resourcing but the overall success of your project. Depending on your chosen approach, test resources will either be aligned to a scrum team (Agile) or part of a resource pool that will be assigned to testing tasks throughout the project (Waterfall).

Budget

If your budget has already been agreed then obviously this will determine how many project resources (and for how long) your project can afford. There are several options available to reduce costs and these should be investigated further, for instance off-shore, near-shore, different resourcing options (internal, contractors), project scheduling, fixed cost or time and materials. Some organisations may also have a policy regarding offshoring which may limit the options.

Go-live Approach

Projects with a date dependent go-live (slippage is not an option e.g. legal obligation) or high business criticality (revenue impacting or service impacting) then building additional contingency and checks into your project is advisable. It is not advisable to rely on development and testing progress alone, but allow for additional testing in key areas such as testing of migrated data, integration testing, release dress rehearsals, data dry run(s) and extending your UAT duration. 

Solution Complexity

Consideration should be taken when assessing the level of testing required for your digital transformation project, some projects quite rightly require more testing than others. Take projects that are revenue generating or will have a direct impact on your clients, or have legal implications, or integrate to many up/downstream systems, combine that with a high-level of coding and configuration, new hosting infrastructure and with complex business change. Any of these are likely be warning signs that the amount of testing that you should consider for your project should increase. 

Other areas to consider when it comes to solution complexity:

• Data – How can the new solution be tested with data? What type of data will be required for each test and can this be automatically created? Can automation or scripting be used? Is there special skills or knowledge required to successfully test the new solution? 
• Business change – Projects that make changes to fundamental business processes should also be dealt with carefully, these changes can mean adaptations to integrations, automated and manual processes, changes to product rate cards, approval routing, etc. 

Working Model

The working model describes the teams and interaction between them, how requirements are created and priorities agreed as well as the daily ‘ways of working’ between teams to complete project work or Sprint. This also takes into consideration the team structure and capability as well as the number of project team members to fulfill the project tasks. Whilst the focus is on development and testing teams, other project functions need to be assessed included PMO (Project Management Office), business analysts, product owners and scrum masters (for Agile projects), and finally internal business teams.

Your project team, who they are and how they are organised is probably one of the most important factors in successfully delivering your project. Whether you decide or the organisation mandates teams to be onsite, remotely working, nearshore, offshore or mixture will have a significant impact on the outcome of your project, especially if you do not have the right governance and management in place. Language barriers and communication limitations can also play a significant role in the success of a project. Another consideration is that it’s likely there will be multiple teams that perform different functions, for example analysis, development and configuration and finally testing. Whichever the working model and team structure you decide will impact the number and skill level of the testing resources required for your project.

Compliance

Your digital transformation project may include compliance or legal challenges, for instance in 2018 the introduction of the General Data Protection Regulation (GDPR) for European individuals means more attention had to be given when controlling and processing personally identifiable information and includes the transfer of data outside the European Union. Obviously, other regions and countries outside of the European Union may have their compliance measures that need to be considered, failing to be compliant can result in substantial fines being imposed. Where projects involve data sensitive information more thorough testing should be considered. 

Data Migration 

Where projects require full or partial data migration it is essential the testing and ultimately the sign-off of migrated data is thoroughly covered. A project that is expected to deliver exceptional benefits will quickly fail if the data cannot be trusted. On few occasions the question of who should carry out ‘data migration testing’ has been raised; the person writing the data migration scripts, data testing resource with the relevant migration skills or the business. The only answer to this is simple…ALL should carry out a level of testing to fully satisfy and provide the confidence needed by Senior Executives that the data is fit for purpose.