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

  1. It is truly a well-researched content and excellent wording. I got so engaged in this material that I couldn’t wait reading. I am impressed with your work and skill. Thanks. software development company Phoenix

    ReplyDelete

Post a Comment

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...

OOPs simply explained

What is OOPs ? It is Object Oriented Programming. It comprises of Polymorphism Encapsulation Inheritance Abstraction Already lost me ? Now here it is read about OOPs as if you deal with it every day. Let's take at OOPs from a Corporate world point of view. There is an organization which comprises of several employees which form a hierarchy. Now every employee has their way of working, some work hard, some like to delegate and some are smart. Though everyone does work in office, they do it in their own way. This is Polymorphism (implementing a function differently while keeping the semantics of function same). Employees are after all humans, we all have secrets. We have our own perspective which we may or may not share with everyone i.e. we have state and behavior only accessible to us. We share some of our secrets with our closest friends, some of our perspective to a group of people depending upon our status. In the end we do keep everything close and private, nothing ...

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 a ≠ b , 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 10000 If number is amicable Add it In Java 7...