The importance of a great software testing process
If a team doesn’t have a great software testing process, they are likely to deliver software projects that are over budget and late.
During our 30 years in business, DragonPoint Software has created a repeatable process for successful software projects, including a proven software testing process.
Our projects start with a great team that has worked together for years. What are the other keys to our successful software projects?
- Clear requirements that define the work to be completed in business and technical teams.
- Strong system architecture.
- Experienced programmers with a proven track record of success.
- Testing and re-testing to ensure the system works as expected.
- Deploying the software using a repeatable and reliable process.
- Training people who will use the software to meet the company’s business requirements.
- User Acceptance testing by people who will use the system in production.
- Documentation and on-page help to explain how each feature works.
- Go live and ongoing support and enhancements of the system.
Click here for more information on how structuring your software development team can support project success.
DragonPoint’s Software Testing Process
Software testing may be automated or manual and includes 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.
Initial testing focuses on the changes and enhancements defined in the statement of work for the current deliverable.
After confirming that all the new and update features work, the tester begins regression testing. Regression testing covers all system functions and ensures the new features didn’t break any of the existing code.
At the end of the project, the tester completes an end-to-end regression test. To do this, the tester goes through every screen, menu option, and feature 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. Each issue is assigned to the applicable developer. After the code is updated to address the deficiency, the issue is re-tested. If the issue has been resolved, the tester closes it; if not, the tester reassigns it to the developer for more work.
Failed projects: No matter how great programmers are, there will be parts of the code that don’t work as defined in the requirements. A good tester following a standard software testing process is critical to the success of a project. Testing fails when programmers who write the code also test it. Another path to failure is to test without a methodical, detailed software testing process. The process must include filing issues, re-testing, and closing them only after the code is working as specified.
Deployment
Deploying the system means installing the software on the hardware/server(s)/network/cloud on which end users will perform acceptance testing. Later in the project, the system will also be deployed to production.
Who: sometimes a specialist who is not a programmer deploys code. At the client’s request, DragonPoint 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 develops code on our own server(s) and deploys code to a test server for internal testing.
DragonPoint recommends having four version of each system:
- Development
- Internal testing
- QA – User Acceptance Testing
- Production
Having these separate applications allows testing and training without impacting production data.
Failed projects: A lack of good source control, including well-defined branches for production, QA, testing, and development code, leads to failed projects.
Training
Someone who knows the system inside and out and is qualified to answer questions will teach people 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.
Training classes are planned and taught by people who understand the application in detail. Sometimes one person writes the training script and someone else delivers it. The best trainers can go off script to answer questions from class participants.
Since the system owners are heavily involved in designing their application, they can often train others to use it. DragonPoint also has experienced trainers who can conduct classes. Training videos may also be created.
During training classes, participants should log into a copy of the production system. This allows simulating real life situations 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)
The first round of training is focused on the people who will perform user acceptance testing. This group will log into the QA version of the application and confirm that the system performs as defined in the requirements document.
Who: The system owner appoints people who will test it. Often this 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 QA 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.
It is important for the people on the user acceptance test team to follow a repeatable software testing process that includes:
- Using the requirements document as the basis for testing.
- Clearly reporting deviations from requirements so they can be addressed.
New requirements identified during testing are reported to the project manager. These are tracked 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. Not following a standard software testing process during UAT could result production problems.
Optional tasks after User Acceptance Testing
If issues are identified during user acceptance testing, the development team will make any required changes, re-test, and resubmit for final testing.
If requested, a professional technical writer who works with the requirements documents and a test version of the system can create on-page help documents.
Go Live
Go Live is when the new system is installed for production use.
This has the same cast of characters and reasons for failure as the Deployment steps above.
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 as small projects, depending on the scope of the changes required.
More about DragonPoint’s Process
Some companies use an Agile methodology for software development. This means they work on small sets of tasks (called a sprint) at once, but they still need to follow all the steps described above 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. The tester repeats the steps to reproduce the issue and then documents it. After the programmers update the code to correct the issue, the tester goes through the steps again. Code is deployed for further acceptance testing only after the tester says the reported issue has been fixed.
Following this standard software testing process ensures the system is working as expected.
Skipping any of these steps (except the optional ones listed above) may contribute to delays, failure to complete a new application, or completion of an 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.
For more information about successful software projects, contact us today.
