Testing guide

[elielytz]

Manual Testing guide

This guide is a quick start for Non-developing team members who are supposed to conduct successfully manual testing for the platform.

Mission

• Work with developers
• Test new features
• Test features before reaching master branch
• Test release candidate

Tips for succeeding in the mission

• Communication
  Effective remote working requires active communication, you will be connected to the slack group where you can ask for help or clarification to get your job done. Be flexible to ask questions there and contribute as much as you need to do so. Also, we have a culture to conduct small meetings at least once per week for you in your squad. For the case of meetings, it will be communicated further in terms of schedule.

• Timing
  Developers are working according to the sprint plan and changes are updated regularly in the sprint board you need to check regularly on changes and test the issue if it requires testing. If you are not clear on how to test, ask by commenting on the issue.

How to get the job done

01) Overview

Comment observations in GitHub issues that you are working on. If the issue is new/needs special attention creates a new issue for it. If that issue happens that it had been reported earlier, you will be notified by the developers. You will get to understand the working environments which are;

• Production environment: This is where the last release with no release-blocking features is live
• Staging environment: This is a sandbox environment before production goes live.
• Local environment: This is configured in your machine (update codes from the master branch and individual branches for effective testing of a certain function)

Here is your smooth journey to identify issues and get started with testing;

• Seek to understand the working culture and expectations.
• Go through Parabol website home page & blog to have a clear understanding of features.
• Run Demo and understand why Parabol.
• Test Parabol in a production environment using release test guide this will help you to identify easily blocking & non-blocking features for the release candidate in the future.

02) Testing new features & updated features before reaching the master branch.

This can be best tested in your local environment.

There is a periodic sprint plan for updating and creating new features, all these can be found in the sprint board you need to check regularly on changes. There is different sections in sprint board but the following sections should be tested in the following order starting with issues in;

1. Maintainer Review
2. Reviewer Review
3. Self-review: ask the developer if the issue is ready for testing

TIP: Trace the respective branch where the changes on the issue are pushed by the developer. Pull it, test and comment if expected behavior is there.

03) Testing release candidate

The main reason for the release test is to identify features that can block the release. This is release test guide.

Release Blocking features/issues: are unexpected behaviors in the current release that are not in the production environment.\

Release Non-Blocking features/issues: these are unexpected behaviors in the current release and the production environment.

Good Testing practice

Suggestion to the product team for speeding up testing cycles