Introducing a QA team into a software development lifecycle (SDLC) usually starts with initial knowledge transfer phase that may take from a week up to a couple of months. By default, knowledge transfer phase duration depends on two significant factors:
- Development phase – QA team that starts it work simultaneously with development team requires less effort to get on board in comparison with the latest project phases, when the requirements are partly outdated due to changes in technical decisions or business priorities.
- Project and domain/area complexity – providing QA for typical end users’ products (e.g., social networks or shop sites) doesn’t require long period of team adaptation in comparison with complex business solutions.
However, there is another factor to consider – process adaptation. I’d like to cover this aspect based on Agile environment (Scrum in particular). According to A1QA experience with more than 100 projects completed using Scrum, there are three significant issues each team faces:
1. Development team has never worked with QA professionals before
Scrum suggests that Agile teams should be cross-functional. And most of the development teams try to follow the rule establishing Agile techniques. After a while they encounter two major problems:
a) Developers are not good enough in testing and miss obvious defects or spend too much time, and b) developers are demotivated by doing the job, they are not interested in. Having a cross-functional team has its own benefits and the most considerable is a feeling of responsibility. However, imagine that you need a cardio surgery. At a hospital they say it will be performed by a dentist explaining that their team is 100% cross-functional. Would you take this risk?
For most companies, the only solution is to introduce a professional QA team. Introducing a QA team in most cases will affect the established process familiar to everyone, e.g., defect management should be introduced together with other QA activities that are often neglected in cross functional teams. To avoid misunderstanding and conflicts, a QA team should be eager to introduce changes and reason them.
A1QA also advises to set up training sessions for development and management to give an understanding when, why, and for sure, how QA works. Regular (informal) Q&A by QA (Questions and Answers by Quality Assurance) sessions are a very popular way to get adevelopment team involved in what QA engineers are doing. And of course, a QA team should become a part of a project team doing Sprint Plannings, Scrum meetings, and Retrospectives accepting responsibility for team success or failure.
2. Development or QA team has no experience working Agile
Agile is called Agile for its flexibility in rules and regulations. Scrum is usually considered to be easy to adopt and follow, especially considering other methodologies like RUP. At the same time, to be effective in Agile the team should spend at least 2-3 full Sprints to get accustomed to the speed and process, to understand the best practices, to feel the team responsibility, and to get used to each other.
The most effective Agile teams are those that have been working with no staff changes for 3+ months. During this timeframe a team will go through some successful and unacceptable sprints, define their own velocity, get more familiar with estimates and risks based on their team experience. A good practice is to have at least 50% of the team members who have been working in Agile before.
They may give a hand to newcomers, share the knowledge and expertise. A1QA try to balance Agile teams starting with at least 75% of Scrum-guru-s and keeping teams unchanged for 6 months and more. We also do an introductory training in Scrum for all team members who are joining A1QA team as well as for development teams.
3. Communication aspect. Another default rule in Scrum is team co-location
The world is changing introducing globalization into everything (and cloud computing is a good sample for IT). Communication is still a very important part within the scrum team. Normally, Scrum meetings should be held in one room, where everyone should stand up and provide their update to the team.
For distributed teams we use the same approach but different tools – team has daily Scrum meetings using Skype, GoToMeeting, or polycom. Therefore, the process itself stays the same, while the tools change.
To cut a long story short, involving QA team in Agile process is challenging. Nevertheless, consider the benefits you get – high quality product, happy customers, time to market reduction, costs optimization and effective developers.