Testing / PractiTest Interview Questions

PractiTest is a cloud-based, end-to-end test management platform that supports the full lifecycle of QA and testing work, from requirements through test design, execution, and defect tracking.

Rather than treating requirements, tests, and issues as separate, disconnected checklists, PractiTest links them together so a team can trace a single requirement all the way through to which tests cover it and which issues came out of running those tests.

• Organizes work into four core modules: Requirements, Test Library, Test Sets & Runs, and Issues
• Supports both manual and automated testing in the same platform
• Provides dashboards and reports for real-time visibility into QA progress

Teams commonly choose it for its flexible custom fields, hierarchical filters, and integrations with tools like Jira, Jenkins, and Selenium.

PractiTest organizes all QA work into four interconnected modules.

These four modules are interconnected: a requirement links to tests in the Test Library, those tests get executed inside a Test Set, and a failing run can generate an issue automatically, giving full traceability from requirement to defect.

A Test Set is a group of tests that a team wants to run together for a unified purpose, such as a regression pass, a smoke test, or a sanity check before a release.

• Tests are added to a Test Set as Test Instances, not as separate copies of the original test case
• Test Sets can be organized and filtered like any other entity, for example by sprint or release
• A Test Set can be created directly from the Test Library, from the Requirements module, or from scratch inside Test Sets & Runs

Grouping tests this way lets a team plan and track execution as a cycle, rather than running individual tests in isolation.

A Test Instance is the specific occurrence of a test case inside a particular Test Set, used to record the actual results of running that test.

Because a Test Instance references the original test case rather than duplicating it, any update made to the test case in the Test Library is automatically reflected everywhere that test is used as an instance, without needing to edit each copy separately.

• Holds its own run history, status, and any linked issues for that specific execution
• Lets the same test case be reused across many Test Sets without maintaining multiple versions
• For BDD tests with a scenario outline, PractiTest automatically creates one test instance per example row

The Requirements module is where teams define and organize what needs to be tested, then link each requirement to the tests that verify it.

• Supports full traceability by connecting requirements directly to tests and, indirectly, to issues
• Automatically calculates each requirement's coverage status from its linked tests' latest run results
• Can be organized using the same hierarchical filter system used across other modules

This gives stakeholders a direct answer to whether a requirement is actually tested and passing, without manually cross-referencing spreadsheets.

The Issues module is where bugs, tasks, enhancements, and feature requests are logged, viewed, and managed.

• Issues reported directly from a failed Test Run using the Fail & Issue button appear here automatically
• Can be managed entirely inside PractiTest, or synced with an external bug tracker such as Jira or ClickUp
• Supports batch editing so multiple issues can be updated at once

Even when issues are synced to an external tool, PractiTest still shows them in the Issues module with a link back to the synced issue, keeping one unified view of tests and defects.

Hierarchical Filter Trees let teams view entities like requirements, tests, test sets, and issues organized under nested, drill-down groupings based on field values, rather than as one flat list.

• Filters can be built on any field, such as application component, priority, or sprint
• Auto filters automatically generate a sub-filter for every value of a chosen field
• Cross filters let one module's filter tree be based on a filter defined in a different module

This is often cited as one of PractiTest's more distinctive features, since it turns a plain grid of entities into a navigable structure that mirrors how a team actually organizes its work.

A Milestone is a project management entity used to define a high-level testing objective within a specific timeframe, such as a sprint or a version release.

• Requirements, Test Sets, and Issues can all be linked to a Milestone
• Provides a quick, single view of overall progress toward that objective
• Commonly used to track a sprint's testing status or the readiness of a release

Where filters organize entities by any field, Milestones specifically group work around time-bound goals, giving a project-management layer on top of day-to-day test execution.

Custom Fields let teams add their own data points to Requirements, Tests, and Issues beyond PractiTest's built-in fields, effectively tailoring each entity to a team's own process.

