With a growing demand in Software Quality, the Test Analyst has become recognized as a key part of the software development cycle. In the midst of these changes, it is important to know how that professional should prepare to meet the market requirements.
To know where we are going, it is important to remember where we came from.
When we talked about the software development lifecycle, we saw models such as Cascade, V-Model, Incremental, Evolutionary, RAD, Prototyping, Spiral, RUP, and several others that have appeared and waned. A common feature in those models is the large amount of documentation such as usage cases, class diagrams, sequence, activity, processes and blah-blah-blah, all very developer-oriented and development-type.
Within this context, Quality was almost never a priority; usually the testing phase was short (when it existed) and it was at the end of the development cycle, close to product delivery. This is a strong indicator that tests were generally not performed with the necessary efficiency.
Tests were performed only manually, the quality team was separated from the other teams involved in the project and had very little business knowledge, as well as low investment in people and time for architecture and testing.
In this scenario, the profile of the Software Quality professional known as Quality Analyst, and several other names that existed according to function, emerged.
The QA professional should have a profile that can communicate well, apply concepts and processes, define, prioritize, analyze, run manual tests, manage tools and execute cycles. Technical knowledge in tools and development as well as software engineering were not always required, and were little used by most professionals in the field.
Our environment has changed, we have evolved a lot, and now we are inserted in new development contexts with a huge diversity of increasingly complex and dynamic tools, methodologies, languages and businesses.
The team’s concern with user experience has taken on tremendous proportions, placing quality as the cornerstone of the product lifecycle and elevating the QA to a prominent role.
But this movement was a double-edged sword. With greater visibility, today the role of Quality Analyst has grown and encompasses many more activities, demanding much more knowledge, but not all of them are sufficiently prepared.
But wait! There is a way
Today the reality of software quality is quite different. Automated testing is mandatory; service virtualization is here to enable different types of testing; the need for quality has come to the world of IoT – Internet of Things; tests must meet the Mobile and Multiplatform demands; and the world of Software Quality is being heavily impacted by the arrival of Artificial Intelligence.
In addition to knowing all these concepts and technologies, it is important that the QA profile can be able to interact with:
- live documentation
- development flows
- manual and automated testing
- service testing
- different software platforms (web, app, desktop, responsive…)
Knowledge of tools (Jenkins, Chef, Docker, Cucumber…) and methodologies (Scrum, ATDD, BDD…) that accelerate these cultures is a great differential, but what is the use of knowing how to handle a hammer if you do not know what a hammer is for?
In everything that has already been discussed, there is one thing that is basic and fundamental: training in programming languages. Test automation tools are essential to this professional’s career (“everyone codes”).
Faced with a growing demand for Quality, the shortest path is for those who already work with tests in the traditional way and for developers who want to work with quality (Software Development Engineer in Tests – SDET) to join forces, since the former already knows what users want, while the latter has the required programming expertise.
The new QA should always look for the *best user experience* and must be seen as part of the development universe of a product, always seeking technical excellence and proximity to users.