Summer Calendar 2022 on Cherry-IT.pl

Day 1

I decided to take a one-month educational testing challenge provided by Anna Pieciulko-Czyrko from http://cherry-it.pl/ blog. The calendar is entitled “Na tropie błędów” [Hunting for defects] and, as the author promises, every day will bring new tasks to do.

Day 2

The first task is to find an error on your favourite website. I track my daily sport activities with Strava app and use Strava Annual Summary (http://www.jonathanokeeffe.com/strava/annualSummary.php) to compare my current statistics with the previous years. Typically, the Summary works well, but recently it has stopped working. After entering my Strava ID and clicking the “Load Activities” button, all my activities are loaded one by one, but the erroneous page is displayed at the end:

The “null” link goes to my Strava account, but no data are gathered.

Day 3

Today I’ve learnt about the defect definitions and life cycle. After the Testing School, it is simply a revision of the material I am familiar with, but every repetition is useful.

Day 4

The next day of theory. This time it is a bug report and its components – a pretty useful topic.

Day 5

My task is to rewrite the error from day 2 into the format indicated on day 4.

ID: 1
Title: Unable to load data on Strava Annual Summary
Description:
Testing steps:
Open page http://www.jonathanokeeffe.com/strava/annualSummary.php
Enter your Strava athlete ID into “Athlete ID” field.
Press “Load Activities”.
Wait till all activities are processed.
Check the resulting page.

Actual result: pages without any statistics; “null” in the title
Expected result:
pages with statistics and charts;
athlete ID or name in the title


Browser: Opera 89.0.4447.83
Testing environment: Windows 10 Pro (10.0.19044)
Tested product version: 2.51
Screenshot:

Day 6

For comparison, the author published a report of the bug that she spotted.

Day 7

A note about test environments. I wonder if I should check for Strava API version and include it in the test?

Day 8

Today we’ve gone through a list of 18 most popular tracking software options according to http://www.softwaretestinghelp.com/popular-bug-tracking-software/

Day 9

Let’s introduce JIRA. At last! Now, the real work will start. At the very beginning, I watched an interesting webinar “JIRA bez tajemnic” [JIRA without secrets] including all the basic concepts of the software and ways to create an exemplary bug report. Although it wasn’t mentioned in the blog, I also found the 2^nd part of the webinar and extended my JIRA basics to include workflow creation.

Day 10

High time to practise! The today’s task is to sign up for a free account in JIRA and to enter the above defect into the software, based on the yesterday’s webinar. In fact, I created my JIRA account a few weeks ago, but I had no time to start working in the software. First, I reconfigured the workflow to block some possibilities to change the statuses. The idea comes from Anna Pieciulko-Czyrko. Additionally, it is a good JIRA exercise. This is how my workflow looks at the moment:

After that, I reported my first bug in JIRA:

It looks nice and the software is quite intuitive, although I think I’ll spend some time in it to become familiar with all the needed functions.

Day 11

The day was for questions only. As I have some doubts about testing environment, I availed myself of the opportunity and asked the author for explanation.

Days 12-14

The next tool is on the table – this time it is Bugzilla – one of 5 most commonly used bug trackers. As part of the today’s task, I had to download and configure the software. At first glance, it seemed to be a simple installation task, but it appeared to be quite complicated, especially for Windows users who install everything from the ready exe files. Fortunately, there is an installation guide (https://bugzilla.readthedocs.io/en/latest/installing/windows.html). At first, I downloaded Strawberry Perl and installed it. Next I had to install a whole bunch of perl modules. Additionally, the Bugzilla documentation contains names with hyphens that (as I’ve found) have to be replaced with double colons to work with cpanm installer used by Strawberry Perl. Next – the Apache Web Server with full configuration (hard work for me at the moment). By the way, I’ve spotted a mistake in the documentation, so I’ve entered my first bug into the https://bugzilla.mozilla.org:

Now the database server. I chose MySQL as I worked in the tool 15 years ago (I created websites using PHP + MySQL). The database installation took me more than two days, and every attempt ended with endless errors. The problem is Bugzilla doesn’t work with the most current version of MySQL, therefore I gave up and installed the last 5.x version of the database system.

And after three days of searching, installing, solving problems etc., the Bugzilla server didn’t start at all due to some configuration problems.

I understand that Bugzilla is universal software which is designed to be used on different platforms, but it seems that Bugzilla is full of bugs itself. During my searches in the Bugzilla databases, I found many bugs that were reported a few years ago and still bother users. Therefore, I gave up the attempt, as my main goal is to learn testing, not solving software problems.

I think I’ll return to Bugzilla when I have time to install Linux, which I plan in the near future.

The next day was devoted to reporting a bug in Bugzilla. Actually, I’ve done it by reporting the documentation error presented above, so I think the main goal is accomplished.

The 14^th day was for taking a rest. For me it was the last day of my lost battle against Bugzilla.

Days 15-16

The days are devoted to Mantis Bug Tracker that I already know quite well thanks to Norbert Jankowski and his Tester School that I attended recently. Using Mantis was part of the training and I reported several bugs connected with different aspects of the training and with Norbert’s website.

Days 17-19

Three days of thinking about analyses in tests. The author encourages to analyse whether the spotted issue is a defect, and whether it is a duplicate of the existing bug. For me it is a quick review of some topics that I am already familiar with.

Days 20-22

The pace, initially quite fast, slowed down. The author proposed two days of revision and a break (that I used to learn something else). The 22^nd day introduced priorities from blocker to trivial that I already know (and I already used them reporting my first bugs) thanks to Norbert Jankowski and his Tester School.

And that is all. The initiative, planned for the whole month, lasted for three weeks. Nevertheless, I’m deeply grateful for the opportunity to practise, repeat the basics and familiarize myself with other tools. Definitely, I’ll be a frequent visitor of Cherry.it.