• Support types such as list, multi-list, and linked-list values
• Can be marked mandatory, shown with an asterisk in the interface
• Feed directly into filters and dashboard graphs, since filters are built on field values

Custom Fields are also commonly used to smooth data migration from other tools, letting imported data map cleanly onto fields that match a team's existing terminology.

The Test Library is where test cases are created and maintained as reusable assets, independent of any specific Test Set they might later be run in.

• A single test case can be added as a Test Instance to many different Test Sets
• Editing the test case in the Test Library updates it everywhere it's used
• Supports both manual test steps and automated test definitions

This separation between the test case itself and a specific run of it is what makes large-scale test maintenance manageable as a codebase and its test suite both grow.

Fast Filters let a user quickly narrow down the entities shown in a grid using a single field value, without building a full saved filter first.

• For example, selecting a Showstopper priority value in the Issues module immediately narrows the grid to just those issues
• Can be applied on top of an existing filter view for further drill-down
• Can be saved as a new permanent filter afterward with a single click

They're meant for quick, on-the-fly narrowing, while full Hierarchical Filter Trees are meant for a more permanent, structured organization of the data.

FireCracker is PractiTest's tool for importing automated test results from CI/CD pipelines directly into the platform.

• Automatically imports JUnit or NUnit result files
• Displays the imported results alongside manual test results in the same Test Sets & Runs module
• Simplifies reporting on CI/CD test results without manual data entry

This is what lets a team maintain one unified view of both manual and automated test execution, rather than tracking automated results in a separate CI dashboard.

SmartFox is one of PractiTest's AI-powered capabilities, used to help generate test cases more efficiently.

• Aimed at reducing the manual effort of writing test cases from scratch
• Part of a broader set of AI features PractiTest has added alongside traditional manual test management

Alongside SmartFox, PractiTest also offers a Test Value Score, another AI-driven feature focused on helping teams prioritize which tests matter most.

Test Value Score is an AI-powered capability in PractiTest aimed at helping teams optimize and prioritize their testing process.

• Helps identify which tests carry more value or risk coverage, supporting smarter prioritization decisions
• Complements SmartFox, which focuses on test creation, by focusing instead on evaluating existing tests

Together, these AI features reflect a shift in test management tools toward not just organizing tests, but actively helping teams decide what to test and in what order.

PractiTest is built to fit into an existing development and QA toolchain rather than replace it, offering two-way integrations across several categories of tools.

• Bug trackers: Jira, ClickUp, and similar tools
• Automation and testing tools: Selenium and similar frameworks
• CI/CD tools: Jenkins and pipelines that produce JUnit/NUnit results consumable via FireCracker
• Source control platforms: GitHub

These integrations are what let PractiTest serve as a central hub, pulling automated results in and pushing issues out, rather than forcing a team to check multiple disconnected dashboards.

PractiTest is a cloud-based platform, meaning teams access it through the browser rather than installing and maintaining it on their own servers.

• Removes the operational burden of hosting, patching, and scaling the platform yourself
• Supports teams of varying sizes without needing dedicated infrastructure
• Updates and new features roll out centrally rather than requiring a manual upgrade per installation

This is a common trade-off in test management tools: convenience and lower operational overhead in exchange for depending on a third-party vendor to host your QA data.

A Requirement's status in PractiTest is derived automatically from the latest run results of the tests linked to it.

Because this status is calculated automatically from the latest run results of linked tests, a requirement's coverage status always reflects real execution data rather than a manually maintained checkbox.

Test Set Permutations let a team take an existing Test Set and automatically generate multiple copies of it for different combinations, such as different platforms, languages, or configurations.

• Useful when the same tests need to run repeatedly across many environment combinations
• Can only be created from an existing Test Set, not from scratch
• Saves the manual effort of duplicating a Test Set by hand for each combination

It's commonly used alongside the batch clone feature when preparing a new iteration or sprint that reuses the same core tests across multiple variations.

Cross-Project Reporting lets managers generate reports that span multiple projects at once, rather than being limited to a single project's data.

