Java, NoSQL, SQL, REST API and other scary words

Simple Visualized Algorythms

Linear Search

Bubble Sort

Bubble Sort

Merge Sort

Merge Sort

Quick Sort

Quick Sort

Max Heap Deletion

Max Heap Deletion

Search 1

Search 2

Advertisements
Standard
Java, NoSQL, SQL, REST API and other scary words, QA (eng)

Blue Green Deployment, Canary Run, A/B testing difference

I put the word “difference” to the header just for fun because all these things are different and could work together. Here are definitions:

  • Blue Green Deployment  is about how to deploy a new version of your software
  • Canary Run is about testing your software on a small amount of random participants who got no ideas that they are testers now
  • A/B Testing is about testing your ideas about how to improve  usability, popularity, noticeability, etc on a different focus groups.

Let’s start with the most complicated of these 3 items –

Blue Green Deployment Continue reading

Standard
BSA, Java, NoSQL, SQL, REST API and other scary words, Requirement management (rus)

Requirements from idea to implementation. BA and SA guide

I started my career in 2008 as a Business Analyst. Since then I worked as a Business Analyst, Systems Analyst, Product Owner, Test Automation and Software Engineer. I worked with custom development projects (for example I made Federal State Statistics Unit Warehouse and Portal) and I worked with products (Case Management System, Customer Relationship Management Systems, etc), so this course is an overview of technologies, practices and tips I used during my career.

I also got couple other Udemy courses, more then 15 articles and some on-site and online courses. This course build accordingly problems I saw during educational process and I really tried to highlight that (especially you will hear a lot of “concentrate on a problem first” tips).

So, to build this course, we had a group of 10 BA-SA volunteers and we started with usual problems BA-SA got, set a course structure you can hear in introduction and wrote something like a 600 pages book, which you will find at the end of the course as a downloadable PDF attachment. This is a base information for the theoretical part. We also researched templates, prepared a set of our favorites and you’ll be able to download these documents templates. Then we made a practice section based on example from one of my practical online course I made at the end of summer 2017 (you’ll get PDF practice examples as well, but they are not 100% done because we would like to show you a process of creating requirements).

Please note that we analyzed more then 900 web sites to combine all necessary theory for you (all these hyperlinks available at the second PDF file with theory).

Here is the link:

https://www.udemy.com/requirements-guide

Discount limited promo code is – AKDISCOUNT2018

PS.

I also would like to say special thanks to my colleagues, who really helped to control quality of all
materials, examples, etc:
● Evgenia Pavlova
● Olesia Volodina
● Maria Begouleva
● Julia Dorozhkina
● Anna Letunovsky
● Dmitry Ivannikov

And there were a bunch of people who were also involved in creating of all these materials:
● Daria Volkova
● Ekaterina Ilyashina
● Julia Vasilieva

And many thanks to Ekaterina Gert for the title image.

Standard
Java, NoSQL, SQL, REST API and other scary words, QA (eng)

Cucumber + ExtentReport

Prerequisites: Cucumber Again. From Requirements to Java Test

To create any simple Cucumber+Java test, we will need to create a glue file, that is pretty simple to do, because, if you don’t need all vhistles and blows on your first step – this will be enough:

package com.cucumber.StepDefinitions;

import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(
        features="src/test/resources/feature",
        glue = "com.cucumber.StepDefinitions"
)
public class CukesRunner {
}

My favorite report engine is ExtentReports, so, let’s add a proper class:

package com.framework.common;

import com.relevantcodes.extentreports.ExtentReports;
import com.relevantcodes.extentreports.ExtentTest;
import com.relevantcodes.extentreports.LogStatus;
import org.testng.annotations.AfterSuite;

public class ExtentReport {
    public static ExtentReports extentReports;
    protected static ExtentTest extentTest;

    public static ExtentReports getExtentReport() {
        if (extentReports == null){
            extentReports = new ExtentReports(System.getProperty("user.dir") +"/ExtentReport/index.html", true);
        }
        return extentReports;
    }

    public static ExtentTest getExtentTest(String testName) {
        if (extentReports == null) {
            getExtentReport();
        };
        if (extentTest == null){
            extentTest = extentReports.startTest(testName);
            extentTest.log(LogStatus.INFO, testName + " configureation started");
        }
        return extentTest;
    }

    @AfterSuite
    public void endSuite(){
        ExtentReport.getExtentReport().close();
    }
}

and implementation is extremely simple:

ExtentReport.getExtentTest(getClass().getSimpleName()).log(LogStatus.INFO, "Run test for " + className);

This is how it looks like:

After that I tried to research if there are any ready to go plugins or examples about how to make reports in Gherkin-like format. I easily found one, but that was working with no problems only with Eclipse. Here is an example – (https://automationissues.wordpress.com/2017/09/29/cucumber-extent-reporting/):

Continue reading

Standard
Java, NoSQL, SQL, REST API and other scary words, QA (eng)

Cucumber Again. From Requirements to Java Test

So, this is another one article abut cucumber, but I’ll try to describe SDLC methodology. If you skipped posts about correct Gherkin/Cucumber format , please have a look here: Cucumber — bridge or another one abyss between BA and QA

If you would like to try Java+Cucumber, please, have a look here: Create a Cucumber Project by Integrating maven-cucumber-selenium-eclipse

Feature File Naming Convention

But if you would like to get a overview on a process, please, continue reading. As every educated Analysts, as a result of our work, we got a list of requirements. We know that we could have functional and non-functional requirements.  This is my typical workflow to deliver requirement to QAs:

  1. Usually I’m starting my IT Projects with Vision document where I got User Stories as a key entity,
  2. I’m doing idealization via Use Cases.
  3. QA adding extra details for my Use Case steps. In general – they are adding steps to add data like “qweqweqwe” in date and number fields and all that kind of negative testing.

If we would like to test particular requirement, then you are:

  1. Searching for a User Story
  2. Searching for a related Use Cases (via matrix, if I already spent some time to create and maintain it)
  3. Searching for a Test Cases, related to this Use Cases
  4. Open Eclipse, configure TestNG xml file to run required test.
  5. Run selected tests

So, it would be great to find one particular Use Case and run it from the one place, without tons of Word document (+ xls tables as an option). The problem is – Cucumber  is not about User Stories, Use Cases, etc. Let’s answer couple important questions:

  1. What is the difference between Use Cases and Features? Features are descriptions of high-level product functionality. We then derive one or more use cases from each feature.
  2. What is the difference between Feature and User Story? A user story can be a specific justification for a feature, or a specific way to do it. Or it could be a totally different thing, like, for exampleUser story: as a customer, I want to pay with the most popular credits cards. While Feature: support the GOV-TAX-02 XML API of the government.

I would place User story and Feature at the same detail level, but the problem is: User Story is way  too long for the Cucumber Feature. Why? Because Cucumber Feature is a simple text file, while Feature Name is a name of this file! This looks nice on the different demo, where teachers got “MyFeature1” and “MyFeature2”, but in fact,  we should split feature files into groups via packaging, otherwise this will be a disaster.But anyway, we will not be able to put all these “As a User”, so, here is the key thing why they got features, because if we are using User Stories, we got space only for ” < some goal >” from “As a < type of user >, I want < some goal > so that < some reason >”.

There is also another one method we could use – add requirement number, this will extremely help us to support consistency and traceability. Continue reading

Standard