Scrum testing heuristic: Is feature usable?

Reading Time: 1 minute

TL;DR

This post will describe how I test in project that uses scrum. Tool is Jira and context is early development phase.

We have in JIRA workflow QA phase.

Frontend has code reviews and developers are able to test (there is no automation) what they code using browser.

Here is how I test in described context.

Feature is usable when user can do main flow described in jira card, for example, create business object.

I use browser and Chrome developer tools. Cards have some story description, so I ask for clarification in card comment section. Also, I observe pull request (angular framework) to see which modules changed. I am looking for feature side effects,  when pull request contains changes not directly related to the card.

I approve card when feature is usable. Remember that context is early development phase, and scrum is iterative process, so there is no point to stop the feature if it is usable. For found issues or missing features, I create new card and bug or task, and I connect those two cards.

In BBST foundations lecture 2, you can learn how your testing differs depending on your context.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Web page cache heuristic that failed

Reading Time: 1 minute

TL;DR

In this post I will describe my heuristic for web page cache testing that failed and why it failed.

Web page cache is mechanism that stores parts of web page that does not change a lot in browser local storage. Hard part is to figure which part of page is not changing very often. A lot of scientific effort have been put in this problem.

I got a Jira card that clearly stated a story with cache usage.

During the creation of business object, cache all referenced data so when user will edit that object, all referenced data is already available.

I did exploratory test around this story, using my brain, eyes, ears and fingers. There were two paths to feature create business object. First path worked as described in user story, but second path did not. When I opened the create business object feature, all data had already been cached.

My first heuristic was that this is an issue. But after I explored the pull request connected with this card and discovered that all code changes were in one place I realized that my cache heuristic failed. Developers are using framework that helps them to write DRY code.

As create business feature component was reusable, first path to that feature already filled cache with data.

If you are in doubt how to enhance your testing craft, BBST is excellent starting point.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned on Testival #27 meetup

Reading Time: 1 minute

TL;DR

This post is report about what I learned at Testival #27 meetup and how I provoked that learning.

Last week we had Testival #27 meetup. Attendant metric was 15/25, which is excellent 0.6! You probably have seen something like this metric in your test reports. 0.6? So what that number means? We recently moved to meetup platform which exposed Testival to local community. 15 testers showed, and 25 applied to meetup. We have total of 65 members in Testival group. This is great improvement for Testival.

Sponsor of this meetup was Repsly, and we met again in HUB385. Repsly is hiring for a QA position. After short introduction of all participants,  we started with lectures and lighting talks.

My takeaways.

  1. Ana showed hers PageObject implementation in javascript. Ruby has PageObject gem with lot of out of the box helpers that you need to develop by yourself in javascript.
  2. Zeljko showed javascript source code for browser automation in various framework. It is less readable than Ruby code and it seems that Ruby gem ecosystem is stronger than one in javascript.
  3. Between two sessions I heard interesting question, how to check large tables using selenium (I always mingle in listening mode in every meetup), and Zeljko mentioned that he successfully used dedicated htl parser for that purpose, not the Watir-webdriver implementation.
  4. I was very impressed how Scratch evolved in past few years.
  5. There is jenkins plugin that enables you to keep history and version of your application builds.
  6. Over beers I learned on real example how is very hard to manage team of programmers. There is no silver bullet, managing a group of programmers is very hard.

Ruby : Javascript in browser automation context 3:0.

Here is small gallery:

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

How to change docker default route on Centos7

Reading Time: 2 minutes

TL;DR

In this post I will explain how to resolve following issue. You are connected via ssh to your centOS box. You successfully installed docker on that box and you started docker daemon using systemctl. Bang!, you are disconnected from your centOS box.

This happened to me. I had successfully installed docker on several boxes without a problem. Reality check, I just scratched the surface of my docker knowledge.

Reality check. This centos box was different than previous ones. I found out that it is in different network. Luckily, there was another box in same network that I can connect to. I ssh to that box and then from that box to the original centOS box. I  am in!

I was able to log in because they were in same network subnet. My laptop was in different range. What to do in order not to be bitten by this issue?

Before you start docker daemon with systemctl, run following cmd:

[ ~]$ route -n

route shows/manipulates routing table. Routing table describe where IP packets should go. Picture above shows ok situation. docker and linux box have different destination for packets.

In above example, docker took 172.17.0.0 by default [source]. It reserves 65536 IP addresses for containers.

In my case, centOS box was in range 172.29., and docker took 172.29.1.0 so from outside, docker took all the traffic, and my laptop was automatically disconnected.

How to change docker cidr range.

Before you start your docker daemon:

  1. run route -n
  2. check your box eth0 destination
  3. edit docker systemctl start file:
vi /usr/lib/systemd/system/docker.service

4. put docker containers in different ip range

Here is example how to set docker ip range from 172.29.1.0 – 172.29.1.255 [cidr calculator]:

ExecStart=/usr/bin/dockerd -bip 172.29.1.1/24

5. Now is save to start docker daemon:

# systemctl daemon-reload
# systemctl start docker
#systemctl status docker
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather