Introduction
The evolution of the adoption of agile methods in companies that develop software products is clear. It is also very clear the evolution of software testing professionals is to adapt to a new context and still be able to actively contribute to their teams. Traditional test cases give way to more experience-oriented approaches, such as exploratory testing, for example. Automation gains space to be able to contribute with the support of regression tests of iterations of past cycles. Roles and responsibilities also change, from test analyst to QA analyst, a professional who, in addition to testing, contributes to quality from the beginning. But after all, is it really possible to contribute from the beginning? For example, while the code is still in development? Yes, it is possible, and in this article, I want to discuss with you, the reader, an approach in which QAs can actively contribute to the quality of the source code, called Functional Code Review.
1. Creating the testing strategy and defining what to test
A professional software testing process includes, among others, the activity of defining what the testing strategy will be like. A set of practices that will be used to achieve test objectives for each level of testing or point in the development process of an application. This activity will take into account what you have access to the application and then, based on that, the definition of what and how to test.
This activity does not change in this evolution from a waterfall to an agile context. In fact, what happens is the change over time, since agile proposes smaller and continuous cycles, and of course, the way in which the software is developed. Even so, at some point, the people responsible for testing will have the necessary inputs in hand to list which tests should be performed to contribute to the exercise of the software and feedback on its quality.
Practices other than just running the software to validate that its business rules have been properly implemented can be part of this strategy, such as non-functional testing, structure-related testing, and also reviews or inspections.
2. The work of code review by developers
When we talk about the modern software development process, we soon remember terms such as code versioning, code hosting, and versioning workflow and then we enter the code review theme, an activity usually attributed to developers who, after working on the implementation of some functionality, require their peers to review their code in order to identify points of improvement based on their knowledge.
Some of the items analyzed are usually the use of good programming practices in that particular language, application of design patterns to solve common problems, and adherence to code quality policies defined by the team, among others. A veritable list of elements will be taken into account when reviewing, seeking to contribute to the quality of the final code.
3. The Functional Code Review
Something that turns out to be rarely analyzed at the time of code review, are characteristics that are linked to the functionality of the software, such as business rules that the code was expected to meet. The name given to this form of review is Functional Code Review (1), in which the reviewer, among other things, evaluates ” edge cases, looking for concurrency issues, trying to think like a user, and making sure there are no bugs that you see just by reading the code”.
The omission regarding the application of Functional Code Review ends up corroborating with the late identification of defects, which end up being identified during software testing after it has already been integrated into its standard repository when they tend to be more expensive (2).
The choice not to carry out these checks is due to the pressure to develop and low practice with tests of this nature.
4. The performance of QAs in the Functional Code Review
Since the functional perspective of applications is commonly addressed by QAs in their testing strategy and it is usually executed mostly while the software (or part of it) can already be executed, a way to anticipate the tests would be to have QAs as contributors in the review functional code, thus being able to analyze whether the code’s functionalities meet the functional expectations proposed in the requirements.
In this case, some characteristics that could be evaluated by QAs would be, for example:
a. If the coded methods meet the business rules
b. If the error and success messages are consistent with the requirements
c. If the field names, labels, and masks meet those defined
d. If the ranges of values allowed in the fields are adequate
By participating in code review sessions, they could then analyze the tests that were designed for certain functionality and identify if the code has what is expected, if not, could then provide feedback and code correction before the code is even executed. , thus saving development time, testing, and of course, avoiding failures in the application.
5. The prerequisites for professional QA
The QA professional, in this case, would have to have advanced coding knowledge, so that he could at least understand the logic, programming language commands, and concepts related to code versioning and the review process. Attributes are already owned by testing and software quality professionals who build and maintain test automation scripts as part of their responsibilities.
6. The challenges and benefits related to this approach
This practice has been used in one of the projects where I work as QA Lead and some of the challenges I have faced are:
a. The learning curve regarding the diversity of programming languages used to build the components of a system
b. The efficiency of QA in identifying files that have functional characteristics to be evaluated
c. Developers’ reaction to the paradigm shift of QA being a professional who only tests in a black-box approach (2)
On the other hand, we have also reaped many benefits, including:
a. The. Anticipation of defects even at code review time.
b. Maximization of the technical knowledge of the QAs and with a broader view of the system
c. The Reduced amount of defects during functional testing stages
d. Reduce downtime early in the development cycle
e. Valuing the quality professional and the actual use of the Shift-Left concept (3)
7. Next steps and recommendations
As previously mentioned, there are still challenges to be overcome in this practice, such as having a process for preparing the QAs to work in this model and working together with developers as their mentors during the adaptation phase. Mentorship in which it could also help QAs to more easily identify the files that are actually targets of functional review in a code review session. Finally, the execution of initiatives to adapt the team regarding the performance of the QA as a professional who really contributes assiduously to the quality of the software from the beginning, instead of only after the software is running.
Conclusion
As we could see, the evolution of the adoption of agility ended up bringing to QAs the need to evolve in terms of their performance and the defect identification process, seeking to become more effective and be able to anticipate their tests as much as possible. This change brings little change in terms of the testing strategy that was already being built in non-agile models, however, when looking at a new context, where the QAs are closer to the developers, it was realized the possibility of going further, contributing to the revision of the source code and the opportunity to run tests early.
