The most common structure inside a Software Development project is a development team (DEV), quality assurance team (QA), business team (BA), and project management team (PM). As you may know, ideally a team is conformed around 5 to 10 team members and, something really common in this kind of team, is that we have people from around the world with different ways of thinking, expertise, and culture, so, one of the biggest questions is, how we are going to align the team on getting the things done? The easy answer is: with a team-defined Quality Strategy (QS).
To be able to define a good QS with the team there are several things that we need to understand first:
- QS is not the same as a Testing Strategy or Testing Pyramid
- QS is a Critical Quality Agreement between the people that are going to be involved in the team
- QS is a living document that is guided by a QA champion but it can be updated for any team member
Now that we have a basic idea of what is a QS we need to think about “Which are the critical quality agreements that will help my team?”, based on this, we will discover that this document doesn´t have a common structure and that it will change based on the team necessities but, we can define some usual topics that are discussed in here, for example:
- Ways of working (Agile practices that the team will perform)
- Effort Measurement
- Path to Production & Roles and Responsibilities
- Definition of Ready
- Definition of Done
- Risks
- Testing Strategy
- Bug management process
As you may notice, these topics are open to having their own article but we will try to give you an idea of what all of these means:
Ways of working (Agile practices that the team will perform)
The most critical alignment that we need to get an agreement in the team is the development methodology that we are going to use inside our team, the most common is to use Agile practices, as the name says, agile means that we are going to define what are the best practices that we can add on our daily work and how to adapt them to our necessities, for example, we can define that we are going to perform 20 min daily, we are going to have Sprint planning every 3 weeks because the Sprint will last 3 weeks long, we can define things like Retrospectives, when to execute a postmortem meet, which will run the daily, when to do a demo and so many things that will guide us based on how we want to work and the availability of each team member.
Effort Measurements
This agreement between the team is about, how we are going to estimate the effort that will cost for the coming tasks, the most common way to measure the effort of a story (in agile practices) is with Story points, which means that we are going to define what does a 1, 2, 3, 5, 7, etc. Represent inside our team, also, need to understand what will be the best approach when we have a task with points like 13, we can try to split them, or let 2 team members work on that task.
Path to Production & Roles and Responsibilities
Here we are going to define how we plan to get things done inside our team, usually, this takes many hours that can be split into different sessions, most of the common things that we will define is what is the lifecycle of a story inside our team, we define things like where a business necessity could come from (business new requirement, stakeholder necessity, improvement the infrastructure, code refactoring, technical changes), who are the responsible to get the necessity transformed into a story (for example, tres amigos method to have three different points of view and try to get the most of the considerations), how we will construct our kanban board (here we can also consider the different testing environments), which columns we are going to define in here, what are the process to deploying the new develop or fix to prod (CI/CD) and how we are going to let the business know about our progress, we need to consider that, inside on each step that we are defining we need to have the responsibility of them based on the roles that we have inside our team, also, is a good idea to get the expectations that every teammate have on the different roles that the team is conformed so we can properly be aware to who is the champion of what specific task
Definition of Ready
This concept is used to understand when a specific task is ready to be picked and developed by the team, we can have our definition of ready that the task has already been reviewed, approved, and estimated by the team so it is ready to be added to our next Sprint in the To-Do column, also, we can add a Story structure that will help to guide the team, we can add thing like Purpose of the story, Examples on how the system should behave after the development, Out of the scope, etc. We can also keep in mind things like our Kaban board and the different testing environments, we can define what means for us that something is ready in QA environments, or in UAT environments.
Definition of Done
The difference in this concept is that here we can understand when a task has completely gone through all of our development processes, has been developed, tested, accepted by the customer or stakeholders, and also is already deployed on production, of course, this applies when we develop something that will be deployed in prod, we can also develop artifacts or libraries to be used for the organization itself so things like being approved or deployed can be modified.
Risks
This is more like a knowledge-based thing to understand what are the risks that can affect our deadlines, for example, common things that need to be considered are holidays, sick leaves, changes on the task, dependencies on other teams' development, etc.
The main objective is to recognize what can affect us as a team and how we can try to mitigate this to make us more reliable, always keep in mind that a risk is something that we can just mitigate but not remove from our project.
Testing Strategy
We always need to keep in mind that testing is not performed to catch bugs, is created to prevent them before it arrives in our system, here we can define with the team what are the different testing practices and methodologies that we are going to apply to our project, we should always try to use the most common testing approaches: static testing and dynamic testing.
Static testing is related to performing tests without using the system, the main question is, how can we test that something is working without using it? and the answer is with documentation, one of the testing principles is related to having working software over extensive documentation, the word “over” doesn't mean instead, so we also use documentation in agile but with a different shape like stories, bugs, epics, etc. One common approach to static testing is the Shift Left testing approach, to start from the very beginning of the concept of the business necessity that will be transformed into a Story or Task and analyze that we have added a common understanding of what needs to be the expected result, for example by using the Specification by Example method. Keep in mind that these static tests can be performed by anyone on the team.
Dynamic testing is the most common method performed by all the development teams, usually, some different testing approaches that we have here are used to define the testing pyramid that the team will use, the two main techniques are White Box Testing and Black Box Testing
White box testing is performed by the dev team because they have the knowledge about what is happening inside the code so they can provide unit tests for each module and/or integration tests between the different modules and define the percentage of code to be covered with this type of test to give us the assurance that, internally talking, the functions and methods are not being affected by new or refactored code.
Black box testing is performed by the QA team to validate that the new or fixed code matches the functionalities that we have defined in the stories, we can perform functional tests for this, also there are more types of testing that will help us to confirm the correct behavior of the system in different types of level, we have end-to-end tests (to confirm that the whole path that the teams develop is working as expected), exploratory testing (using a good knowledge of the system behavior, understand what are the code changes to review if any other functionality was affected by it), user acceptance tests (to confirm with the stakeholders that the system is doing what they were expecting), smoke test (to confirm that the new deployment hasn’t affected any of the main or most used functionalities by the customers), etc. We can also consider that we can add automated test scripts to avoid having a huge amount of repetitive manual tests and improve the performance and time of the QA people
Bug Management Process
This helps us understand what is considered a bug and how we will resolve it, usually, a bug is something that we found on production, so we need to report it to be analyzed, and based on that we can create a ticket, a common structure to report a bug is:
- Steps to reproduce it (with images or a video)
- Current Behavior
- Expected behavior
We need to consider that, if we find something that is not working correctly but is still not in production, means that we can negotiate with the developer to move the tasks again to the To-Do column so we can discuss with the team what is missing to define in the ticket.
As you can see before, a Quality Strategy provides critical agreements that teams usually tend to take as granted that everybody has the same ways of interpreting things thus the team will have the same ways of working, is a good practice that any of the QA takes the lead on defining all of these aspects inside the team so we can have a common understanding between everyone and avoid having disagreements with processes that are already in place, also with these agreements embodied in a document, we can be sure that any new team member will be able to understand and adhere to them, so keep that in mind, this document is handled and maintained by the whole team, we do have a champion, but this person is not the one who will decide all the QA aspects that need to be defined, and last but not least, remember that this is a living document, this will change based on team changes, team new members, business necessities, etc.
Top comments (0)