Is QA required for early project planning?

QA in early stages

There are many factors that determine the success of a project and one of these is the establishment of a sound project plan in that project’s preliminary stages. Which is why more and more team members are getting involved earlier on. And it’s not just analysts, but developers and QA Engineers too. Indeed, with every team member having a unique mindset informed by different competences and experiences, this will bring varying and valuable perspectives to any given business requirement.

The appropriate time for involving QA in the project depends on the client and the software development methodology that is adopted. In Agile methodology, a tester’s work will begin at a certain point in the software life-cycle and elsewhere in the waterfall methodology. Much depends on the client's decision and budget, and though QA’s initial involvement is associated with additional costs, there are still several reasons why it can prove profitable.

What are the benefits of involving a QA in a project’s early stages?

Guaranteeing the utmost quality in software is paramount, lest you risk the competition benefitting from user dissatisfaction. QA’s involvement at an early stage of application development means errors are pre-empted. These errors could be in the application itself, in its design or ones committed during the process of requirement gathering. It is easier (and less expensive) to introduce an amendment to the list of requirements or the design than to the code. By detecting, then fixing errors, we improve product quality from the outset.

Even patching a software’s earlier version is infinitely easier and less time consuming than having to fix an application in an advanced stage of development. As a finished application is typically a vastly intricate and complicated product, introducing later corrections will risk further malfunctions elsewhere. To reconstruct such a product will naturally require more work, thus more time -- thus more money. 

What QA can do at the beginning of the project

Participate in client workshops 

QA may be introduced in the earliest stages of a project through client workshops. Here, it can be effective in querying and collecting user requirements. It will also help determine those requirements which have not been accounted for by the client yet remain necessary for the application’s proper functioning.

For the QA Engineer, participation in Product Discovery workshops is an opportunity to get to know the client and to better understand his/her business needs. Ultimately, it is an opportunity to clarify how and why the end product is intended to work as it will.  In this way, QA can test an application’s usability more efficiently. The Product Discovery workshop is a fully-integrated element in the software development process at Startup House.

Participate in requirements analysis

During the requirements analysis, the QA Engineer is able to identify any irregularities and/or deficiencies in the requirements. As a result, the documentation can be consulted with the client and corrected at an early stage. The QA can also help to create user stories, providing both feedback and acceptance criteria.

Design testing strategy

Prior to the project’s initiation, the QA Engineer should plan which approach will be used in the testing process. This testing strategy takes into account what to test, how to test it, and who will be responsible for conducting these tests. Depending on the size of the project, its budget, and an organization’s approach, the testing team will be sized accordingly. It is common in some projects that the Test Leader or Test Manager be responsible for strategic planning whilst the responsibility for carrying out the strategy is shared among several testers. Elsewhere, a testing team may simply be one person responsible for both planning and test execution.

As part of the testing strategy, QA determines both the scope of and approach to this testing; it defines the test environment’s requirements, selects the necessary tools, and plans the method and frequency of progress reporting. Finally, QA identifies project risks as well as all entry and exit criteria.

The end product of such planning is the test plan, a document containing all the aforementioned information regarding the testing process on the project. Documenting the entire process upon the project’s initiation ensures the subsequent work during the software development is systematic and orderly.

Document the process flow

This initiation of the software development process is an ideal time to introduce flow diagrams. Such documentation enables one to detect logical errors and to identify places where decision paths have not been fully covered or where necessary functionalities have been omitted.  It is also useful in planning the entire software development process. Through the use of process diagrams, a clearer understanding of the project is rendered for technical and non-technical people alike.

Not only do diagrams help with comprehension and in client conversations, but they can also be a basis for queuing user stories for development. When established early enough in the process, they can also be helpful in creating user stories. 

Create test documentation

Based on the requirements and software designs, QA can write most of the test cases needed for the project. Test documentation is best conceived at the starting point of software development where there is not yet anything to be tested. Writing test cases, as with creating process diagrams, can reveal gaps in logic and requirements: the sooner issues are identified, the easier it will be to fix them.

Creating test documentation early in the project makes later work easier for the tester. When new functionalities appear, the tester can focus on testing and spend a majority of the time doing this. The ready documentation facilitates the planning of test runs: functional tests, end-to-end tests, smoke tests and regression tests.

Test new features immediately

The presence of the QA Engineer in the early stages of software development allows him to test even the smallest delivered parts of the application immediately. 

Once the code-containing test environment is ready, QA can start testing. Doing so with individual modules does not require the existence and operation of the entire application - plugs and mocks can be used instead. This solution enables QA to check a new module soon after its creation and introduce corrections without having to wait for the rest of the application. As it is easier to fix a module that has been recently worked on, this is beneficial for developers too. Such fixes pose no threat to the rest of the application given the product’s modest level of complexity in these early stages.

Summary

The involvement of the QA Engineer earlier allows for the early detection of bugs, in turn reducing the costs incurred for repairing them. Finding inconsistencies in the requirements is far preferable since any changes to the design are far more economic than those made to the application code.

Indeed, QA provides an indispensable overview of the project during client conversations, so having the foresight to employ it from the outset is wise. It is indeed an investment whose returns are enjoyed not so much through the problems they fix, but rather in those they avoid.

At Startup House we’re always keen to share the wisdom, so if you’d like to know more, don’t hesitate to contact us: hello@start-up.house