• Gives a high-level view of testing effort and status across an entire organization or product line
• Useful for leadership that needs visibility across teams without digging into each project individually
• Built on the same underlying reporting engine used for single-project reports

This matters for larger organizations running many parallel PractiTest projects, where a project-by-project view alone wouldn't answer questions about overall QA health.

Filters mode is the recommended way to organize entities like requirements, tests, test sets, and issues into dynamic, cascading, hierarchical groupings based on their field values.

• Lets a team build a filter tree that reflects how they actually think about their project, such as by component, by sprint, or by owner
• Filters update dynamically as entity field values change, rather than requiring manual re-sorting
• Can be combined with fast filters for quick, temporary narrowing on top of an existing filter

Filters mode is what turns a simple entity grid into a navigable structure that scales as the number of requirements, tests, or issues grows into the hundreds or thousands.

PractiTest's publicly listed plans have generally followed a per-user, per-month structure with a minimum number of tester licenses, though pricing details are best confirmed directly on PractiTest's site since they can change.

• Professional: priced per user per month, with a minimum of 3 tester licenses
• Enterprise: a higher per-user, per-month tier, also with a minimum of 3 tester licenses, aimed at larger or more complex needs
• Unlimited: a custom tier requiring direct contact with PractiTest for pricing

The tiered structure reflects a common SaaS pattern: broader capability and scale at each step up, with the top tier reserved for organizations whose needs don't fit a standard published price.

Batch Edit lets a user select multiple issues at once, using the checkboxes in the grid, and apply the same change to all of them in a single action.

• Useful for updating status, priority, or other fields across many issues after a triage session
• Avoids opening and editing each issue individually one at a time
• Works the same way conceptually across other modules that use a similar grid layout

For teams dealing with a large backlog of issues, this kind of bulk action turns what would be a repetitive, tedious task into a single click.

While executing a Test Instance inside a Test Set, a tester can press the Fail & Issue button to log a failure and create a linked issue in the same step.

• Automatically marks the Test Instance's result as failed
• Creates a new issue that's automatically linked to that specific Test Instance and, transitively, to its Requirement
• The new issue immediately appears in the Issues module alongside issues created directly there

This shortcut avoids the disconnect of a tester noting a bug on the side and separately logging it later, since the issue is captured with full context at the moment it's found.

Test Case Reusability is the design principle that a single test case, created once in the Test Library, can be used as a Test Instance across many different Test Sets without duplicating it.

• Any edit to the original test case automatically propagates to every place it's used
• Avoids the maintenance burden of updating dozens of copies of the same test individually
• Directly addresses the common problem of test suites becoming unmanageable as they grow

This is described as one of the core problems PractiTest is built to solve: keeping test cases relevant and consistent even as a product's features change rapidly.

PractiTest supports a BDD test type that can include Scenario Outlines with example rows, similar to Gherkin-style feature files used in behavior-driven development.

• When a BDD test with a Scenario Outline is added to a Test Set, PractiTest automatically creates a separate test instance for each example row
• Removes the manual work of creating one instance per data variation by hand
• Keeps BDD-style tests organized inside the same Test Sets & Runs structure as other test types

This lets teams practicing BDD keep their scenario outlines and data tables intact while still getting PractiTest's usual execution tracking and reporting on top.

In short, a Test Set is the plan, the group of tests you intend to run, while a Test Run is what actually happened each time you executed them.

A standard Filter organizes entities within a single module based on that module's own field values, such as filtering Tests by their component field.

A Cross Filter, by contrast, is built in one module but bases its criteria on a filter that already exists in a different module.

• Example: creating a filter in the Issues module that reuses a Sprint filter already defined in Test Sets & Runs
• Keeps filter criteria consistent across modules instead of redefining the same grouping logic twice
• Updates automatically if the source filter it's based on changes

Cross Filters are especially useful for teams who want a single source of truth for something like which sprint, reused consistently across Requirements, Tests, and Issues.

