Blog

Ever evolving Software Engineering industry has encountered major challenges in past couple of decades and one of those challenges was to define the roles and responsibilities of different people involved in different projects. Unfortunately, Software Quality Assurance personnel and part of a software project have suffered the most in the process of program definition.

There is an opinion that as Software industry borrowed its processes from other engineering industries; the PMs tended to start quality assurance, post production of a product. Whereas it is proven that in a software development project, it becomes more expensive and less productive if you tend to delay the quality assurance process. Another problem is that, QA has always been integrated as merely a part of a project which limited the authority and throughput of QA team.

Having QA testing services as a part of the project may work and may work well in small to medium size software projects, but in case of a large application development process; typically an ERP application, QA, being integrated as a part of the project can very likely jeopardize the whole project.

Testing an ERP application can be a tricky, lengthy and fluctuating process and may very well test the patience of the higher management. So, it is best to leave QA and its management to the people who are typically skilled for Quality Assurance processes and procedures.

Implementation of an ERP System can be a lengthy process; most of the peers involved in the process can change their requirements. With changing requirements, the development process needs to be revised accordingly. In such scenarios, QA should have more authority and control on their own process so they can ensure the agility in their process and take radical decisions on time.

While the overall goals of an ERP implementation are set prior to the start of the project, but QA, as separate team should line down its own goals, check-posts and cost accordingly. In a situation where requirements and plan can change, QA should have the authority to tweak and refurbish its plans, goals and their cost and the overall project expectations.

As ERP implementation typically takes much time, QA can be a lesser cost effective part of the project if it is being dealt as a part. QA as a standalone project can do its own rightsizing when it’s needed and produce the results in a more cost effective way.

QA can ensure compliance with quality standards if they have their own budget and cost analysis. If QA is a part of the whole project and the overall cost of the project is higher than expected, it is highly unlikely that QA is allocated with budget to ensure compliance with quality standards.

Concluding, QA can suffer from minor to major blows if it is dealt as part of the whole project in ERP development or any other larger applications development process for that matter. If QA is a standalone project, they will have their authority and full ownership of maintenance of quality of not only the actual product but the whole development process as well, and all that while complying with quality standards of the industry. As the overall objective is to deliver a high quality and stable product, all stakeholders should be comfortable working within the team, but in a development and implementation activity, expectations from QA rises exponentially and they can feel suffocated on cost, goals and objectives perspectives. So, to maximize the output from a QA team in such activities, it is best to deal them as separate projects and let the QA team have its liberty to play around for much better results.