Boy, what a loaded question that can be these days, and the most exact answer is, “it depends.” Today’s software development projects are nimble in comparison to what they once were. While we review what a testing process might look like, it’s important to note that the most experienced software testing teams will be the best able to adapt to your software development team structure. Lighthouse Technologies is a perfect example. Describe your scenario, and we will know how to complement your methods and teams with key software QA principles from our True North Test Methodology™, and utilize our experienced software testing professionals.
Back in the days of traditional Waterfall project management, the process was consistent:
- Read the requirements
- Develop a plan
- QA testers begin testing after code is written
- Bugs reported and addressed
- Retest and validate
- End-users begin testing
- Bugs reported and addressed
- Retest and validate
A significant factor is the timeline of this waterfall process, where testing occurs as development completes. This process delayed QA involvement until months into the project. Waterfall testing is very structured and very rigid or…..CONTROLLED. Frankly, the bugs aren’t discovered until so late in the cycle, that many of the developers may no longer be on the project.
Enter Agile
Agile has taken software development teams by storm over the last decade, completely revolutionizing the ways and methods around software development. It all started with a Manifesto that turned values around for testers, developers, and beyond:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Responding to change over following a plan
- Collaborating with customers over contract negotiation
- The entire team must evolve to embrace these values in Agile methodology. Unlike waterfall, an Agile testing team works alongside developers and customers through the whole project, from start to finish.
Similarities at first glance
The testing steps involved are very similar to what we described in Waterfall approach, but Agile software testing processes begin when the project starts. The testing plan evolves from the requirements (In Agile, these are generally written as user stories), but we don’t need the full set of requirements to be complete before we get started.
One of our favorite tools on the Lighthouse Technologies team is the ScopeMaster tool for analyzing user stories (or functional requirements). We bring value to our clients with this tool because it can analyze those requirements in as little as four seconds, identify dozens of missing and incorrect user stories, and save the team days of effort and meetings.
Testing Process for Agile
Another significant difference of Agile is that every step of the software testing process occurs several times in small increments, generally known as sprints. Based on the user stories, the QA manager creates a software test plan that allows for functional testing for each sprint, as well as non-functional testing at certain intervals. In addition, the QA manager needs to determine how to accomplish regression testing. If the test plan calls for 100% test automation, then regression is performed fully in each sprint. Otherwise, the QA manager often builds in hardening sprints (often every 4-8 sprints) to execute the full regression test suite. From there, it’s full steam ahead.
Outside of the Sprint, but well within the SDLC (software development lifecycle)
Defining the scope of testing
Just as the project has a scope, so does testing. We recognize that we cannot test every single detail (because there’s never enough time or budget), so we identify and prioritize the most critical user stories first and work from there. Each sprint will define precisely what is developed and tested as the scope. As the above diagram shows, for each sprint, the test team develops test cases, executes them, reports all bugs, and retests when the fixes are made. As with traditional waterfall, experienced testers know how to test “in the surrounding areas” looking for issues that the developer inadvertently created when they fixed the bug. This is more of an art than a science, and this is where experienced teams, like Lighthouse, really prove their value.
Other essential QA functions worth mentioning
Note: A sprint will be trying to complete new functionality and potentially old bug fixes. These changes are not considered complete until the new functionality is done/done (Development is complete AND testing is complete).
Automated Testing
When system functionality is stable, it is often beneficial (i.e., there’s a positive ROI) to transition from manual testing to test automation. There are a lot of potential benefits to test automation, but it needs to have a good strategy and justification. Automating test cases is always much more expensive than performing manual testing. However, when a set of functionality is critical and needs tested every sprint, we write code to execute a test script automatically, saving teams time and money over the life of the application. (Note – This is really a 50,000 foot overview and we have many blogs on test automation and considerations for automation ROI.)
Exploratory Testing
Exploratory testing might be declared a free-for-all, for it lacks structure as the testers autonomously explore the application, trying to learn it as they design and execute test cases based on their findings. Exploratory testing is often focused on user experience and highly adaptable to change. Interactions hold a higher value than processes and tools with this type of testing. Experienced professional testers who understand the context of the application and implications of different transactions can find fragile areas of the application using exploratory testing.
Performance testing and load testing
After confirming that functionality is working as planned, the next step is to see how much it can take under pressure. Some tests may include different applications working together in sequence or tandem, while other stress tests focus on increasing the volume of users or amplifying the level of data being accessed. Pro Tip – Don’t wait until the end of your project to start performance testing. It can often identify weaknesses in system architecture and may require significant code or database refactoring.
Role of Agile testers:
Agile testers must be able to adapt quickly to change, think critically while being given minimal information, and ask thought-provoking questions to the rest of the team.
At Lighthouse Technologies, we have these qualities in spades and bring with us a wealth of expertise to suit just about any software testing need you have. How can we help? Let’s talk today and we can explain how we have helped our clients keep their projects on track – cost, schedule, and quality.
