Why Dedicated Software Development Testing Matters – Part 1
It’s not uncommon to hear clients on the business side question whether it’s really necessary to budget for dedicated testing resources as part of a software development project. “If the development team followed spec and developed according to plan, how much testing is there to be done?” Sounds like a valid question.
But when you take a closer look, this situation is quite similar to when executives ponder budget requests for additional staffing and technology in Marketing. Sure, we need Marketing to drive sales; but really, how many people and tools could they possible need to plan and execute? In reality, quality control management has always been critical to delivering high quality software; but what’s not always obvious is that it covers much more territory than simply exposing errors or bugs.
Comprehensive Testing Adds Value
Testing teams are dedicated to validating that a software program or app or product meets the technical requirements and design guidelines established at the start of the project. In addition to validating functionality, they also cover standard compliance, non-functional requirements, as well as integration with other systems. This broad approach improves the end-product quality and delivers a positive user experience.
That said quality control management should not become the “gold-standard”. Expert testing teams must be diligent about identifying and covering the “must-have” scenarios and cases – within project constraints.
In today’s market, there is the addition of complex Digital Transformation initiatives, where there are typically many connected moving parts that must function together seamlessly – multiple platforms and systems, devices, Websites, and eCommerce capabilities. Development work in a specific area can easily impact how the new software interacts with existing systems which makes testing – specifically Integration Testing – a critical part of the complete software development project.
Agile testers provide quick feedback on each point which makes fixes easier and less painful. Agile means open daily communication and continuous involvement of the testers as part of the development team instead of functioning as a separate team in a traditional plan-driven development approach. They not only function as testers, but as BAs and as UX experts.
A typical day in the life of an Agile tester is very busy with interaction, discussions – not only the function of testing. Agile embraces change during any stage which makes testing more, well, agile. In contrast, testing in a plan-driven development model leaves the majority of testing to be performed after the development work has been completed. Depending on the testing results, this approach could have the effect of delaying delivery especially if a high number of serious defects are identified.
Quality Control Structure and Testing Flow
We believe there are 3 main phases when it comes to testing:
- Define the test strategy and testing plan
- Execute on testing
- Assess and Report on the readiness or “done” status
Phase 1 - Define the test strategy and testing plan
At a minimum, it’s important to have a vision for how testing will be executed throughout the development phase. Or, the team may create an initial version of the testing plan prior to the start of the project. The level of plan detail is dependent on customer expectations, the project lifecycle, and the size of the team. What matters is that there is a clear understanding of business and technical requirements to ensure they are covered in the testing plan.
This document should describe the testing goals and quality standards, hardware and software testing environment, tools, types of testing to be used for each project phase, and testing results reporting. The objective for this document is to define what level of testing quality will be acceptable and how the testing team will meet the requirements.
It is important to ensure the testing process is continuously updated with any changes such as changes to the focus or goal of testing, or the testing expectations. To ensure the effectiveness of the testing process, the test leader must be able to adapt to the project changes.
Phase 2 - Testing Execution
Test cases may be high-level and describe main steps, or they can be quite detailed, to the point that less-experienced testers could execute them without knowing all the details of the project. The level of detail required depends on the project needs and is a part of a negotiation between the Project Manager (PM), Business Analysts (BAs), and the Test Leader.
Test cases and scenarios are live documents and must be kept up to date. As requirements are updated, the related cases must be updated at the same time. The output from this activity will be functional test cases and scenarios.
Each test case should have a clear entry point, testing step(s), along with the expected results. The creation of test cases is often dismissed as not important by individuals on the business side. But without clearly articulated and documented test cases, the steps of how requirements will be verified will only exist in the tester’s mind while repeatability is one of the main characteristic of a mature testing process.
Depending on the project lifecycle, test cases and scenarios may be created and tracked in a separate phase or this work may be completed along with development or even test-first approach.
Options for Testing Software Solutions
The testing team may decide to use a powerful ALM (Application Lifecycle Management) Solution such as Microsoft TFS (Team Foundation Server) or QC (Quality Center) by HP, to track test cases and link them to the appropriate requirements. This is an ideal scenario since using an ALM tool provides traceability between requirements, test cases and discovered defects, making the current status clear and transparent for all stakeholders.
If the preferred, but more expensive tools are not available, the team may choose to use tools with less integration such as Zephyr (the testing support plug-in for Jira), or free tools like Test Link, or even smartly structured Excel documents. The goal is still the same - tracking and traceability.
Other Key Factors in Testing Execution
Defects found during the test execution phase should be tracked in a proper system. It is ideal to use tools such as Jira, TFS, or tools of similar quality. Some customers provide their own testing environment and provide secure access to the First Line Software testing team. If a testing environment is not provided, the First Line Software team can use Redmine, which is a bug-tracking tool.
Impact analysis is another important area of testing. Skilled professionals identify the critical areas where testing efforts should be focused.
Regression testing is often the last step in the Test Execution phase. After performing testing of new functionality throughout the development phase, identifying defects, and re-testing defects, the Testing team executes a final run to verify that all functionality which worked previously has not broken with the introduction of new functionality.
Test automation has always been a part of excellent testing practices. Since test automation is expensive, especially at the start, it is important to understand why it is needed. Test automation is used primarily for Regression Testing; but some projects support automation from the start of the project. Regression Testing can be UI-driven or pure backend and First Line Software testing experts are equipped to propose a solution.
A new challenge has arisen in Test Execution. Many projects require short development phases and frequent releases. Clearly, a project with one-week sprints cannot afford to spend even one full team day on Regression Testing. Test automation can be a part of the solution; but the team must clearly understand what to automate and what not automate. Automating at least several frequently-used scenarios not only saves time; it also provides the ability to introduce changes later-on during the sprint.
Eliminating Testing from a development project can have serious consequences in terms of achieving the desired quality of the end product and duration of the project. Whether your company is outsourcing the entire development project or simply the testing phase, be sure you allocate budget for this important function.
To learn more about Testing and explore how the First Line Software Testing Team can be instrumental in ensuring the best possible development results are achieved for your company, Contact Us today.
Download Case Study
Need more details?
Fill in the form and we’ll contact you as soon as possible.
David Tedford has over 20 years of sales experience within the IT/software industry. He excels at being immersed in a customer's environment, understanding his customers requirements, crafting solutions to meet those requirements, and ultimately providing solutions to his customers.
Senior Vice President
As the head of business development for First Line Software, Vladimir heads up business development in Western Europe and Russia.
Vladimir began his career in IT in 2002, when, as a student of Faculty of Automation of Computer Science of the First Electrotechnical University (ETU “LETI”), he began his work at The Morfizpribor Central Research Institute (CRI). Vladimir joined the StarSoft team (predecessor of First Line Software) in 2004 as a Junior Software Developer. As he gained experience with more and more projects, he was promoted to leadership roles.
The Hague, Netherlands
Praha, Czech Republic
UK Business Development
Richard has over 15 years of sales and account management expertise in the IT and Tech sector. He has worked on many outsourcing engagements with global companies.
Gloucestershire, United Kingdom
David is a business development professional with more than 20 years’ experience as a specialist in the acquisition of partnerships and IT/software services for associations, not-for profits and corporations in Australia, New Zealand and USA. He has specific expertise in the healthcare, legal and hospitality industries.