How to protect PROD from bugs and yourself from stress
Today I want to talk about bugs in PROD and how to protect the team from this, because implementation requires the help of the entire team in building software development processes. The wonderful title of this article speaks for itself – if you can’t protect your team from bugs, then you can definitely protect yourself from stress, because not everything depends on QA.
Chapter 1: SOFTWARE DEVELOPMENT METHODOLOGY
Before we begin to dive into the discussion that testing is just a comparison of EO and DF, it is necessary to display the software development methodology. In our case – Agile.
Step 1. Idea
The first step in development is an idea, something that we really want to implement in our product. This could be a new feature, a revision of an old feature, or a major update that affects old functionality and adds new features to the software.
An interesting question is who brings the idea to the product?
I present to your attention the main roles in the IT team:
Product Owner communicates with the customer and is the link between business and development. The main product areas of the team are supervised by the Product Owner. The main ideas and directions of the product follow from it.
Systems Analyst is the main source of specifications and the regulatory element of documentation in the team. A systems analyst prescribes technical requirements for the implementation of certain product functions. Based on these requirements, test scenarios are compiled.
Development team – Frontend, Backend, Testing and Support are the mechanism that brings ideas to life with the help of specifications, technical. requirements and their professional competencies. During the development phase, front and back may adjust specifications after the analyst due to inaccurate requirements or to optimize the product. When testing usability, QA can introduce new ideas to the product, agreeing on them with the analyst or product owner.
Each team member can contribute ideas, and the most important thing is to document the changes so that when testing there is an accurate understanding of the expected and actual results.
Step 2. Analytics
As I already wrote above about the systems analyst, he is the source of all those. requirements and specifications. The analyst prescribes specific requirements that need to be implemented at the front and back in order for the new function to appear first on the dev stand and then fall into the hands of users. At this stage of tech. requirements are not finite. The development team has not yet started implementation and adjustments to the documentation may also be made later.
Step 3. Development
The front and back take tasks into a sprint and get to work. As a rule, on the back it is necessary to complete tasks first and only the front field is pulled up to the answers from the database. But there are also exceptions in the form of implementing the front with mocks (stubs), which imitate the response from the back and are then replaced.
Step 4: Testing
The most interesting thing is to accept the work of the developers and test the software with already written test cases and checklists. Test documentation is written at the stage when technical requirements arise from a system analyst or product owner. Test cases are most likely already outdated, because requirements changed during the development stage. And therefore, when testing functionality, we study adjustments to the specifications and update our tests during testing. This is Agile 🙂
Sometimes it is not possible to test the functionality, because… The back is ready, but there are no buttons or UI on the front. In this case, you can postpone tasks and wait for the front. An important condition is that the tasks must be in one sprint; if the front will complete the task only in the next sprint, then it makes sense to test the API, for example, and record the intermediate result in the comments.
Step 5. Release (Support)
The release involves regression testing at different stands until we get to the PROD itself.
For example, there is a local DEV stand – a stand where developers code and implement features. After the changes are made from DEV, they are uploaded to the test bench, where QA actually tests from step 4. After successful testing, all changes are released, but we cannot implement the changes directly to the final product, which the client is already using. For now, we are uploading everything from the test bench to the release one and also testing regression and all changes in the service. There can be many test benches and each one is responsible for testing something 🙂
Chapter 2: RISKS
Now we will highlight the steps where bugs may occur or it may not be a bug at all, but simply the customer meant “other”!
It is important to highlight that a bug means a difference between the expected result and the actual one. We expected that when we press button A, window B would appear, but something completely different happens. The diagram above shows the risks of not only the appearance of a bug, but also unforeseen errors in the form of the program not making it better, but only making it more difficult to use.
First risk: The idea gets to the analyst
Product owner and analyst at the technical design stage. requirements may incorrectly describe the logic of the new functionality (flow). The customer had one thing in mind, but in the end the specifications stated something completely different. The solution to this problem may depend on the rules of interaction with the customer in your team.
Does the customer need to put proposals in writing with precise descriptions? The responsibility for this risk lies on the shoulders of the product owner and he, in turn, can make communication with the customer more transparent for the team.
The goal is to include the development team in the process of introducing new functions and changes at the stage of the idea (before writing technical requirements). QA can comment on the ease of use of new functionality and even help optimize the flow. This is easier and cheaper to do before the development stage than after.
In each team, back and front developers react differently to business goals; it is important to find out their opinion at the PBR (grooming) stage, where the task is assessed before it is taken into the sprint. By this time, the first version of the technical requirements will have already been written by the analyst, but correcting it will not be critical.
Second risk: development according to technical requirements. requirements
Frontend and Backend developers take tasks from the backlog into the sprint, but the task may have outdated documentation attached, or it may not exist at all.
Write this without knowing what, implement it this way without knowing how.
This development model is often encountered – when responsibility falls only on the developer, bypassing the product owner and analysts. This is sad and in this case they will help DOR And DOR.
Definition of Ready is the criteria for readiness to take a task into development, that is, DOR is the conditions under which the task can fall into the sprint. The team chooses its own criteria and adheres to them. For example: the analytics have been written, there are exact technical requirements, etc.
Definition of Done is the criteria for completing a task, that is, the conditions after which the completed task goes into testing by QA.
Third risk: Frontend and Backend perform tasks out of sync
By synchronous execution of a task, I mean that tasks on the front and back will be completed in at least one sprint. Why is this critical? As I described above, technical requirements tend to be adjusted at the development stage, and if one developer took a task in one sprint and adjusted the implementation on his side, then the second developer can complete the task according to outdated requirements.
The risk depends on the interaction of developers with each other and the ability to come to an agreement, but if your process in the team is not perfect, then you need to voice actions when technical requirements change. For QA, this will be critical in updating test cases and testing features. The developer completed the task 2 weeks ago and now he needs to remember why it’s like this here and why it’s like that.
Risk Four: Testing
The testing itself may be of poor quality due to human factors. I missed the error because… did not write a test case for this functionality or did not check negative tests. There was not enough time for testing. There was no documentation at all.
This risk depends on the testing engineer himself, but the risks described above can directly affect the quality of testing and the responsibility falls on you.
The above will help you protect yourself and your time. DOR And DOR. Criteria are required for which a task is taken for testing and criteria for completing testing. For example, the task describes all changes in requirements; the task contains a description and a link to the requirements for which the technical specifications can be updated. The completion criteria will be updated test cases and the recorded result of the new feature. The criteria depend on your experience and testing team.
The sprint board must have a Test column in which tasks related to program changes are located – they must be tested. Not all tasks need to be put in this column, because… you do not double-check the work of the developers, but check the operation of the software (program).
Fifth Risk: Release (Support)
This risk depends on the fourth, because you can only detect a bug during regression testing, which means little time is spent on testing. I would add to this risk the moment when you roll out to the industry, but the customer doesn’t like something.
Here the responsibility does not lie with QA, but there are cases when they try to find the culprit and it could be you. This is why you need to adhere to the steps above and do not forget about acceptance and system testing, which will ensure that we have rolled out exactly what was expected.
CONCLUSION
In this article I have listed five risks, but depending on your experience and the project you are working on, there may be more or less of them. When writing, I was guided by my experience and will be grateful if you add or correct my information.
QAtoDev – channel about manual and automatic testing
