Team Organization 

How a delivery team is organized impacts multiple aspects, and the ultimate success, of any strategy meant to provide deliverables according to a given timeline. This presents a unique challenge within the QA space as we frequently find ourselves having to align with timelines that are set based on business goals. These timelines are then further constrained based on the ability of development teams to deliver with enough lead time for the proper depth and scope of testing to guarantee the highest level of quality. In order to meet these timelines within the aforementioned constraints automation of regression tests becomes critical. An ability to execute regression testing at will and on a set schedule allows for better functional coverage and for manual testing efforts to be focused on new feature sets.

The question frequently asked when considering automated testing is, ‘How does the addition of automated testing and its associated resources change the composition of a QA Team and how does it impact the ability of that team to deliver?’

 

Approaches

Below are three approaches to team organization that answer that question by providing any assumptions made and the conceptual description of the approach. Each approach builds on the previous and utilizes the same phased implementation pattern detailed after this section under ‘Implementation’.

 

Bolt-on

Assumptions

  • Manual testing resources exist and are integrated into the development team and their cadence.

 

Concept

The bolt-on approach is exactly what the name implies. We are creating a separate set of resources and processes outside of the existing integrated QA/Development team and ‘bolting’ them on in order to design, implement and maintain an automated testing solution. This can be a temporary or permanent group depending on the strategic goals of the organization and is further explained in the ‘Implementation’ section.

 

Augment

Assumptions

  • Manual testing resources exist and are integrated into the development team and their cadence.
  • Manual testing resources are lean and having floating resources that can assist at times would be beneficial

 

Concept

Augment expands on the ‘Bolt-On’ approach by creating a separate set of resources and processes outside of the existing integrated QA/Development team and ‘bolting’ them on in order to design, implement and maintain the automated testing solutions. Once the automation group is established and their cadence is set, cross-training of automation group and manual testing resources can begin. The cross training and task sharing are central to the ‘Augment’ approach, this allows for knowledge transfer and the ability to ramp teams up and down to meet periodic needs for increased velocity.

 

Shared Service

Assumptions

  • Multiple applications exist, each with its own dedicated team of manual testers
  • Manual testing resources exist and are integrated into the development team and their cadence.

 

Concept

Shared Service is similar to ‘Bolt-On’ in that we are still creating a separate set of resources and processes outside of the existing integrated QA/Development team and ‘bolting’ them on in order to design, implement and maintain an automated testing solution. The difference, in this case, is that instead of a single application being targeted, we are targeting multiple applications across an organization and treating automation as a service that can be deployed in a more strategic manner as new applications are brought online. Additionally, a centralized set of resources dedicated to automated testing can be used to inform the design and implementation processes in order to make applications more testable as well as assisting groups such as Information Security and Network Infrastructure teams to develop automated testing and monitoring tools to support areas outside traditional QA roles. Beyond utilizing automated testing in non-traditional roles we can further embed the automation group and provide value at an organizational level by integrating the cross-training of resources from the ‘Augment’ approach.

 

Implementation

Implementing the bolt-on approach involves three phases with the third being different depending on whether the automation group is part of a permanent solution or part of a temporary solution.

 

Phase 1: Discovery

Phase 1 involves meetings with the existing manual testing team, project managers or scrum masters and other team level stakeholders to identify the following:

  • Any test plans that currently exist
    • Ideally, there should be, at minimum, a manual regression test plan
    • Are they housed in a test management solution? If not, how will changes to the existing tests be communicated to the automation team to maintain the accuracy
  • What technologies are involved in the solution being tested
  • What is the environmental landscape of the solution being tested
    • Example: Solution is a web application

Do they have QA, Staging and Production environments?

The phase one deliverables are largely consumed by the resources assigned to phase two in the form of guiding points that dictate the tools and methodologies to be used to create the regression test solution.

NOTE: Keep in mind this is not an exhaustive list and is meant to help start and guide the conversation.

 

Phase 2: Design and Implementation

This phase comprises the bulk of the time and effort for the automation group. Using the information gathered in phase one the automation group will identify the tooling, design patterns, and methodologies that are the best fit for the solution and the organization. One thing to keep in mind is the tools not only have to fit the solution being tested they also have to fall within the organization’s technology stack, workforce skillset, and security guidelines. Following this same line of logic, every effort should be made to engage an organization’s Information Security and Architectural leadership during the design portion to gain all necessary approvals and avoid rework associated with concerns from those groups when they exist.

 

For example:

  • Open source tooling with a low industry adoption rate may not be acceptable within a security-minded organization or one that deals with sensitive data such as payment systems or within healthcare systems.
  • Organizations heavily invested in a given tech ecosystems such as the Microsoft .NET stack will need a compelling argument to adopt solutions based on Java or requiring hardware platforms manufactured by Apple.

 

Once the design is completed and any approvals that are needed have been obtained implementation can begin. During this portion of phase two expectations should be carefully managed and communication with the existing QA/Development team leadership should be frequent in order to facilitate resolutions to any issues encountered. In order to show value and provide impact for the organization as tests are completed, they should be incorporated into the dev/testing cycles too, initially, help instill confidence in the tooling and help reduce the manual effort.

 

NOTE: If the solution being implemented is a coded solution, i.e. Selenium-based for web applications, gated check-ins with code reviews should be utilized to maintain consistency and adherence to development principles.

 

Phase 3:

This section is forked based on whether the automation group is meant as a permanent or temporary solution.

The ‘Temporary’ section applies to the ‘Bolt-On’ approach

 

Temporary: Handoff and Training

In cases where the automation group was formed as a temporary team to create a test solution and then either be released, in the case of contractors, or return to their assigned teams, in the case of resource pools, there must be a period of handoff and training with the responsible parties to set them up for success. This period should include the following:

  • Knowledge sharing sessions
    • One of the more effective methods of knowledge sharing is to have the automation group embed with the responsible parties for a sprint or cycle for hands-on implementation
  • Detailed design documentation
  • How to documentation
  • Repository of resources that were used to create the solution

 

Permanent: Maintenance

In cases where the automation group was formed as a permanent team, phase three sees a ramp down inactivity and a transition into maintaining and expanding the tests and capabilities of the automation solution. Alongside maintenance and expansion comes the opportunity to utilize the team, and potentially the solution, to provide automated testing for additional QA/Dev groups and their solutions.  This phase should include the development of a similar set of artifacts targeted at reducing knowledge gaps and making all resources subject matter experts by producing, at minimum the following:

  • Detailed design documentation
  • How to documentation
  • Repository of resources that were used to create the solution

The creation and maintenance of these artifacts will not only serve as a reference for existing resources, they will also fill the role of training materials for new resources and reduce the loss of subject expertise in times of turnover.

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *