Although QA (Quality Assurance) and BA (Business Analysis) roles have been an integral part of the software development process for years, their importance is quite often questioned by customers – especially those with little or no experience in software development. The default assumption is that good developers always write bug-free code and a reasonably well-drafted vision of the future product should suffice for kicking off a project and ultimately taking it to a successful completion. The reality is quite different, however, and we would like to share some insights on how to convince a potential customer that BA and QA are essential for delivering a well thought-through, stable and secure software product.
Surprisingly, many customers tend to believe that quality assurance is some kind of costly extra, an accessory for the otherwise productive, efficient and unmistakable team of developers. It is often assumed that a good developer will always cover his code with unit tests, run and re-run tests all the time and generally split his time between development and testing in nearly equal proportions to ensure that the result is always perfect. This may be the case at certain companies or on certain projects, but the rule of thumb is to keep development and quality assurance separate for the sake of productivity and objectivity.
Rigorous control over quality
The first reason for this is that development and testing processes can be easily run in parallel, thus allowing every team member to concentrate on their primary task. What can be overlooked or ignored by a developer as “good enough” may not pass QA acceptance if a proper process is in place. There is also a psychological twist to it – we tend to treat imperfections in our work with a touch of indifference, try to cut ourselves some slack, especially when we seem to have exhausted all improvement options. However, if we have an unbiased observer, such as a QA team, by our side, none of these tricks will go unnoticed.
One more solid argument in support of QA is that hardly any developer is capable of running a broad range of specialty tests, such as load, performance, security, functionality and regression tests with a proper level of quality and thoroughness, let alone the distraction factor that will inevitably come into play if a developer assumes too much of the QA role. In this particular case, the division of labor is completely justified and stability of the final product directly depends on the coordinated actions of the development and quality assurance teams.
The last, but not the least valuable observation about the importance of having QA’s on the team is that without them, no vendor would be able to provide any kind of warranty for the work done. A deliverable can be considered shippable only after is has passed QA acceptance – that is, confirmation that the requested functionality was implemented according to the specification, that there are no critical bugs and that the company bears responsibility for the results of the project.
The bottom line – and this conclusion reflects Cortlex’s position on the matter – is that without QA, development turns into an unpredictable endeavor where things may go wrong or right with nearly equal probability. Only thorough testing and adherence to an established quality assurance process can guarantee a stable and predictable software development flow and ensure success in the long run.
Another frequently underestimated and misunderstood role is that of the business analyst. When a customer hires a dedicated team to work on a project, it is automatically assumed that a more or less detailed vision of the solution will suffice for the developers to start and carry on until it’s done. However, in reality, business analysis on the customer’s side very often becomes a major bottleneck, especially in case of Scrum or a similar agile methodology, which forces teams to remain idle until enough user stories (that is, groomed scope) are ready for them to continue.
It’s all about requirements
Business analysts work with purely business requirements coming from non-technical points of contact and turn them into clear and straightforward specifications for developers to follow. Apart from this, they serve as intermediaries between the customer and the team, making sure that the language barrier does not become an issue and that nothing gets lost between the lines. Having a BA in the team ensures that development and requirements analysis workflows do not hamper one another and run in parallel, which results in the optimal team velocity. As mentioned above, this is especially important for agile teams, where sprint planning relies heavily on the availability of analyzed and formalized requirements for certain features or parts of the system. The very purpose of BA is to help the customer get a better understanding of their future product and build a system based on a set of flows, use cases and designs that have been discussed and agreed upon, rather than a blurry vision and spontaneously changing requirements.
Finally, business analysts are the people responsible for creating detailed documentation for the solution being developed, which is essential for future maintenance, updates or handing it over to a different software developer in the future.
Cortlex strongly believes that QA and BA roles are absolutely essential for any type of project, regardless of the approach used. Both bring immense value to every party involved and dramatically increase the chances of a successful outcome. We advise all customers to never underestimate the importance of proper planning and meticulous quality control. In case you have any questions about our QA and BA expertise, do not hesitate to contact us, and we’ll be happy to share our thoughts on how we can help your project be a success.