Test Policy

Mission of Testing

Bosphorus Industrial Software Solutions (BISS) strongly believes that testing saves cost and time, while providing efficiency and quality to all software products. The main idea is to deliver the product in such a quality that the users will have the intended experience.

Definition of Testing

BISS defines Testing as validation and quality improvement of the product from ideation phase to the final delivery within all angles. Testing is an ongoing process together with other processes in SDLC.

Testing Approach

The testing approach is determined according to the project requirements, customer expectations, team knowledge, and project duration. More than one approach might be combined to perform tests in the project.

Test Process

Our process follows the IEEE and ISTQB standards.

This process applies as a general rule for all the projects at BISS. To see the equivalent steps in the STLC or SDLC of each activity please refer to the Test Strategy Document.

1. Requirement Testing

  • Testing requirements, user stories, or analysis documents to see if they are ready for the development phase.
  • Identifying types of testing to be performed. Please check Table 1 for further information.
  • Preparation of the “requirements traceability matrix” (if possible).

2. Test Planning

  • Preparation of test plan and other test documentation.
  • Definition of entry and exit criteria.
  • Selection of test tools.
  • Estimation of the effort (include training time if needed).
  • Determination of roles and responsibilities.

3. Test Case & Test Data Development

  • Creating test cases (automated or/and manual test cases).
  • Creating or requesting test data.

4. Test Environment Setup

This process can be started along with phase 3.

  • Setting up the test environment, users, and data.

5. Test Execution

  • Executing tests.
  • Reporting bugs and errors.
  • Analysing the root cause if possible.

6. Test Closure

Preparation of the test closure document which includes;

  • Time spent.
  • Bug and/or error percentage.
  • Percentage of tests passed.
  • The total numbers of tests.

In each step, there are entry and exit criteria that need to be met. These criteria usually vary from project to project but the common entry and exit criteria can be found in the Test Strategy Document.

7. Test Levels and Test Types

Test Level Owner Test Types Objective(s)
Unit(Component)
  • Developer,
  • Software Tester
  • Functional Testing,
  • White-box testing,
  • Change-related testing:
    • Re-testing,
    • Regression testing
  • Detect defective code in units,
  • Reduce risk of unit failure in production
Integration
  • Developer,
  • Software Tester
  • Functional Testing,
  • White-box testing,
  • Grey-box testing,
  • Change-related testing:
    • Re-testing,
    • Regression testing
  • Defect defects in unit interfaces,
  • Reduce risk of dataflow and workflow failures in production
System Software Tester
  • Functional Testing,
  • White-box testing,
  • Grey-box testing,
  • Black-box testing,
  • Change-related testing:
    • Re-testing,
    • Regression testing
  • Non-functional testing:
    • Performance,
    • Load,
    • Stress,
    • Accessibility
  • Detect defects in use cases,
  • Reduce risk of the system behavior in a particular environment
Acceptance
  • Software Tester,
  • Product Owner,
  • Customer
  • Functional Testing,
  • Black-box testing,
  • Alpha testing,
  • Non-functional testing:
    • Performance,
    • Load,
    • Stress,
    • Accessibility
To be sure the software is able to do required tasks in the real world.