A Requirement's status is derived entirely from the latest run results of the Tests linked to it, rather than being manually set by a user.

1. If no tests are linked at all, the status is NOT COVERED
2. If tests are linked but none have been run, the status is NO RUN
3. If at least one linked test has started running without failing or being blocked, the status is STARTED
4. If all linked tests passed, the status becomes PASSED
5. If any linked test was blocked, without any failures, the status is BLOCKED
6. If any linked test failed, the status is FAILED, taking priority over blocked or started states
7. If every linked test is marked N/A, the status is N/A

This automatic calculation is what makes requirement traceability trustworthy: the status can't drift out of sync with actual test execution the way a manually updated field could.

An Auto Filter automatically generates a sub-filter for every distinct value of a chosen field, rather than requiring someone to build one filter per value by hand.

• Saves setup time when a field like Component or Priority has many possible values
• Stays current automatically if new values are added to the underlying field later
• Supported for list, multi-list, linked-list fields, and milestones

Manually creating a filter for each value works fine for a small, stable set of options, but becomes tedious and error-prone as the number of values grows or changes over time, which is exactly what Auto Filters are meant to remove.

Either way, issues still appear in PractiTest's Issues module, giving testers one place to see both test results and defect status regardless of where the actual issue record lives.

Traceability in PractiTest comes from explicitly linking each Requirement to the Tests that verify it, so the platform can answer whether a requirement is actually covered and currently passing without any manual cross-referencing.

• A Requirement with no linked tests is immediately flagged as NOT COVERED
• Every run of a linked test rolls up into that Requirement's overall status
• Reports and dashboards can show coverage and pass rates at the Requirement level, not just at the individual test level

This link is also what lets teams answer audit-style questions, like proving that every requirement in a release has at least one passing test behind it, directly from the platform rather than a separate spreadsheet.

As a product grows, the number of test cases needed to cover it grows too, and keeping hundreds or thousands of individually maintained test cases consistent becomes its own significant burden.

• Reusability means a test case is defined once in the Test Library and referenced everywhere it's used
• A single edit, like fixing a step or updating expected behavior, propagates automatically to every Test Set that includes it
• Avoids the drift that happens when duplicated copies of a test case are updated inconsistently over time

This is explicitly framed as one of the core problems PractiTest is designed to solve, since maintaining test relevance at scale is one of the biggest practical challenges growing QA teams run into.

Thinking of it as authoring versus execution is a useful mental model: the Test Library is your library of reusable scripts, while Test Sets & Runs is where you actually perform and record a specific reading of those scripts.

Both features help generate multiple similar Test Sets, but they're suited to slightly different situations.

• Use Permutations when you need many combinations of the same Test Set for different configurations, such as testing across several browsers, languages, or platforms at once
• Use Batch Clone when you simply need to duplicate existing Test Sets for a new iteration, such as carrying the same regression suite forward into the next sprint

In practice, Permutations solve a combinatorial problem, generating many variants from one base Test Set, while Batch Clone solves a repetition problem, carrying the same Test Sets forward unchanged into a new cycle.

A simple list view just shows every entity in a module in one flat, unorganized list, requiring manual searching or sorting to find anything specific.

• A Filter Tree instead organizes entities into nested, drill-down groupings based on field values
• Supports multiple independent trees over the same data, for example organizing Tests by testing level in one tree and by application component in another
• Groupings update dynamically as underlying field values change, rather than needing manual re-sorting

The practical difference shows up at scale: a flat list of a thousand test cases is hard to navigate meaningfully, while a filter tree lets a tester jump directly to a specific nested grouping in a couple of clicks.

Filters organize entities by any field value, but they don't inherently represent a time-bound goal the way a Milestone does.

• A Milestone explicitly represents an objective with a defined timeframe, like a sprint or release
• Requirements, Test Sets, and Issues can all be directly linked to the same Milestone, giving one unified view of everything relevant to that goal
• Dashboards can be built specifically around Milestone progress, showing overall readiness rather than just a filtered list

