{"id":21047,"date":"2022-04-28T13:28:24","date_gmt":"2022-04-28T11:28:24","guid":{"rendered":"https:\/\/stage-fp.webenv.pl\/blog\/?p=21047"},"modified":"2023-02-27T10:21:00","modified_gmt":"2023-02-27T09:21:00","slug":"when-disaster-knocks-on-your-door-the-importance-of-quality-assurance","status":"publish","type":"post","link":"https:\/\/www.future-processing.com\/blog\/when-disaster-knocks-on-your-door-the-importance-of-quality-assurance\/","title":{"rendered":"When disaster knocks on your door – the importance of Quality Assurance"},"content":{"rendered":"\n

In my 12 years of testing experience<\/strong>, I’ve come across high-risk projects many times. I’m convinced that we have always been able to steer clear of at least some issues or \u2013 in other cases – significantly mitigate their impact on the projects <\/strong>because of having the dedicated quality programming specialists onboard<\/strong>. I’m referring to both the legal and financial issues, as well as the client’s image perception externally, i.e. when the product doesn’t meet the users’ expectations or leaves them disappointed.<\/p>\n\n\n\n


A story of an efficiency<\/h2>\n\n\n\n


First Case<\/h3>\n\n\n\n

In the case of this project, we were approached by a client who already had an existing system in place<\/strong>. So the first step we took was getting to know that particular customer’s needs. That way, we were able to define the project’s objective: achieving the desired result within a given timeframe using available resources<\/strong>. <\/p>\n\n\n\n

The client’s existing system was associated with financial solutions<\/strong>. It had been created based on older technologies and developed for many years by various teams. Additionally, it had been passed on numerous times from one contractor to another, who all approached Quality Assurance very differently.<\/a> As a result, the code’s quality was very low, and it lacked suitable project templates, among other things. Consequently, the quality of the whole system suffered<\/a>, rendering it an obstacle to the effective implementation of business objectives. <\/p>\n\n\n\n

For example, the processing of some data<\/a> points was measured in days. That also caused serious problems with using the software, which \u2013 in turn – significantly damaged the client’s reputation in the eyes of their end-users. Hence, improving the overall system efficiency became our highest priority<\/strong>. Its successful implementation would allow us to achieve the project’s main business objective<\/a>. The timeframe for achieving the desired result – improving the efficiency – was also a part of that objective. <\/p>\n\n\n

\n
\n
\n The system was supposed to be implemented for new clients before the new tax year, so the solution had to be delivered strictly according to that implementation plan. There was no room for delays or deadline negotiations at all. <\/div>\n <\/div>\n <\/div>\n\n\n\n

Additionally, to achieve the desired result within the given timeframe, we needed to clarify available resources in the context of the team and the tools. The team comprised a few experienced developers and QA representatives<\/strong>. Their task was to ensure that the quality of the process<\/a> and the delivered solution would be maintained at all times. The tools were chosen according to the technology the whole system was based on. It was related to the project itself. Apart from the main application’s code, verifying the tests’ code was also one of the tasks<\/strong>. The tests were supposed to detect errors in the early stages of the implementation of new functionalities. <\/p>\n\n\n\n

Unfortunately, in the case of this particular project, they were practically non-existent<\/strong>. All verifications and validations up until that point had been carried out manually. That made everything very costly and time-consuming<\/a>, and, keeping in mind the strict upcoming deadlines, we couldn’t afford to lose more time. Therefore, our QA team was tasked with the following:<\/p>\n\n\n\n