4 interesting ways of adapting TestFLO to your testing process


24 May 2018 • 11 min read

    If you’re looking for a process that will work every single time and in every single case, prepare for failure.

    Every organization and its projects have specific characteristics that need to be taken into account when designing workflows, rules, and best practices. Most of the time, it’s not about pure creativity but compliance with legal or industry standards.

    Organizations tend to look for solutions that are tailored to match their needs or are flexible in configuration. When designing Jira, Atlassian was aware of that and made their product as configurable as possible. Combining Jira with apps available on the Atlassian Marketplace extends the number of available options, allowing organizations to craft their own processes effortlessly.

    We followed a similar philosophy when we created our app TestFLO.

    Our experience suggests that various organization have different needs when it comes to the testing process. That’s why we decided to make our tool adaptable instead of forcing organizations to change their testing process. TestFLO is highly configurable and allows implementing different concepts of test management within Jira depending on a team’s needs.

    Here are 4 interesting methods for adapting TestFLO to your testing projects.

    1. Simple solution

    This concept is easy to implement. All it takes is integrating its elements into the project where you also manage your requirements and create bugs. That type of all-in-one attitude is very beneficial. All the tests and other tasks related to the projects will be carried out in a single Jira project.

    This method works best for projects with small teams where we don’t need to implement user restrictions but instead use a single permission scheme. In general, it’s good if the realized project is not a very large undertaking. Remember that TestFLO introduces three types of issues and that alone can cause chaos if we’re dealing with many different issues in a project.

    2. General test management

    In this case, we’re taking a step further because we separate a project for test management where we will locate our test repository as well as test executions. That project can be used for realizing tests for many other development projects. To do that from the project level in TestFLO you only need to indicate the projects where you store your requirements – that’s how you’ll be able to connect your tests with specific issues.

    If you’re carrying out many different projects and they’re all connected to a single team of testers, that solution is a good bet. All the testers will have a single space for managing their work without mixing their tasks with others. Moreover, you can use a dedicated permission scheme for test management projects to, for example, allow only testers to create issues related to testing.

    3. Many applications

    The concept of managing tests in many applications develops the approach presented in the previous point. In this case, for every development project, we create a related test management project. Thanks to the TestFLO project configuration, we can individually indicate the related project where requirements are stored. You can also indicate the project where you will create defects.

    That approach will come in handy if you’re dealing with many unrelated projects that have dedicated testing teams. Each of your teams will have a space for realizing tasks to boost transparency and help testers focus on their batch of work. A great advantage of this type of testing realization is the possibility for individual matching of TestFLO elements to the realized process – for example, the method for test categorization, workflow construction for tests or columns in the Steps field.

    4. Separate test repository

    A separate repository of tests implies the separation of an individual project for storing only test cases. Thanks to the modular structure of TestFLO, we can decide in which project a given module will function so we can allow a test repository to be managed separately. We can decide for each development project to have its own test repository or simply have all the projects that are related using one central repository.

    This test management implementation works best for organizations and projects characterized by specific politics and where a high level of process control is required. Thanks to a separate repository, you can decide that only a specific group of users can create test cases and another execute them. For example, if you want only experienced testers to design tests. That type of configuration boosts team transparency and the project’s organization because you have a separate container where you control all your test cases.

    Key takeaway

    Processes are a key factor in a how the organization functions and how it realizes projects. When managing projects, we want their method of realization to match our needs and reflect the reality as much as possible. We expect that from our tools as well.

    We want our tools to adapt to our process, not the other way around.

    One of the critical characteristics of TestFLO is its flexibility that allows matching the product to individual requirements even if these are different within the same organization.

    That type of philosophy is in accordance with the general vision behind Jira and tools that emphasizes their flexibility, giving full control to users. Thanks to its close integration with Jira, our app TestFLO allows taking advantage of Jira’s native mechanisms which boost its flexibility further.

    Have you got any questions about TestFLO and how it helps organizations craft unique testing processes? Reach out to me in comments; I’m always happy to share my knowledge with the testing community.

    [contact-form-7 404 "Not Found"]