In practice, teams often use both together: filters to organize the day-to-day grid view, and Milestones to track whether a specific sprint or release is actually ready to ship.

Based on PractiTest's publicly listed plans, Professional and Enterprise both follow a per-user, per-month structure with a minimum tester license requirement, with Enterprise sitting at a higher price point aimed at organizations with larger or more complex needs.

• Both tiers require a minimum of 3 tester licenses
• Enterprise is priced higher per user per month than Professional
• Beyond these two published tiers, an Unlimited option exists that requires contacting PractiTest directly for custom pricing

As with most SaaS pricing, it's worth checking PractiTest's current pricing page directly before quoting exact figures in a real conversation, since these tiers and prices can be updated over time.

Without a dedicated shortcut, logging a defect found during testing typically means finishing the test run, then separately opening the Issues module, then manually re-establishing the link back to the test and requirement involved.

• The Fail & Issue button collapses this into one action: marking the Test Instance as failed and creating the linked issue simultaneously
• The resulting issue automatically carries context from the test, avoiding a tester having to manually re-describe what was already documented in the test steps
• The issue immediately becomes visible in the Issues module, whether managed natively or synced to an external tracker

This tight coupling between failing a test and logging its issue is a big part of why PractiTest can claim full traceability from requirement to test to defect without extra manual bookkeeping.

Every organization structures its QA process a little differently, so a fixed set of built-in fields would inevitably be too rigid for some teams and missing fields for others.

• Unlimited custom fields let each team model its own process, whether that's tracking a Browser field on Requirements or a Root Cause field on Issues
• Custom fields feed directly into filters and dashboard graphs, so this flexibility extends into reporting, not just data entry
• Supports smoother migration from other tools, since imported data can map onto fields that match a team's existing terminology instead of forcing a rename

This flexibility is explicitly called out as one of PractiTest's more valued features, precisely because it lets the tool adapt to a team's process instead of the other way around.

When a BDD-type test containing a Scenario Outline is added to a Test Set, PractiTest doesn't just add a single Test Instance the way it would for a regular test case.

• It automatically generates one Test Instance for every example row defined in the Scenario Outline
• Each of those instances can be executed and tracked independently, with its own pass/fail result
• This keeps data-driven BDD scenarios organized the same way as any other test, without requiring manual duplication of the base scenario

This matters for teams practicing BDD because it preserves the intent of a scenario outline, testing the same behavior across multiple data examples, while still getting individual execution tracking for each example.

1. Creation: a Requirement is created with no tests linked yet, so its status defaults to NOT COVERED
2. Linking: one or more Tests are linked to the Requirement, moving its status to NO RUN since none of them have executed
3. Execution begins: as soon as a linked test starts running without failing or being blocked, the status becomes STARTED
4. Resolution: once execution finishes, the status resolves to PASSED if every linked test passed, FAILED if any failed, BLOCKED if any was blocked without a failure, or N/A if every linked test was marked not applicable

Because this status recalculates automatically every time a linked test's result changes, a Requirement's coverage status is always a live reflection of current test results rather than something that needs to be manually updated as tests run.

A Hierarchical Filter Tree is built by chaining filter criteria together so that entities are grouped under nested, drill-down categories rather than one flat list.

1. A base filter is defined on a field, such as grouping all Tests by Application Component
2. Child filters can then be nested under it, for example splitting each component further by testing level, like Regression versus Smoke
3. Auto Filters can generate this nesting automatically for every value of a field, rather than requiring each branch to be built by hand
4. Cross Filters let a branch in one module's tree be based on a filter that already exists in a different module, keeping the same grouping logic reused consistently

The result is that the same underlying set of entities, tests, requirements, or issues, can be viewed under multiple independent trees at once, since filters are just saved queries rather than a single fixed folder structure the data has to live inside.

