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:

  1. Define the test strategy and testing plan
  2. Execute on testing
  3. 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

Specific test data may also be necessary for certain types of business scenarios. Producing test data is the responsibility of the testing team and requires technically skilled testers. When preparing long xml or json files, they need to be varied to cover different cases and then updated once related functionality is changed. At First Line Software our testers use Python, JavaScript, Powershell, or other widely used languages to optimize this time-consuming work.

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.

Read Part 2

Download Case Study

Contact Us



Cambridge MA

1 Broadway,
14th Floor,
Cambridge MA 02142 +1 877-737-7178


San Mateo CA

400 Concar Dr,
San Mateo California
94403 +1 877-737-7178


The Hague

Louis Couperusplein 2,
4th floor 2514HP,
The Hague +31 70 512 1899


Sydney | Brisbane

12 Creek Street,
Brisbane QLD 4000 +61 2 8111 5900
United Kingdom

United Kingdom


Cowley House,
12 Black Jack Street Cirencester
Gloucestershire, GL7 2AA +44 7771 787840
Czech Republic

Czech Republic


Na Hřebenech
II 1718/8,
140 00 Praha 4 +420 721 537 689
Czech Republic

Czech Republic


Centrum, Šumavská,
Šumavská 416/15,
602 00 Brno +420 721 537 689



Narodnog Fronta Bb, Becici +382 67 136 640

Send us a note

We'll do our best to answer within one hour