The (correct) first step of the development project

Have you been in a situation when you hired a team of experienced developers and paid a lot of attention to your project, and yet it still failed or was seriously overdue? That is a very common case. It does not necessarily mean you did not choose the best people for the job. Very often, the problem is not about “what was done wrong” but “how was it done wrong”.

What can you do to make sure your project will go smoothly from the beginning till the successful end? The answer lies in the Discovery Phase lead by a Quality Assurance Engineer.

What is Discovery Phase?

At the very beginning of the project, we always suggest our clients undergo the Discovery Phase. During the procedure, a QA Engineer takes a closer look at the whole process of application development. From the way the requirements are passed to the team, to the way how the code is pushed to the testing servers – everything is examined.

In the area of tests, the QA Engineer asks such questions as:

• Does a client have tests?
• Are these tests automated, or manual?
• Does the client hire testers, or outsource testing outside the company?
• When the code is tested – right after a developer delivers them, or with some kind of delay?

Next area that goes under the watchful engineer’s eye is the process of deployment.

• In what way the client deploys their application to production?
• What is the lifecycle of the product?
• Is the product tested before it is deployed?
• What are the tests environments? Are there, according to the best practices, two of them: pre-production and one for checking the system integrity?

Finally, there comes the DevOps area. Some questions that QA engineer asks here are:

• Is the infrastructure well documented?
• Does someone configure it manually, or are scripts prepared for it?
• When deploying the code, is it done automatically, with tools for continuous integration?

The process of developing the product is not only about technicalities. Team members are far more important than that. And when many people work together, communication sometimes gets tricky. That is why the area of team cooperation is the next one the QA engineer pays attention to:

• Does the team know the requirements of the project?
• If yes, then – do they understand them?
• Are procedures and standards known to everyone?
• Do team members know the business requirements of the application they are writing? Or are they simply being given technical commands, without any business context?
• Are the tasks defined understandably?
• How is the team working? What are the methodologies?

The scope is wide, but that is what Quality Assurance is all about. All the areas mentioned above are components of the overall quality of the product.

Fixes suggestions… then what?

After examining various areas of the process, the QA Engineer can give their advice. It never takes a form of criticism, rather: a suggestion. There are always things that can be done slightly better, and pieces of advice do not turn the team’s work upside down.

The Discovery Phase is the first step of the project and takes place only in the beginning. The process of producing the product is not further evaluated… unless in the team working on the app has a QA engineer. It might be the same person that conducted the examination, or it might be a different person hired as a quality litmus paper.

With a QA on board, the process of improving the quality of the work never ends. Why? Because the product – just as the team, the requirements, the situation – constantly changes. Here come new developers, or the application takes a different turn than anyone expected, or suddenly we are dealing with the global pandemic and everything needs to be adjusted.

The QA role in the team is to analyse and suggest ideas to improve the process or fix problems. They share those ideas during the cyclical meetings called retrospective. Thanks to the iterative nature of those meetings, the whole team is constantly being challenged to learn and grow during the project.

Finding out what is wrong

The phase can focus on many areas, it can involve DevOps, it can be related with the role of Agile Delivery Teams od Project Managers, but that is why we say Quality Assurance is not just about testing and testing.

A broad look at the software development process, at humans being part of this process, at the machines, technicalities, gives you a chance to see problems that hinder the whole project. Usually, a QA Engineer is not an expert in DevOps or human relations areas. But when they are looking at all elements, they can notice things otherwise not very obvious. Then, their role is to say, “Maybe it is not the best solution when a developer deploys the code manually to test servers. Maybe it would be good to switch to automated tools”.

Because that technical expert knowledge is a forte of the testing field: what to test, when and how, what to automate, and when automation is not worth it.

Could Discovery Phase save your project and cut the development costs in half? It’s possible!
Contact us through the form below. We will explain to you details about the Phase and discuss if it could help deliver your product.