1. The tester opens a Test Set and selects a specific Test Instance to run
2. They work through the test's steps, recording pass/fail for each as they go
3. If a step doesn't behave as expected, the tester marks the Test Instance as failed
4. Pressing Fail & Issue creates a new Issue automatically linked to that Test Instance
5. The Requirement linked to that test, if any, has its status recalculated, moving to FAILED since a linked test just failed
6. The new issue is now visible in the Issues module, whether it stays native to PractiTest or is synced to an external tracker

Because each of these steps happens as part of the same execution flow, a single failed test click produces a fully linked chain, from a specific test step, to an issue, to an updated requirement status, without any separate manual bookkeeping.

As a project's requirements, tests, and issues grow into the thousands, an unstructured filter tree becomes as hard to navigate as no filters at all, and cross-project reporting only compounds that if different projects organize things inconsistently.

• Standardize a common set of custom fields and filter categories across projects, so a Cross-Project Report can meaningfully group data from each one
• Use Auto Filters for high-cardinality fields, like Component or Owner, instead of manually maintaining a branch per value
• Rely on Cross Filters to keep shared groupings, like Sprint or Release, consistent across Requirements, Tests, and Issues within each project
• Periodically prune or archive stale filters that no longer map to active work, so the tree doesn't accumulate clutter over multiple release cycles

The underlying principle is that Cross-Project Reporting is only as useful as the consistency of the filter and field structure feeding it, a report spanning ten projects with ten different ad hoc field naming conventions won't roll up cleanly.

1. Confirm whether any Tests are actually linked to the Requirement at all, since NOT COVERED specifically means zero linked tests
2. If tests should be linked but aren't showing, check whether the link was created on the correct Requirement, since a link can accidentally end up on a similarly named one
3. Verify you're looking at the right Requirement Coverage scope, since coverage can be scoped either to the last run of a linked test overall, or to runs within specific selected Test Sets
4. If using an integration with Jira or Azure DevOps, confirm the PractiTest panel inside that tool is reflecting the same linked tests, since a sync delay could show stale information
5. As a last step, manually re-link the intended tests to the Requirement and confirm the status updates immediately, since the calculation is automatic and shouldn't require a refresh

In almost every case, a persistent NOT COVERED status comes down to a genuinely missing link rather than a display bug, since the status calculation itself is a straightforward, automatic reflection of linked tests.

Neither replaces the other, and PractiTest's own guidance points toward using both together: Filters for structural, ongoing organization of tests by criteria like component or level, and Milestones layered on top for tracking whether a specific sprint or release is actually on track. Treating them as competing options misses that they answer different questions, how is this organized versus are we ready by this date.

1. A CI/CD pipeline, such as one running through Jenkins, produces a standard JUnit or NUnit XML results file after an automated test run
2. FireCracker ingests that result file and parses the individual test outcomes it contains
3. Those outcomes are mapped onto the corresponding Test Instances inside PractiTest's Test Sets & Runs module
4. The results appear in PractiTest exactly like manually executed test results would, complete with pass/fail status
5. Any Requirement linked to those tests has its coverage status recalculated based on the newly imported results

The practical effect is that a team doesn't need a separate CI dashboard to know whether automated tests passed, since FireCracker folds those results directly into the same traceability chain used for manual testing.

1. Creation: a Test Set is created, either from scratch or from a chosen set of tests in the Test Library or Requirements module
2. Populating: tests are added to it as Test Instances, referencing the reusable test cases from the Test Library
3. Permutation, if needed: the base Test Set is used to generate multiple variant Test Sets for different configurations, such as browsers or platforms
4. Execution: testers work through each Test Instance across every generated permutation, recording pass, fail, blocked, or N/A results
5. Reporting: dashboards and reports aggregate those results, and any linked Requirements have their coverage status recalculated accordingly

The permutation step is what scales a single authored Test Set into full coverage across many configuration combinations, without requiring the team to hand-build a separate Test Set for every combination from scratch.