---
title: Guide to building your test plan in Centercode
description: "Turn a product into a schedule your testers can work through: phases that set the calendar, features that name what gets tested, and activities that tell people what to do and what to send back."
---

[Skip to content](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#main-content)

[![New\_Centercode\_Logo.png\]](https://help.centercode.com/hs-fs/hubfs/New_Centercode_Logo.png?height=35&name=New_Centercode_Logo.png)](https://centercode.com/)

- [Help Center Home](https://help.centercode.com/)
- [Starter & Delta Edition Help](https://learn.centercode.com/)

Open main navigation

Close main navigation

- [Help Center Home](https://help.centercode.com/)
- [Starter & Delta Edition Help](https://learn.centercode.com/)
- [Report an Issue](https://centercode.com/issue)

[Report an Issue](https://centercode.com/issue)

 How can we help?

- There are no suggestions because the search field is empty.

1. [Help Center](https://help.centercode.com/en?hsLang=en)
2. [Features & Test Planning](https://help.centercode.com/en/features-test-planning?hsLang=en)
3. [Guides](https://help.centercode.com/en/features-test-planning?hsLang=en#guides)

# Guide to building your test plan in Centercode

## Turn a product into a schedule your testers can work through: phases that set the calendar, features that name what gets tested, and activities that tell people what to do and what to send back.

This article applies to **All** editions.

Recruiting gets people into your project. Your test plan is what you give them to do once they're there.

It's the part of a project that decides whether feedback arrives steadily or in a useless clump at the end, and whether that feedback can be traced back to a specific part of your product or just says "the app." Everything downstream depends on it: your dashboards, your satisfaction scores, the weighting on your feedback, and how well Ted can nudge testers toward the areas nobody has touched yet.

We'll build one here, start to finish: an onboarding phase, one engagement phase, and a single feature inside it with an activity, instructions, and a satisfaction rating coming back. That's a deliberately small plan. The same steps repeat for every feature and every phase after it, because a full test plan is this loop run a dozen times.

If you already know your features and just want them in quickly, skip ahead to [faster ways to build a plan](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#faster).

### Table of contents

- [What a test plan is made of](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#what-a-test-plan)
- [The three phase types](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#the-three-phase-types)
- [Before you start](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#before-you-start)
- [Opening Test plan management](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#opening-test-plan)
- [Step 1: Break the product into features first](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-1)
- [Step 2: Add your phases](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-2)
- [Step 3: Create a feature](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-3)
- [Step 4: Choose how testers engage with it](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-4)
- [Step 5: Write the instructions](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-5)
- [Step 6: Decide what comes back](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-6)
- [Step 7: Set feature access](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-7)
- [Step 8: Align your feedback types](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-8)
- [Features that live outside an engagement phase](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#feature-that-live-outside)
- [Check the plan before your testers arrive](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#check-the-plan)
- [When the schedule changes](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#when-the-schedule-changes)
- [Faster ways to build a plan](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#faster-ways)
- [Best practices for test plans](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#best-practices)
- [Notes](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#notes)

### What a test plan is made of

*![](https://t.gyazo.com/teams/centercode/535b927b0fd9423f41bf952ce06d6862.png)*

Three things do all the work, and they nest.

A **phase** is a block of time. It has a start date, an end date, a type, and a list of teams that can see it. Phases are how you split a test into periods of focus instead of handing people everything at once.

A **feature** is a part of your product you want validated. Setup, battery life, the mobile app, checkout. Features are what tie your activities, satisfaction scores, feedback, and dashboards together, so the names you pick here follow you through the entire project.

An **activity** is the work you ask a tester to do with a feature, along with the instructions for doing it. Every feature in an engagement phase has one. It's the difference between a feature that gets tested and a feature that merely appears in a drop-down.

So the shape is: a phase holds features, each feature carries an activity, and each activity ends with something coming back, usually a satisfaction rating, a survey, or feedback.

💡 **Ted Tip**: When a customer tells me their testers aren't doing anything, I ask where the features are before anything else. Features sitting outside an engagement phase are real, selectable, and completely silent. Nobody is ever asked to test them. It looks identical to a participation problem and it isn't one.

### The three phase types

Every phase is one of three types, and the type changes what testers can do and what Ted sends them.

- **Onboarding**: gets testers settled and ready. This is where you confirm they've received the product, that the software is installed, and that they know their way around. **Testers can't submit feedback during an onboarding phase**, which is deliberate, because feedback filed before anyone has the product is rarely about the product. If Ted is enabled, he sends a series of introductory emails during this phase.
- **Engagement**: the bulk of your test. This is where features and their activities live and where feedback gets collected. Most projects have several engagement phases, each one focused on a different slice of the product. If Ted is enabled, he contacts testers regularly with progress updates and points them at what they haven't finished.
- **Closure**: wrapping up. Coordinating the return of test units, handling incentives, and closing the loop with participants. Testers can still submit feedback during closure, for as long as they have access to the project. If Ted is enabled, he sends a final summary of what each tester completed, and a thank you.

A standard project runs one onboarding phase, several engagement phases, and one closure phase. You don't have to use all three types, but the onboarding phase earns its place more often than people expect. It's where you find out that a third of your testers never got the hardware.

### Before you start

- You need access to the Test plan tool in your project. If you don't see *Test plan* under *Management*, ask a Community Admin to check your team's access. See [**What are Centercode's user roles and access levels?**](https://help.centercode.com/en/team-types-and-user-roles?hsLang=en)
- Your teams should already exist, because phases and features are both scoped by team. See [**Guide to managing user access via Teams**](https://help.centercode.com/en/guide-to-user-team-management?hsLang=en).
- Check the timezone on your *Project settings* page. Phase schedules follow it, and a phase that ends "Friday" ends Friday in that timezone, not in your tester's.
- Have a rough list of what you actually want validated. [Step 1](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-1) is about making that list, and it's worth doing before you open the tool.

### Opening Test plan management

1. From inside your project, click **Management** in the navigation menu
2. Select **Test plan**

This page is your whole plan on one timeline: every phase in order, every feature inside each phase, and the buttons that create more of both. For a field-by-field tour of everything on it, see [**Test Plan Management Overview**](https://help.centercode.com/en/test-planning-overview?hsLang=en).

### Step 1: Break the product into features first

This step happens on paper, not in Centercode, and skipping it is the most expensive mistake in test planning. Feature names are permanent in practice. They appear on feedback forms, in dashboards, in satisfaction comparisons across phases, and in every report you build later. You can rename a feature later, but by then your testers have learned the old name and every piece of feedback filed so far reads as though it were about something else.

Write down the parts of your product that matter to its success. For each one, ask what a tester would have to actually do to tell you whether it works. That question is your activity, and if you can't answer it, the feature is probably too broad to test.

Two rules keep the list honest:

- **Names are short, specific, and unique.** Testers pick features from a drop-down when they submit feedback. Two features with similar names, even in different phases, produce feedback filed against the wrong one.
- **Volume is capped by what a volunteer can give you.** Aim for two to three hours of focused testing per week, per tester. Count the features you're putting in a phase against that, not against how much you'd like to learn.

💡 **Ted Tip**: The fastest way to size a phase is to walk its activities yourself with a timer. Whatever it takes you, someone using your product for the first time will take longer, and they're doing it around a job. If your own pass takes two hours, the phase is full.

### Step 2: Add your phases

 ![](https://t.gyazo.com/teams/centercode/89c150c0db7aedb9be6d87ffe6d0a00c.jpg)    
 

Build the calendar before the contents. It's easier to place features into a schedule that exists than to invent the schedule around features you've already made.

1. From **Test plan**, click **Add a phase**
2. Enter a **Name** for the phase
3. Add a **Description** of what the phase is for
4. Select a **phase type**: Onboarding, Engagement, or Closure
5. *(optional)* On an engagement phase, check the option to include regression features, covered in [features that live outside an engagement phase](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#other-features)
6. Set the **Start date** and **End date**
7. Assign **team access**
8. Save the phase

Four things about this screen catch people out:

- **The phase name is internal.** Your testers never see it. Name phases for your own sanity, not as marketing. "Engagement 2, camera and video" is a better name than "Phase 2."
- **Start dates can chain.** Rather than picking a date, you can set a phase to begin when the previous one ends. When you do, the platform shows you the resulting date and the phase length, such as "This phase will be 7 days long." Chaining is the safer choice, because moving one phase moves everything after it instead of leaving a gap.
- **Phases can't overlap.** Two phases cannot occupy the same window. If a date is rejected, this is nearly always why. See the entry on running phases at the same time in the [**Test Planning FAQ**](https://help.centercode.com/en/test-plan-faq?hsLang=en).
- **The schedule uses the project timezone.** It's set on the *Project settings* page, not per phase and not per user.

### Step 3: Create a feature

 [![](https://t.gyazo.com/teams/centercode/828cb4922fd1f68efe930df296bb6a74.jpg)](https://centercode.gyazo.com/828cb4922fd1f68efe930df296bb6a74)

With a phase in place, add the first thing you want tested.

1. From **Test plan**, click **Create a feature**, or hover over the phase you want and add the feature directly to it
2. Enter the **Feature** name
3. Write a **Feature description**
4. Set the **Feature value**

The name and description are what your testers read. The name appears in the Feature drop-down on feedback forms, so keep it short. The description is where the detail goes, and its job is to help a tester decide whether this feature is the right place to file what they're about to report.

**Feature value** is the field people skip, and it's the one that quietly shapes your results. The value you pick becomes a multiplier on the weight of every piece of feedback filed against that feature. It's multiplied by the feedback's popularity score to produce its impact score, which is how the most important issues rise to the top of your lists.

- None: 0
- Very Low: 0.5
- Low: 0.75
- Neutral: 1
- High: 1.5
- Very High: 2

A value of None means feedback on that feature carries no weight at all, which is occasionally what you want and is otherwise a good way to lose a real problem in the noise. For the full picture of how weight, popularity, and impact combine, see [**Guide to feedback impact scoring**](https://help.centercode.com/en/guide-to-feedback-impact-score?hsLang=en).

💡 **Ted Tip**: Set every feature to Neutral first. Once the whole list exists, read it top to bottom and ask which ones are a little more important, which are a lot more important, and which you'd rather not hear about. Relative judgments are much easier than absolute ones, and you can only make them once you can see everything side by side.

### Step 4: Choose how testers engage with it

![](https://t.gyazo.com/teams/centercode/25a1a445683668b5d877d7513130f563.png) 

This is where a feature becomes an activity. Your selection here tells the platform what kind of work you're asking for, and it changes what the tester is given.

- **Exploratory task**: the tester uses an area of the product naturally and reports back. Open ended by design. Use it when you want to find out what people do, rather than confirm they can do one specific thing.
- **Prescriptive task**: the tester follows a specific sequence of instructions. Use it when there's a defined path you need validated, such as a setup flow or a migration.
- **Recorded interview**: the tester records themselves talking about their experience. You provide both what they should discuss and how to record it.
- **Recorded experience**: the tester records themselves using the product, by webcam or phone camera.
- **Recorded screen**: the tester captures their screen. Useful for software workflows, account creation, and anything where what they clicked matters as much as what they said.

The three recorded options add a capture element the tester has to complete before the feature is done, and they unlock a video configuration section covered in [Step 5](https://help.centercode.com/en/guide-to-building-your-test-plan-in-centercode#step-5). See [**Guide to capturing recorded video with Centercode Replays**](https://help.centercode.com/en/how-to-capture-recorded-video-via-replays?hsLang=en) for what testers experience on their end.

##### Activity options

Two settings change whether and when a tester has to do this activity:

- **Optional**: testers are still asked to complete the activity, but they can say they didn't do it and don't plan to, which lets them opt out of the feature. Use it for features that only apply to some testers, such as a peripheral not everyone owns.
- **Conditional**: requires at least one other feature in your plan. Pick that other feature from the drop-down and this one can't be completed until its activity is finished. Use it to enforce order, such as requiring setup before anyone tests performance.

💡 **Ted Tip**: Conditional is the right tool when a feature genuinely depends on another one, and the wrong tool for sequencing convenience. Every condition you add is another way for a tester to get stuck behind something they can't finish, and you won't see it happen. If the only reason is "I'd prefer they do this first," use separate phases instead.

### Step 5: Write the instructions

Instructions are built from the same resource elements you use everywhere else in Centercode, so you can write text, add images, attach a quick start guide for download, embed a video, or combine them. For what each element does, see [**Creating Resources in Centercode**](https://help.centercode.com/en/creating-resources?hsLang=en).

If you chose one of the recorded options in Step 4, you'll also see a video capture section here:

- **Video recording instructions**: guidance to help testers capture something usable. Worth writing. Lighting, orientation, and saying what they're doing out loud all make a difference to what you get back.
- **Transcribe recording**: automatically transcribes tester videos, which makes them searchable and far faster to review.
- **Mark as personal data**: treats the recordings as containing PII, which means they're erased if the tester removes their account. Consider this carefully for anything showing a person's face, home, or screen contents.

💡 **Ted Tip**: Give testers a clear endpoint and as little of the route as you can get away with. "Get a second device connected to the account" tells you something real. A numbered list of every tap tells you only whether they can follow a numbered list. When a tester can't figure out how to reach the endpoint, that's not a failed activity, that's your most valuable result of the week.

### Step 6: Decide what comes back

An activity that collects nothing tells you only that someone clicked "done." This section is where you choose what a tester hands you when they finish.

- **Centercode FSAT**: the built-in satisfaction survey. Collects a five star rating and then directs the tester to submit feedback based on how they rated it. This is the simplest setup and it automatically includes both additional steps below.
- **Custom**: attaches one of your own surveys to the activity. The tester is sent to it immediately after completing the activity, and the survey is only available to people who completed that activity. See [**Create (or modify) a survey overview**](https://help.centercode.com/en/create-a-survey-overview?hsLang=en).
- **None**: no survey. You can still collect a star rating using the option below.

**A custom survey can only be attached to one feature.** You can't point two features at the same survey. If you need the same questions in two places, clone the survey and attach the copy.

##### Additional steps

- **Collect star rating**: presents the five star satisfaction score before the tester completes the activity. Without it, they're simply asked whether they completed it. Star ratings are what drive feature satisfaction comparisons on your dashboards, so leaving this off costs you more than it looks like it does.
- **Collect feedback**: includes this feature in the Feature drop-down when testers submit feedback. Leave it on unless you have a specific reason not to, because a feature that isn't in the drop-down can't be reported against.

### Step 7: Set feature access

Choose which teams can see this feature. Anyone without access isn't prompted to complete the activity and won't see the feature listed when they submit feedback.

This is per feature, and it's separate from the team access you set on the phase in Step 2. Both apply. A tester needs access to the phase and to the feature.

Feature level access is available on **Team** and **Legacy** editions.

💡 **Ted Tip**: Feature access is how you run two audiences through one project without building two projects. Hardware testers get the setup and battery features, software-only testers get the app features, and everybody shares the phases, the dashboards, and the feedback pool. It's much less work than it sounds and it's the single most underused setting on this page.

### Step 8: Align your feedback types

One step lives outside the Test plan page, and skipping it breaks the connection between your features and everything downstream.

For testers to file feedback against a feature, each of your feedback types needs a feature element on its form. Without it, feedback arrives unattached, which means no feature dashboards, no impact weighting from the value you set in Step 3, and no way for Ted to tell which parts of the product have been covered.

See [**Feedback properties (and feedback type creation)**](https://help.centercode.com/en/feedback-properties-overview?hsLang=en) for adding the element to a type.

### Features that live outside an engagement phase

Not every feature belongs on the calendar. Three kinds sit outside your engagement phases and behave differently.

*![](https://t.gyazo.com/teams/centercode/532d524bf354062100c9b31172d13158.png)* 

##### Regression features

Features you want tested repeatedly, phase after phase, to confirm that reported problems actually got fixed.

1. Create the feature under the regression heading, or move an existing feature there
2. Modify an engagement phase and check the option to include regression features in that phase

Every regression feature is then included in that phase, and testers are prompted to test them again. Because the feature name stays the same across phases, your dashboards can compare the results side by side, which is the entire point.

One behavior surprises nearly everyone. If a regression feature has a custom survey attached, testers don't get a fresh copy each phase. They're taken back to the response they already gave and asked to update it. That's right when you want one evolving answer per tester, and wrong when you want to compare phase against phase, because each update overwrites what you had. To capture each round separately, clone the survey at the start of each phase and point the feature at the new copy.

##### New user features

Features that testers who join late have to complete before anything else. Downloading the app, registering hardware, reading a primer. A tester with access to new user features is asked to finish those first, and is then given access to the currently active engagement phase, wherever the rest of the group happens to be.

Two limits are worth knowing before you rely on this:

- New user features can't be reset. Once a tester has completed the ones available at the time, they're permanently marked as done for that project.
- Adding more later won't prompt anyone who's already marked complete. Only testers who haven't finished yet will see the additions.

##### Phaseless features

Parts of your product that testers might want to comment on but that you're not actively testing. A phaseless feature appears in the Feature drop-down on feedback forms and nowhere else. No activity, no instructions, no prompting.

Use them for the areas around the edges of your test, and for a catch-all such as "Other" so feedback that doesn't fit anywhere has a home instead of landing on the wrong feature.

Phaseless is also the supported way to retire a feature from active testing. Move it out of its phase and testers stop being asked to test it while keeping the ability to report against it.

### Check the plan before your testers arrive

Four checks catch nearly everything, and all four are faster than fixing the same problem after 200 people have hit it:

- **Read the timeline end to end.** Phases in the right order, no gaps between them, and an end date on the last one that matches what you told your stakeholders.
- **Count the features in each engagement phase** against the two to three hours per week rule. Phases that are too full don't produce less feedback evenly. They produce a lot of feedback on the first two features and nothing on the rest.
- **Check feature access against your teams.** A feature nobody has access to is invisible and produces no error.
- **Confirm each feature collects something.** Star rating, survey, or feedback. A feature set to None with no star rating and no feedback collection records only that someone clicked "done."

Once testing is underway, the phase and feature dashboards are where you watch it land. See [**Centercode Dashboards overview**](https://help.centercode.com/en/centercode-dashboards-overview?hsLang=en) and [**Project overview dashboard overview**](https://help.centercode.com/en/project-overview-overview?hsLang=en).

### When the schedule changes

Test plans don't survive contact with real testers, and most of what you'll need is already built in.

##### A phase ended too early

Reopen it. Hover the phase on the *Test plan* page, click through to its details, and set a new end date. Every prior submission stays in place, and the phase's surveys and activities become available again, so check they're still relevant before you do it. Full detail in [**Guide to Reopening or Editing Past Phases**](https://help.centercode.com/en/guide-to-reopening-editing-past-phases?hsLang=en).

##### One feature needs more time, but the phase doesn't

Move the feature instead of extending everything. Hover the feature and click **Move**, then choose the phase it should go to. Two options come with it:

- **Continue testing**: brings the feature across with all its data intact. Testers who already completed it aren't asked again. Use this when participation was thin and you want more of the same data.
- **Retest**: brings the feature across and resets it, so everyone is asked to test it again. Use this after a fix.

##### The dates on a past phase are wrong

Deactivated phases keep the same date controls as active and pending ones, and editing those dates doesn't reactivate the phase. This is how you make the historical record match what actually happened.

### Faster ways to build a plan

Two options on the *Test plan* page skip the one-at-a-time build entirely.

##### Generate a test plan with AI

Click **Generate test plan with AI** to have Ted build a structured set of phases and features from your project details, your uploaded product documents, and any custom instructions you give it. You get a complete draft plan you can edit, which is a much better starting point than a blank page. See [**AI Test Plan Overview**](https://help.centercode.com/en/creating-a-test-plan-using-ai?hsLang=en).

##### Import a test plan from a file

Click **Import test plan via file**, then **Download the template**, fill it in, and upload it. The import creates features, phases, and teams in one pass, which is the right approach when your plan already exists in a spreadsheet, or when you're rebuilding a plan you've run before.

Three things to know before you do:

- **Don't alter the template.** Adding, removing, or rearranging columns causes import errors. Resizing rows and columns is fine.
- **Decide how phases get made.** The *Override phase schedule in test plan file* checkbox lets you set a phase length of weekly, bi-weekly, or monthly and a start date, and builds the schedule for you.
- **Know the fallback.** If you don't check that box and your file has no phase information, everything lands in a single one-month phase named *Imported Phase*, starting the next day. That's recoverable, but it's a surprise if you were expecting your own schedule.

Full detail in [**Import a test plan overview**](https://help.centercode.com/en/test-plan-import-overview?hsLang=en).

Test plans can't be exported, so the import sheet you build is worth keeping. It's the closest thing you have to a reusable copy of a plan.

### Best practices for test plans

- **Name features for the product, not the phase**: "Camera, low light" survives being moved, retested, and compared across phases. "Week 2 task 3" stops making sense the moment anything changes.
- **Size phases by tester time, not by coverage ambition**: two to three hours per week is the working number. An overfull phase produces less data than a right-sized one, not more.
- **Use an onboarding phase even when you think you don't need one**: it's where you discover the units that never arrived and the installs that failed, while there's still time to fix them.
- **Collect a star rating on everything you can**: satisfaction scores are what make phases and features comparable to each other. They cost the tester one click and they're the backbone of your dashboards.
- **Set feature values as a group, not one at a time**: start everything at Neutral, then rank. Values set in isolation drift, and they're multiplying every piece of feedback you receive.
- **Walk your own activities before the phase opens**: with the instructions as written and nothing else. Most unclear activities are obvious within thirty seconds of trying to follow them.

### Notes

- Phase names are internal. Testers never see them, so name them for your team.
- Phases can't have overlapping dates. If a date is rejected without an obvious reason, check the phase before and after it.
- Phase schedules follow the timezone set on the project's *Project settings* page.
- A custom survey can be attached to only one feature. Clone it if you need the same questions elsewhere.
- A regression feature's custom survey returns testers to their existing response to update it, rather than collecting a fresh one. Clone the survey each phase if you need separate captures.
- New user features can't be reset, and testers already marked complete won't be prompted by ones you add later.
- There's no supported way to reset one tester's completed activity.
- Test plans can't be exported from Centercode. Keep your import sheet.
- Testers can't submit feedback during an onboarding phase. They can during engagement and closure.
- Confirming that testers received their hardware before the test starts? See [**What is Product Verification and how is it used?**](https://help.centercode.com/en/product-verification-overview?hsLang=en)
- Activities are not notices. Notices are what a user must pass through to enter the project, such as agreements and profiles. Activities are the work inside it. See [**Centercode Basics: Notices**](https://help.centercode.com/en/notices-overview?hsLang=en).
- Looking for the reference version of any single piece here? See [**Test Plan Management Overview**](https://help.centercode.com/en/test-planning-overview?hsLang=en), [**Phases Overview**](https://help.centercode.com/en/creating-phases-overview?hsLang=en), [**Features Overview**](https://help.centercode.com/en/features-overview?hsLang=en), and the [**Test Planning FAQ**](https://help.centercode.com/en/test-plan-faq?hsLang=en).

- [Centercode Basics](https://help.centercode.com/en/centercode-basics?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/centercode-basics?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/centercode-basics?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/centercode-basics?hsLang=en#faqs)
- [Community Administration](https://help.centercode.com/en/community-administration?hsLang=en#main-content)

    - [Community Administration](https://help.centercode.com/en/community-administration?hsLang=en#community-administration)
    - [Overviews](https://help.centercode.com/en/community-administration?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/community-administration?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/community-administration?hsLang=en#faqs)
- [Project Administration](https://help.centercode.com/en/project-administration?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/project-administration?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/project-administration?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/project-administration?hsLang=en#faqs)
- [Features & Test Planning](https://help.centercode.com/en/features-test-planning?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/features-test-planning?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/features-test-planning?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/features-test-planning?hsLang=en#faqs)
- [Resources & Surveys](https://help.centercode.com/en/resources-surveys?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/resources-surveys?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/resources-surveys?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/resources-surveys?hsLang=en#faqs)
- [Recruiting](https://help.centercode.com/en/recruiting?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/recruiting?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/recruiting?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/recruiting?hsLang=en#faqs)
- [Feedback](https://help.centercode.com/en/feedback?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/feedback?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/feedback?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/feedback?hsLang=en#faqs)
- [Dashboards & Reporting](https://help.centercode.com/en/dashboards-reporting?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/dashboards-reporting?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/dashboards-reporting?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/dashboards-reporting?hsLang=en#faqs)
- [Integrations](https://help.centercode.com/en/integrations?hsLang=en#main-content)

    - [Overviews](https://help.centercode.com/en/integrations?hsLang=en#overviews)
    - [Guides](https://help.centercode.com/en/integrations?hsLang=en#guides)
    - [FAQs](https://help.centercode.com/en/integrations?hsLang=en#faqs)

- [What's New?](https://whatsnew.centercode.com/)
- [System Status](https://status.centercode.com/)
- [Starter & Delta Edition Help Center](https://learn.centercode.com/)
- [Report an Issue](https://centercode.com/issue)

[![Centercode logo](https://help.centercode.com/hubfs/images/logos/Centercode-Logo.svg "Centercode logo")](https://centercode.com)

Copyright © 2025, Centercode