Skip to main content

DIY Testing Portal

Introduction

A simple portal for tracking testing reports, bugs found and then mapping all this way back to features and releases. However JIRA and other such project management tools provide the features that are mentioned in this document but still this solution can come in handy for those who don't want an outside tool rather a quick dirty solution.
Note this is for a general solution overview and focuses more on data modelling. Any installation and setup related findings is homework for reader :)

What all is compassed in testing ?

  1. Testing Report
  2. Bugs
  3. Releases
  4. Features
  5. Test cases
  6. Environment

What all do you need to see in a testing dashboard ?

  1. Timeline of all testing that has happened till date
  2. Individual testing report
  3. Test cases, which cases map to which feature(s)
  4. Testing cycles for a specific release
  5. Bugs introduced in a release, mapped to which feature(s)

The portal solution involves :

  1. Mongodb
  2. Mongodb Compass - mongodb dashboard tool
  3. Elasticsearch
  4. Kibana - elastic search dashboard tool

How will it work

Managing Testing Metadata in Mongodb

We use mongodb as database/storage for all the testing related metadata we have i.e. bugs, test cases, release versions, testing cycles. Exact modelling of data will come in later section. To manage mongodb as well as to have an interface to enter metadata/information in mongodb, we can use Mongodb Compass (a solution by mongodb itself).

Making sense of data

Kibana has excellent dashboard functionality, it provides various chart types for every possible reporting type that one may need. So to facilitate Kibana we integrate ElasticSearch with Mongodb. Check out this post https://www.linkedin.com/pulse/5-way-sync-data-from-mongodb-es-kai-hao for integration. For me I used the river option (option 3) in the linked post, but as you may see that is now deprecated for 2.0x version. Once this integration is done, you can create custom dashboard in Kibana based on the data you have and voila!

Data Modelling

Here I am hoping you have some basic knowledge of Mongodb or atleast understand how JSON works.

Testing Report

A testing report is basically number of testcases that passed and failed on a particular release deployed on a specific environment. This can be modelled as :
{
 "id": "<uuid>",
 "environment": "<string>",
 "release": "<releaseId>",
 "bugs": ["<bugId>", "<bugId>", "<bugId>", "<bugId>", "<bugId>"],
 "result": {
  "passed": ["<testCaseId>", "<testCaseId>", "<testCaseId>", "<testCaseId>"],
  "failed": ["<testCaseId>", "<testCaseId>", "<testCaseId>", "<testCaseId>"]
 },
 "timestamp": "<date>"
}

Test Case

Test case is just the description of the scenario that will be tested, expected outcome and feature to which it maps.
{
 "id": "<uuid>",
 "description": "<string>",
 "expected": "<string>",
 "features": ["<featureId>", "<featureId>", "<featureId>"],
 "timestamp": "<date>"
}

Release

Release is basically the latest stable working tag of software which has some new features and follows an increment style i.e. build upon last release.
{
 "id": "<uuid>",
 "tagVersion": "<string>",
 "incrementedOn": "<releaseId>",
 "features": [{
  "id": "<uuid>",
  "description": "<string>"
 }, {
  "id": "<uuid>",
  "description": "<string>"
 }, {
  "id": "<uuid>",
  "description": "<string>"
 }],
 "timestamp": "<date>"
}

Bug

Bug is an anamoly found in functionality of software during testing cycle. It maps to a feature and may or may not present in multiple releases.
{
 "id": "<uuid>",
 "introducedIn":"<releaseId>",
 "presentIn": ["<releaseId>", "<releaseId>", "<releaseId>"],
 "features": ["<featureId>", "<featureId>", "<featureId>"],
 "timestamp": "<date>"
}

Conclusion

With the above explained data models and tools one can have a minimal testing portal up and running in just a day, all is left to prepare the metadata and feed it to mongodb.

Comments

Popular posts from this blog

Guide : Spring Boot with Apache CXF for REST services

In this series of guide, we are going to explore writing REST services with Apache CXF using Spring Boot. The project is build using maven. I assume that you already know how to use maven. Step 1 : Adding dependencies for Spring Boot By default you have to inherit the parent pom of spring boot, but that cannot be followed everytime, so I use an alternative to that. I basically add spring boot pom as dependency so that it brings all the dependencies. <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> <spring.version>1.4.3.RELEASE</spring.version> <cxf.version>3.1.10</cxf.version> </properties> <dependencies> <dependency> <!-- Alternative to inheriting from parent spring pom --> <groupId>org.springframework.boot</groupI…

Enabling CXF goodies in Spring Boot

In this post we are going to add some of the CXF features to our existing app that we developed in previous post. These features are : ID LoggingJackson Provider for POJO to JSON conversionSwagger 2 documentationStep 1: Configuration class Create a RestServer class in config package as shown below
package org.blog.config;importcom.fasterxml.jackson.jaxrs.json.JacksonJsonProvider;importorg.apache.cxf.feature.LoggingFeature;importorg.apache.cxf.jaxrs.swagger.Swagger2Feature;importorg.springframework.context.annotation.Bean;importorg.springframework.context.annotation.Configuration;/** * Created by Anand_Rajneesh on 3/23/2017. */@ConfigurationpublicclassRestServer{@Beanpublic JacksonJsonProvider jsonProvider(){returnnewJacksonJsonProvider();}@Beanpublic LoggingFeature loggingFeature(){returnnewLoggingFeature();}@Beanpublic Swagger2Feature swagger(){ Swagger2Feature swagger =new Swagger2Feature(); swagger.setBasePath("/services"); swagger.setContact("…

Power of declarative syntax of Lambda

Since Java has introduced lambda, writing code has become a breeze especially when it comes to expressing what you want to computer to do rather than how to do it. The following is a question from Project Euler and is solved using lambdas in Java8.

Let d(n) be defined as the sum of proper divisors of n (numbers less than n which divide evenly into n). If d(a) = b and d(b) = a, where ab, then a and b are an amicable pair and each of a and b are called amicable numbers. For example, the proper divisors of 220 are 1, 2, 4, 5, 10, 11, 20, 22, 44, 55 and 110; therefore d(220) = 284. The proper divisors of 284 are 1, 2, 4, 71 and 142; so d(284) = 220. Evaluate the sum of all the amicable numbers under 10000.  A simple brute force solution is to check every number from 2 to 10000 and if its  an amicable number then add it to sum. Listing it in steps you are basically doing 3 things: Take numbers from 2 to 10000If number is amicableAdd it In Java 7 one will basically start a for loop, mak…