BluePrint: Quality Assurance

Introduction

This blueprint outlines the development of the automatic testing framework. This automatic testing framework will provide robust testing of the code-base and ensure proper maintenance of the code.

Whenever some changes are added in the current code, it has to be validated and tested upon with the integration with the other components of the code. So, this framework will provide this support.

With tests running on a scheduler, continuous testing can be done. This is important to Sahana, seeing the rapid movement of the code-base. Currently, Sahana has automatic test framework, whose details can be found here

Stakeholders

• Developers - With an automatic testing framework setup, it will be relatively easier for the developers to test their changes in the code.

• People who want to deploy Sahana - They would like to run the tests to ensure that the system is integrated well and ready for deployment.

• Sahana as a service - Automated testing will provide Quality Assurance to it’s clients.

• Bug Marshalls

User Stories

• Developers will run the test suite on making changes to the code to test if it works with the integration of the system. Developers may also see the test results mailed to the list to see the possible bugs introduced into the system.

• People who want to deploy will run the test suite to check the functionality of the system.

• The “bug marshalls” will review the test results mailed periodically by the CI Server and fix the bugs or log them.

Requirements

<Group requirements in subsections, e.g. _{etc.> <​http://en.wikipedia.org/wiki/Requirements_analysis requirements> <Identify different types of requirements:>}

Functional

• Maintain the CI Server to run the tests periodically and send the results.

• Automatically Create Dummy Data while testing.

• Extend Role Tests (Currently is limited to the IFRC roles for RMS)

• Run Selenium and Smoke tests in multiple templates with multiple user accounts. Ideally, these tests can be run against each and every template where the target functionality is available. For templates where the functionality is not available, the test should auto-deactivate.

• Clearer Error Messages in a way that anyone can reproduce them.

• The CI Server should catch failures in any template. So, it should run tests across templates and include the template name in the aggregated report.

• Simplify Selenium Tests and make them easier to read and more robust.

• Adapt tests to meet needs of evolving CI Server(SysAdmin/ContinuousIntegration)

• Load Tests

Non-functional

​http://en.wikipedia.org/wiki/Non-functional_requirements

Interoperability

Standards

System Constraints

Use-Cases

Design

<Where relevant include alternative design options>

Workflows

• The CI Server runs the tests periodically and sends the results. On a regular basis, the bug marshalls review the test results and see if the reported negatives are false negatives or true negatives. If they are false negatives, they fix the tests. If they are true negatives, they report the bug on the trac or fix the bug themselves.

• The developers make changes to the code and run the tests. If their changes do not break the tests, then this code is viable for merging.

• The clients run the tests to make sure that the functionality this software is intended to provide is fulfilled.

Technologies

• For setting up the CI Server, some of the technologies which can be used are given here - ContinuousIntegration

• For Continuous Integration, an instance of Eden can also be used which will enable Scheduling, enable subscription of notifications for test results, can also provide formatted results.

• For functional tests, currently, Selenium and Smoke Tests are used. The current Selenium tests should be made more robust and they should work across browsers. Currently, there is support for Firefox Webdriver(upto version 16) and Chrome Webdriver. We need to provide support for Safari Webdriver, Opera Webdriver and Internet Explorer Webdriver.

• The Role tests(which currently run only on the IFRC template and uses Selenium Unit Test) are to extend to run on multiple templates.

Implementation

The seleium tests can be run on mainly IFRC template. WIth some changes, they can be run on the default template as well. However, they don’t work across templates.

The unit tests expect that some particular modules are enabled in the template. If they are not enabled and unit tests are run in that template, then false negatives are reported.

Current implementation of the selenium tests, smoke tests, role tests can be found here -

​https://github.com/flavour/eden/tree/master/modules/tests

Unit tests and benchmark tests can be found here -

​https://github.com/flavour/eden/tree/master/modules/unit_tests

References

BluePrintTesting

QA

DeveloperGuidelinesTesting

SysAdmin/ContinuousIntegration

BluePrint