FujiForty - Test Management

Whether end users or QA engineers believe it or not, all developers perform tests on their code. Sometimes it might not be as accurate or detailed as it should be, and sometimes it's not even documented. A developer knows the use cases they are coding for and can be sure to test for those cases. Handing an app over to QA may not always include a list of the tests performed or the expected results. This somehow needs to be captured by the product manager and/or the developer depending on the organization structure.

The new Test Management application in Fuji may help improve this process. Like most developers, I occasionally struggle with documenting what I need to and have tested. I tend to fall back on reviewing the collection of classes and methods and memory of what I've validated. So I decided to checkout Test Management. The biggest challenge with any process application is making it quick and easy enough as to not frustrate the user or impede effective production. 

At the root of the test management application is a collection of hierarchical test components:

  • Test Suites - collection of test cases. For me, I initially felt that an application would have a one to one relationship with a test suite.
  • Test Cases - a component of a suite that contains a number of tests. Following the suite=application model, a test case could be the collection of use cases for a given persona (i.e. end user tests). For more complex applications this might be too generic of a model.
  • Tests - a component of a test case. This is the actual smallest unit of test that needs to be performed (end user creates a new record with default values)
  • Test Environments - the destination (url) of where the tests should be performed

Once the suites, cases, and tests are defined we need to actually perform and track the results of the tests. This is done through test plans. Test cases can be linked to one or more test plans. When a case is added to a plan, a copy (instance) of the case and all of it's tests are added to the plan. These are the working items that will capture the results and the status (unexecuted, in progress, pass, fail, blocked) of the test.

I'm still in the process of deciding whether this is quick an efficient enough for me to use in my development lifecycle, but I would definitely encourage anyone planning on getting applications certified and published to the store to check it out. You could even export your suites and make them available to your customers so they can use the same tests as they perform their own customizations.