Incorporating Testlab to your buying process

This document describes the benefits of using Testlab as part of your project management and gives pointers on how you should incorporate the tool as part of your project buying process. Each section of this document features a summary of benefits regarding your field of expertise.

The buying process introduced in this document refers to a situation, where you as an organization acquire project implementation from a vendor partner. If your organization has in-house development practices it might be fruitful to familiarize yourself to the benefits and practices of using Testlab in project delivering organizations and in product developing organizations too.

  • Introduction – for organizations acquiring projects

    There are as many models to buy software as there are organizations. The goal of all models is to acquire software that fulfills the business need as economically as possible. Each model strives to avoid budget and timetable overruns and acquire good quality software.

    To simplify things, let’s divide the project acquiring process into three prime phases:

    Analysis & Tendering

    Feasibility ≎ Tendering


    Project management ≎ Vendor development


    Maintenance ≎ Further development

    The Analysis & Tendering activity consists of the requirement analysis phase, where the feasibility for the new software is confirmed and of the tendering phase, where the project development partner is chosen. In addition, before kicking off the project the implementation must be planned to the suitable level to ensure, that the time tables and budgets agreed on tendering phase are as accurate as possible. The goal of Analysis & Tendering is to analyze and plan the project requirements and find the best possible vendor to deliver the software.

    The Implementation activity consists of managing the project and committing the needed resources for the development of the software by the vendor. The goal of Implementation is to construct and deploy the software fulfilling the requirements in the best way possible.

    The Maintenance activity consists of the use of the acquired software and possible further development of the software involved. The goal of Maintenance is to capitalize on the investment made to the project and optimize gains with further development.

    Keep in mind, that these activities might be more distinct or simultaneous depending on the buying model in your organization and on the project in question.

  • Analysis and Tendering

    The analysis and the tendering phase have two distinct and important goals:

    • To plan the software to be acquired to the stage, that the feasibility of the implementation can be decided and
    • go through a tendering process to choose the best vendor for the implementation of the project.

    The analysis for the feasibility of the project often consists of a return of investment analysis which aims to investigate if the software project makes a sensible investment. For simplicity, let’s assume the project passes as viable and proceeds.

    As the planning of involved software proceeds, it should be seen as a contract between you and your soon to be chosen vendor on what actually has to be constructed. To agree on the effort involved, it is essential to plan the implementation to the point where the terms between you and your customer can be agreed on. This is best done by gathering requirements for the software to Testlab.

    You can document your requirements in a way that best fits the specification and project process you aim to. If you already have a hunch on the software development method your future project vendor might use, it is recommended to document the specification in the format that fits best with this process. For example, if your vendor is using Agile methods such as Scrum, documenting the requirements as user stories are the best fit. You may also document the requirements in some other format to Testlab (such as use cases or traditional business requirements) but the important thing to remember is to commit your vendor to document their specification to your Testlab.

    Regarding your software’s specifications, an important thing must be remembered. The implementation of your software is just a small part of the total cost of your software when the whole life cycle of the system is considered. It’s often the case, that most expenses for the system come from the use, maintenance and further development of the software in the future. It’s crucial, that as a software acquiring party, you make sure you also acquire and/or document as good specification and test plans as possible for your software. This ensures, that the maintenance and further development of your system are as easy and cost-effective as possible.


    How-to & Benefits

    With Testlab, you should document your requirements (business requirements, user stories, use cases, whatever you prefer using) to a Testlab project. If you prefer, you can utilize approval-workflows of Testlab to collaborate with your project implementing partner. Storing requirements to Testlab is great in a way that these requirements can be used as they are when proceeding to project implementation.

    Remember, that it is essential that the user stories and requirements of the project are kept up to date in your Testlab project. This ensures that your project is well documented when it completes.

    For Project Managers
    • Achieve standardization of the documentation between projects
    • Collaborate better with your chosen project vendor
    • Having all quality-related assets linked together gives unprecedented visibility and reporting possibilities compared to the situation, where assets are distributed among systems
    • Reporting and metrics ensures better response to change
    • Get better traceability on change in your project for later reference
    For Project Vendor
    • Easy to use tool helps to keep specification up to date
    • Make the transition from the specification phase to implementation easier
    • Achieve trust in the specification through collaboration with you
    • Technical design and implementation is easier when the design relies on approved requirements you can trust on
    For Executives
    • Maximize the return of investment in your projects
    • Minimize risks of budget overruns
    • Minimize risks of deadline overruns
    • A good specification can be leaned on in agreement disputes
    • Minimize costs of maintenance and further development
    • Good documentation and specification of your software prevents vendor locking



    Long story short, you should document and keep your specification of the project in your Testlab project. Specification of your software is a crucial and valuable asset for your organization driving the better return of investment for you and for minimizing expenses in the maintenance phase.

  • Implementation

    The project implementation consists of all tasks related to the actual construction of the system. Most work here is done by your chosen vendor, but all software projects require committed resources from your organization too including the necessary people managing the project.


    As explained earlier, it is important to document the specification for your software in Testlab and in addition, keep the existing specification up to date. To ensure that the software implemented conforms to the requirements in your specification, it is verified by testing it. For testing, there various different methods that your vendor might apply. Regardless of the testing process applied, it is important that you commit your vendor to document the test cases for your software to your Testlab. This is important because the test plan is a valuable asset in the maintenance phase of your system and also, it is often used as it is in the acceptance testing phase most often executed by the people in your organization. Keep in mind, that the test cases documented can and should be linked to the specification’s requirements in your Testlab. This way, you get traceability from test cases and from found issues all the way to the specification which gives you great reporting possibilities in Testlab.

    Issue management

    When testing, issues in the implementation are found. They are recorded to Testlab as issues that might be defects or in a good case, new features or enhancement ideas. Issues are usually recorded by testers – your vendor or maybe your own testers in the acceptance testing phase.

    Issues can be seen as tasks that should be somehow resolved. In the most common case when the issues are bugs and defects, the issues are assigned to responsible developers, fixed, and marked as resolved. Team members responsible for testing then re-test the issues.

    Issue management is a very common practice in any software project by efficiently tracking open issues in the project gives you good visibility on the current status of your project.

    How-to & Benefits

    With Testlab, you plan and document test cases to your Testlab project. Test cases are organized and executed in test runs and testing results are recorded to the project. Issues encountered are recorded, resolved and handled to a conclusion.

    For Project Managers
    • Easy access to the status of the testing
    • Get efficient reporting
    • Supports team collaboration
    For Project Vendor
    • Easy access to the project specification
    • Make issue management easy
    • Trace issues back to the specification
    • Supports team collaboration
    For Executives
    • Get better metrics on project quality
    • Achieve continuous improvement on project quality
    • Good testing practices lead to lesser costly late found defects and to cost savings

    Make sure that your vendor documents the test plan as test cases in Testlab. When testing, execute test cases and document findings to issues. Monitor project progress against open, resolved and closed issues. From feedback learned from issues make sure that the specification and related test cases get updated to achieve continuous improvement in your projects.

  • Maintenance

    Your software is now implemented, accepted by you and the use of the software begins. We say the system is now in maintenance.

    Before the deliverable in your project can be Used, it is deployed for the customer. Typically, when the system is deployed successfully and accepted by the customer, it continues to be maintained.

    Maintenance and follow-up development

    As your software is maintained, it is typical that issue management takes a bigger role. Using issue management, any issues encountered in the production system get resolved in your process. You should agree with your vendor, that your Testlab is used as an issue tracker for your project. This ensures, that all issue history gets record to your system and gives valuable information for the future maintenance and further development of your software. Using Testlab as a ticket system is preferred, as issues can be configured to trigger e-mail notifications that keep all parties informed.

    Any follow-up development or further projects on the same software, using Testlab gives immediate benefits. The specification and the test plan in your Testlab project can be used as it is for further testing of new versions. Revising existing requirements and/or user stories and adding new ones, you can create the basis for the development of your follow-up projects.


    How-to & Benefits

    Manage the issues encountered in Testlab. Continue development of follow-up projects in Testlab and utilize all assets created so far as they are.

    For Project Managers
    • Get confidence in delivery quality
    • Easy reporting of the project
    • Increase vendor commitment through collaboration
    • Kick-off followup projects more efficiently
    For Project Vendor
    • Kick-off follow-up projects more efficiently
    • Handle maintenance tickets more easily
    • Collaborate better with you
    For Executives
    • Increase user satisfaction
    • Increase the return of investment on further development and maintenance
    • Increase cost-effectiveness of maintenance and support
    • Avoid vendor locking due to up to date documentation on your software


  • Just get me started

    To keep things simple, how should you start with Testlab to get easy gains? You should start the use of Testlab with three goals:

    1. Make sure to plan and specify the requirements of your software to be acquired to Testlab. This can be done directly to Testlab or, the specification can be easily imported from your JIRA, Pivotal Tracker or Excel.
    2. Collaborate with your vendor using Testlab, and make sure, that your project vendor agrees with the requirements set for the project. Think of the requirements in Testlab as a contract between you and your project vendor on what has to be done and delivered.
    3. Require, that your project vendor plans the testing and handles issues in Testlab. Test plan for your delivered software is a valuable asset especially in further development on your project and in addition, avoids vendor locking in future projects.

    Following these three steps gives you immediate gains on risk management of your projects, increases the satisfaction on delivered implementation and makes your projects more cost-effective.

    If you have any questions or would like to talk with us more, please don’t hesitate to contact us. We are more than glad to help you in your efforts to get the best of your software projects.