The importance of thorough testing and quality control
Testing: automated or manual unit testing and end-to-end testing.
Who: Tester (who is not a programmer) supplemented by automated unit tests (written by the programmers)
How: The tester goes through every function, screen, and feature in the requirements document to ensure the code works as expected. In addition, after each set of code is complete (each sprint or phase of a project), the tester performs some level of regression testing to ensure the new features didn’t break any of the existing code. At the end of the project, the tester completes an end-to-end or regression test, going through every screen, menu option, and feature in the application to ensure the system meets the client’s objectives.
When there are questions about system functionality or interpretation of the requirements, the tester relies on the project manager.
Any deviation from the requirements is reported in a tracking system and each issue is assigned to the applicable developer, who will update the code appropriately and set the task status to indicate it’s ready for re-testing. If the issue has been resolved, the tester closes it.
Failed projects: No matter how great programmers are, there will be parts of the code that don’t work as defined in the requirements, so a good tester following a standard process is critical to the success of a project. Testing fails when programmers who write the code also test it or when the tester doesn’t follow a methodical, detailed process of filing bugs and re-testing and closing them only after the code is working as specified.
Deployment: Install the software on the hardware/server(s)/network/cloud on which end users will perform acceptance testing, and later in the project, deploy to production.
Who: sometimes a specialist who is not a programmer deploys code; however, at the client’s request, a DragonPoint system architect or developer is often responsible for deploying code.
How: Some companies may use a specific DevOps process, which companies like DragonPoint follow when deploying code to the company’s servers or cloud. DragonPoint generally develops code on our own server(s) and deploys code to a test server for internal testing.
Failed projects: Without good source control including well-defined branches for production vs development code, it is difficult to successfully deploy an application.
Training: teaching everyone to use the application
Who: Trainers need strong communication skills and know the system in detail.
How: Training scripts are developed by technical writers. They use a test version of the system to walk through the steps that will be taught. They may also reference requirements documents and interview subject matter experts for the application.
Training classes are taught by people who understand the application in detail and who can develop and deliver a consistent scripted class, but who also have the ability to go off script if necessary to answer questions from class participants.
With DragonPoint’s custom software development process, the representatives from the client help define the code and can often train others in their organization. DragonPoint also has experienced trainers who can conduct classes. Training videos may also be created.
Whether training is provided by the people who helped design the code or by a specialized training team, the people who will be testing and who will use the system in production need classes that allow them to log into the application and use it in a test environment where data can be added and deleted.
Failed projects: No matter how intuitive we believe a system to be, expecting people to figure out a system without any type of training can create resistance that causes a new application to fail.
User Acceptance Testing (UAT): testing by the people who will use the system
Who: the system owner appoints people who will test it. This generally includes the client project manager, subject matter experts, and others who were involved in the design of the application.
How: The application is deployed to a test environment. If the new system is replacing an existing application, the test application will include data converted from the legacy system. If there is no legacy data, the system will allow the testers to build all new data.
Testers will work against the requirements document and will report any issues so they can be re-tested, recorded, and fixed.
New requirements identified during testing are reported to the PM, who tracks them as part of the backlog for future sprints/phases of work.
Failed projects: People who are going to use the system in real life will work differently than a professional software tester. Ignoring user acceptance testing increases the likelihood that issues may occur with production use of the application.
Optional tasks after User Acceptance Testing
Testing and code updates to address issues found during UAT
Creation of system documentation by a professional technical writer who works with the requirements documents and a test version of the system
Go Live: Install software for production use
This has the same cast of characters and reasons for failure as the Deployment steps above (step 5).
Support and ongoing enhancements: support for production systems is DragonPoint’s highest priority. Ongoing enhancements may be completed as part of a maintenance agreement or projects, depending on the scope of the changes required.
Some companies use an Agile methodology for software development, which means they work on small sets of tasks (called a sprint) at once, but they still need to follow all these steps for each sprint.
At DragonPoint, these steps are completed for each set of requirements, and most projects include multiple sets of requirements, which we also call a sprint or phase of a project.
For each sprint or phase, some of the steps are repeated before moving the to the next one. For example, issues identified during acceptance testing go back to the tester, who repeats the steps to reproduce the issue and files a bug. After the programmers update the code to correct the bug and mark it fixed, the tester goes through the steps again to ensure the system is working, and then the code is deployed for further acceptance testing.
Skipping any of these steps (except the optional ones in step 8) may contribute to delays, failure to complete a new application, or completion of a new application that does not meet the business requirements.
Conclusion
While people may be stars in their role, one person cannot perform all the steps required for creating a new software application. The skills that make someone a success in one role may make them a poor fit for another part of the team.
Having a skilled team doesn’t guarantee a successful software project, but NOT having the right team – or expecting one person to perform all the team’s roles – guarantees a failed software project.
Let DragonPoint guide you through the final stages of your software project. Reach out today.
