About the Quality Assurance

This document is about the testing process of Teamboard reference product. Document contains descriptions of used tools, testing strategies and used methods. Testing is done continuously while developing the product.

Methods

Performance testing is executed on Teamboard's website in model-based fashion. Objectives of these tests are to verify the performance and functionality of the product before delivering it to end users.

In general Model-based testing works in a way that System Under Test (SUT) has an abstract model that represents its wanted behaviour. Test Cases are generated from the states of the model. For example login, register, workspace and board views. Basically every possible path between the states is generated as a new Test Case and tested independently. This results to a complex map of possible combinations and plenty of Test Cases. Some software also allow the use of weights which can be used to simulate the user behaviour. For example some users could add more tickets while others would be more interested in removing and moving them.

Model-based testing is kind of like black box testing since the Test Cases are derived from the model instead of source code.

Tools

Ixonos Visual Test
We have received a license for the Visual Test tool through collaboration with Ixonos.

IVT can be used to create page models from the views of Teamboard. Different views are for example Login screen, Workspace view and Add Board pop up window. First the page is appended and then the tool is used to automatically find the elements of the page. Elements can be inserted manually later on if something is missing or added afterwards. After page is created, methods are created scripted with Python which can be done by clicking the element and choosing desired action. For example click button or verify text.

You can make test cases manually, but we use the Model Graph feature to make them in model-based fashion. Page models work as states that are navigated through transitions. In transition there are two mandatory selections and one optional. First input and output methods are inserted and if the transition requires, you can add up to five precondition methods. Input is the method done in the current state and output is what happens in the new state, for example verify that we're in right view.

login screen picture

IVT also allows you to create references, which basically are transitions to some other state that isn't directly connected as next. Input and Output methods are also required make the reference.

reference picture

After all transitions have been defined, Model Graph can generate the tests automatically. Every path between transitions and references will be tested as separate test case.

There is a way to collect test data either automatically from the pages or insert it manually for later use in methods. Test data is saved in XML format.

fMBT
TBD