BBVA API Market
Never underestimate the test plan. When developing a software project, it is essential to guarantee the quality the customer expects, and to make sure the criteria that were agreed when the software was defined are actually fulfilled. We have to be sure there are no errors, bugs, or any other element that could cause our software to fail.
The concept of QA stems from this commitment to quality. Every development team should have least one person responsible for ensuring the correct operation of the software being developed. This doesn’t mean someone who is constantly correcting what the developers are doing wrong, but someone who acts as a facilitator for the tests required by the software.
QA in scrum teams
When a development team uses a scrum-type methodology, there can be doubts as to where the matter of testing fits in. The traditional concept relegates QA to the end of the whole process. This is a tremendous error if we’re looking to be agile and allow our company to move rapidly while developing in small steps –by comparing the customer’s expectations so we can boost production in small two-week sprints, for example. And of course, to allow us to rapidly correct anything that doesn’t work or doesn’t fit.
To achieve the goals promised by agile methodologies, development and QA must go hand-in-hand and be integrated in our everyday procedures. In this approach, and when defining the work team, each team of developers should have someone responsible for QA who follows the whole process throughout conception, analysis, development and obviously verification.
During the conception phase, QA should be aware of the intended aims –in other words, the type of requirements, how the product owner in the project (or customer as the case may be) wishes to see it implemented, and so on Then we can begin to create the first acceptance tests that will be used in the verification stage.
Throughout the development we’ll need to have tools available for continuous integration which combine the unit tests that are more common in the TDD methodologies –and which the developer has used to implement the functionalities– with the integration tests.
The responsibilities of QA
QA should be placed somewhere between the business and the technical part of the business. It helps the business translate the customer’s wishes into tests, and validates the acceptance criteria for the software implemented by the developers.
QA doesn’t simply detect faults, but anticipates them and verifies all possible contingencies so they can be validated by all the actors involved.
It should be responsible for creating an appropriate test environment. Throughout the development process, the programmer needs to have pre-production and staging environments with real data, without affecting the production side of the application. The QA will define part of these data and processes, depending on the situation when we go to production.
The task of preparing the data can be fairly time-consuming, so it needs to be automated through processes that create environments that are easily reproducible for each different scenario.
Aspects of defining a test plan
When defining a test plan we need to compile the functional requirements that define the scope of the project. This is the core that conforms the part of the business we set out with the customer and the users.
Set a clear time for testing. Preferably from the start. Although the project may be running behind in terms of time or costs, we should never reduce the test time. We have to guarantee the project that we deliver is free from errors. Most errors occur precisely when we’re in a rush to get ahead.
It is highly recommended to involve the key users who have shared in defining the requirements for the applications. Get frequent feedback.
And don’t forget the regression tests –once an error has been corrected we need to go back and test everything again. It’s essential to be absolutely sure that nothing has been broken elsewhere.
Nor should we forget the loading testing, which is the only way that we can be 100% sure that the whole technical part is working correctly. That is, that the infrastructure is capable of supporting the expected number of users. Scalability is a key issue in largescale software projects.
And finally, remember to maintain your pre-production and staging testing environments stable. Never run tests during production. Remember you can cause real problems for your current users.
The Embedded Finance (EF) and Bank-as-a-Service (BaaS) ecosystem is expanding at lightning speed and is in the process of defining of the roles of the new stakeholders entering the ecosystem, who are looking to fill niches or create new services. How will the Embedded Finance and Bank-as-a-Service sector evolve? José Luís Navarro Llorens is Head […]
Traditional banks are making the commitment to BaaS models, open banking is driving digital financial services, regulatory bodies are increasing scrutiny when it comes to BaaS providers, the banking ecosystem is rapidly changing and increased competition and regulatory pressures are expected in the BaaS sector. The State of Banking-as-a-Service (BaaS) is a report prepared by […]