The significance of practising QA through the eyes of Ginger Payments’ QA Engineer
Quality Assurance or QA is one of the phases in software development world that often has people being strongly opinionated about. Some developers have a tendency to assume that since there are no visible errors during the development process or if their code simply works, the software quality is good and it does not need refinement. However, from my experience (and all my fellow QAs') this is never the case and there are always more factors to be taken into consideration when determining the software quality. Quite often, the management tries to get the bare bones of QA by only postulating User Acceptance Testing to be performed, which is insufficient for modern software requirements. Used interchangeably with Testing, QA is to a greater extent, a part of Quality Management, focused on providing confidence that quality requirements of the software are fulfilled. The desirable outcome of all the QA efforts is high-quality software and good UX with clean code as a covetable side-effect.
The distinguishing factor about Ginger Payments in the Finance domain is that everyone understands the importance of QA at each and every step, and the associated benefits. We work towards generating sustainable and good quality code. Thus, QA is not merely an obligation but a habit at Ginger.
The decision to have a QA team is influenced by a long list of factors with time being the major one (we all know how valuable time is!). It is often the case when the final outcome is not as initially expected (eg. multiple issues in the performance of the code in a performance critical software) or the software fails completely (the worst case scenario - in the hands of the end user) the company experiences not only external collapse of its reputation but also internal frictions between the responsible team members. Clearly, this is not a pleasant experience for anyone. But here at Ginger Payments, this is rarely the case.
When I started working at Ginger Payments, it was a major relief to see that common quality practices like code reviews, unit tests, automated tests and a sufficient amount of documentation were already present. This was an indication that quality is a serious factor here. Since there is always a scope for improvement, I initiated the process of having a Definition of Ready and Done for all those involved in the development process. This was a minor quality step effort wise but a major one outcome wise. Implementing it was a great success, which received very useful and positive feedback from the management and was completed and executed with the cooperation from the whole development team.
Most of my testing efforts are functional testing and I often need the information about the business rules at play (at my fingertips). Everyone involved in that task always makes sure the necessary details are communicated to me by mentioning the impacted area - which is a major pointer when I am QAing the task at hand. When I test a task and find it is not meeting the requirements, I communicate immediately the outcome to the developers. They comprehend it well and together we work it out, thus releasing quality software. Although rarely, it has happened that there was a disagreement between me and the developers, in which case a quick face to face chat always helps to find the best solution. In this way, my efforts as a QA Engineer succeed because the developers understand my role well (which goes a long way), we have clear communication without being constrained by distance (since a few of our devs do work remotely), and lastly because there is a presence of a great developer-QA-management rapport. The applications which I use to track my work and communicate the testing efforts to all the stakeholders are Jira and Confluence. I also jot down points and tasks for the day is a paper diary and coloured pens (yes I am an old-school one... ;) ) Whenever I need any help or expert opinion from the management, they happily assist me without requiring a formal communication - unlike the previous work cultures I have worked in.
Having explored the impact and the presence of the QA team in Ginger, it is interesting to mention some of the major factors that help achieve a good quality of the software under development in our company:
It is impressive to see that Ginger gives importance to all the above mentioned factors and practices them as well. An example to illustrate all these factors in practice is the way we work with ING for development of new features for the ING PSP Platform. There are weekly feedback sessions between the Ginger Payments and ING to highlight the upcoming features, discuss them and document the required business rules. Once the documentation is in place, our Product Manager bifurcates the work and creates the related tasks in our product backlog in Jira. The tasks are then delegated to the involved team members for implementation. During the development phase, the quality is ensured by following standard coding practices coupled with peer to peer reviews and sufficient unit tests. Post this, the feature is handed over to the QA team for testing, feedback and approval. The transparent communication between ING and everyone at Ginger Payments ensures that the whole SDLC goes smoothly until the feature is released.
All the teams within Ginger are encouraged by the management to contribute actively to the QA policies and regular refinement is done on the SDLC process at Ginger to keep pace with changes. The developers and QA communicate freely with quality as the main goal. The scalable code base attributes its good quality to the great work atmosphere and culture, the progressive thinking and practice and lastly the same long-term vision shared by both Management and all the employees of Ginger.
It is vital to understand that no QA professional is exactly the same. Some QA professionals have a deep understanding of the Requirement Manager role or UX role and can seamlessly step into that role if required. At Ginger Payments, for everyone , such unique mix of capabilities is well understood and responded by the management to make the maximum use of individual potential accordingly. One of my ninja powers (including testing the plugins for software) is doing the translation for our software, with great encouragement and support from the management and the clients. Another quality possessed by QA professionals is the fundamental understanding of each of the roles in the team and, as thus are as such, a ‘generalist by trade’. Thus, QA professionals use this broad comprehension of the roles to understand how projects and their products are progressing and, as a result, provide feedback to improve practices or processes. And, above all, they always inform the development team about whether the product under development is what the customer wants because, at the end of the day, they are the one making use of the product.
If you are a startup and in doubt when you should implement QA process in your business model, here is one major tip - “As soon as possible!” Quality Assurance practices should be part of your company culture from the get-go to avoid software failures in the hands of your first paying customers. And once you have allocated enough resources for a dedicated QA personnel, make sure you document the client's requirements thoroughly, clearly communicate them with the involved team members and provide your QA with assistance and approval when needed. After all, as our HR manager says: “Throwing a brick at a window is easy, but doing QA - that requires real talent.”