Starting up a Software Quality Assurance (SQA) team: A nearshore alternative
By Marco Roman, Business Development Manager at e-Core
Eduardo Anflor, Team Lead at e-Core, contributed to this article.
Software quality assurance is a crucial part of building software and having access to a pool of talented resources and being able to scale at a faster pace with cost efficiency are some of the challenges software vendors usually face. Starting up a nearshore project is a convenient path that such companies can take to address these challenges.
Choosing a business partner is a decision of great importance due to the number of factors that need be considered such as culture fit, alignment between partners and also between staff, management of distributed teams, delivery models, required skills, costs, service provider’s expertise, existence of established processes and environment that can enable future growth in a sustainable way, etc.
For quality assurance engagements it is not different and although each new initiative has its own particularities and challenges the experience of setting up and growing multiple QA teams at e-Core show us lessons that can be applied to standardize and reduce the complexity and costs of building successful teams.
For simplicity and experimental reasons an engagement usually starts as a small team of 1-3 people that might grow into a bigger team. At this stage sometimes team members have to occasionally wear different hats so good time management and planning skills are required. When forming a team a higher level of seniority and leadership is recommended as this is usually a time when many important decisions take place.
The ability of using a standardized approach for clarifying the inherent uncertainty of a new engagement, exchanging information between parties and also defining clear requirements and goals are important pillars for the success of the latter execution phase.
Expanding an existing team or building one from scratch
For a vendor is paramount to have solid understanding and adherence to partner’s business rules, systems and processes and having a good training methodology in place can help with that. It might be the case that there is already an established quality program with systems and processes in place (e.g. when a new branch of a team is being built) or perhaps there is nothing in place and the team should start from scratch.
Each of these brings a different set of responsibilities ranging from, in the first case, learning the tools and processes, using the existing expertise to extract the maximum out of it and being able to suggest improvements or, in the second case, being able to define the whole structure and process, conduct studies and understand the trade-offs (e.g. initial setup vs long-term costs for implementation and execution, budget constraints, benefits and disadvantages) between different technologies.
A typical output of both approaches is what is usually called a strategy guide: a document containing details of all the agreements between parties and project plans i.e. how will everything work, what are the standards, responsibilities, risks and mitigation plans, among other relevant details. It is considered one of the most important artifacts when a project starts and it can be used as a future reference being revised later if anything changes.
Defining stages for a software quality assurance project
Let’s consider some common stages to exemplify how starting a quality assurance engagement would typically work after a team is set up:
- Definition: It’s time to define the scope of the quality assurance activities: such as the final list of testing modules and scripts as well as the expected deadlines. Define the manual testing approach, what parts could be feasible to automation and when to do it or not (i.e. are the procedures standardized? How rapidly does it change? Should it evolve through manual iterations a little longer before being automated?).
- Test creation: Create test cases or scripts, make use of review techniques such as peer review, create test suite prior to execution for easily visualizing and communicating the proposed testing coverage. Documentation plays and important role here and should not be overlooked, especially the ones related to requirements or business rules.
- Execution: Execute the tests and keep the history of its execution with details such as time, which of them
- passed/failed or were (or not) executed.
It is very important to maintain and review these records with breakdown by releases or by sprints, for example, as they can provide useful information when reporting the defined metrics. Ensuring the team is working with the right testing tools allows you to have the best performance and makes the difference in terms of deliverables.
- Bug tracking and reporting: Use standardized and documented practices for reporting bugs. Tie them to the related test cases and requirements so you have a good understanding and tracking of the whole testing coverage process. Use well known tools like Atlassian JIRA to help you with that.
- Reporting metrics: Each engagement needs to have a well-defined set of indicators to be observed such as defects by status, severity or functional area. You can also report testing coverage based on how many scenarios are being covered on your test cases and test progress based on the execution status. Once each cycle is finished it is important to review and report on the defined metrics so after raw data analysis we know what happened, what are the bottlenecks, major defect incidences, application performance details, etc. and data-driven decisions can be made.
- Feedback cycle: An important step throughout the whole process is comprised of the feedback cycle between partners and also between staff to ensure high cohesion and alignment between teams. Post-release reviews, quarterly engagement surveys and frequent direct and honest feedback are just three ways of making sure high customer satisfaction standards are being met.
- Communicate: Each company has its own preferences regarding communication pace and format. It is important that everyone is on the same page since the first stages of a project and using existing practices and devices such as video-conference and tools like GoToMeeting, Skype and Google Hangout on a regular basis can ensure important information is shared with the relevant groups.
Software testing services are good candidates to be performed by independent groups responsible for auditing and certifying the software. A nearshore quality assurance project implemented using best practices and highly qualified personnel can generate high value-added solutions and help to solve the highlighted problems of scaling software development operations with competitive costs.
The Atlassian Marketplace is a portal that provides access to many apps that will optmize tools that you use, like Jira, Confluence, Bamboo and others. In addition, you can differentiate yourself by your integration potential. It allows customers to discover and...
We know that at the time of purchase and / or renewal of licenses of Jira, Confluence or other Atlassian tool, some doubts arise. In an effort to help you solve some of them, we've chosen the key issues we're addressing at the moment. Are additional licenses required...
Understand the benefits of purchasing licenses with an Atlassian Platinum Partner and make it easier for your to obtain tools like Jira, Confluence and Marketplace Apps.