How to Become a Software Tester

BTW

What does a developer do when the programming for the coming release (e.g. 1.0) is finished? He writes the code for the next release after coming release (2.0)! So, when testers find bugs during stage “Testing and bug fixes” developers have to interrupt their work on 2.0 and fix bugs for 1.0.

The important thing to understand here is that after the developer has done his work for the current Cycle, he moves to the “Coding” stage of the next Cycle.

BTW

Compilers and interpreters are special programs that translate code typed by humans (a=2+3) into the language understood by computers (0110000100111101001100100010101100110011). The difference between a compiler and an interpreter is that:

– a compiler produces an executable file but doesn’t execute our code. Thus, text files written in C++ must be compiled to become executable (launchable) programs.

– an interpreter doesn’t produce an executable file but immediately executes our code. Thus, text files written in Python are already executable.

Example

Let’s look at the example of a syntax bug in C++ program. C++ uses compiler.

Here is first program of any student learning C++ (line numbers are not part of software code):

1.#include <iostream.h>

2.

3.void main()

4.{

5.cout << "Hello, World! << endl;

6.}

This code is saved in the file hello_world.cpp. Let’s try to compile this program:

~> gcc hello_world.cpp

hello_world.cpp:5: unterminated string or character constant

hello_world.cpp:5: possible real start of unterminated constant

The last two lines are the compiler’s description of the bug in this code. What happened was that the compiler found a problem and exited after giving us information about the bug. The bug happened because we didn’t close with double quotes after World!. How would we describe this bug in one sentence? “hello_world.cpp: closing double quote is missing after World!”

If we fix the problem, our hello_world.cpp will compile just fine, and we will get an executable file that prints “Hello, World!” when we launch it.

Example

Let’s look at the example of a syntax bug in Python program. Python uses interpreter.

ShareLane -> Go to this URL: https://www.sharelane.com/cgi-bin/register_with_error.py (you can also launch this file from here: Test Portal>More Stuff>Python Errors>register_with_error.py). As you can see, there is a syntax error in this line of code:

body_html = get_firstpage(zip_code)

Programmer made mistake by giving wrong name of function:

Expected: get_first_page

Actual: get_firstpage

Here is a bug summary: “register_with_error.py: wrong name of the function get_first_page()“

Brain positioning

ShareLane -> The only difference between

– perfectly working file register.py (Test Portal>Application>Source Code>register.py) and

– not working at all file register_with_error.py (Test Portal>Application>Source Code>register_with_error.py)

is a single underscore character (“_”). So, even smallest modification to existing code can break the whole system. That’s why regression testing, i.e., re-testing of old functionalities, has immense importance.

Example

ShareLane -> Do steps below:

1. Create new user account on main.sharelane.com and login.

2. Add any book to the Shopping cart.

3. Set number of book inside Shopping cart to 30 and click button “Update”.

4. Check value in column “total”.

We have logical bug inside functionality “Shopping cart”, because total amount got calculated incorrectly:

Expected result: 294 (discount must be subtracted).

Actual result: 306 (discount is added).

BTW

ShareLane -> Let’s see buggy line of code. Go to Test Portal>Application>Source Code>shopping_cart.py and click link “BUG #6” under sub-section “View bugs.”

Expected statement: total = total – discount_amount

Actual statement: total = total + discount_amount

Example

<Product design>

Spec #9877: “7.2. User must enter two integers from 1 to 12 and press enter. Program must print on screen arithmetical mean between entered values.”

<Coding>

Here is the code written in C++. That code, also called a source code, is in text file get_average.cpp.

01.#include <iostream.h>

02.

03.void main()

04.{

05.int first_number = 0;

06.int second_number = 0;

07.float average = 0.0;

08.

09.// get first number

10.cout << "Enter first number: ";

11.cin >> first_number;

12.

13.// get second number

14.cout << "Enter second number: ";

15.cin >> second_number;

16.

17.//calculate average

18.average = first_number+second_number/2.0;

19.

20.//output result

21.cout << "Average = " << average << endl;

22.

23.}

Now, after the code is written, the programmer uses the C++ compiler gcc to compile the text file get_average.cpp into executable file get_average.

<Testing and bug fixes>

~>get_average

Enter first number: 9

Enter second number: 2

Average = 10

According to the spec, our expected result is 5.5 if we use 9 and 2 as inputs. But our actual result is 10, so we have a logical bug. What will you do now?

– You will file a bug against the responsible programmer. Bug summary: “Spec9877: get_average: wrong calculation of arithmetical mean“.

– Then the programmer should look into the problem, fix it, and reassign the bug to you (soon we’ll cover all the technicalities related to bug tracking).

– Then you must retest the code and

– if the bug is fixed, you close it;

– if the bug is NOT fixed, you reassign it back to the developer.

BTW

The problem with the code was in line 18 where our programmer didn’t put a parenthesis. Here is the correct expression:

average = (first_number+second_number)/2.0.

BTW

We should file another bug against the PM who didn’t specify the precise range of inputs. If the max valid input is 12, than the first sentence of item 7.2 must have this wording: “User must enter two integers from 1 to 12 inclusively and press enter.” Why do we need “inclusively“? Because without it:

Some folks will be confident that “integers 1 to 12” means that the max value is 12.

Some folks will be confident that “integers 1 to 12” means that the max value is 11.

Some folks will be plainly confused.

So, while writing specs the PM must make sure that everyone in the spec audience will understand the spec the same way.

BTW

That spec has another problem: it’s not specified how the program should react to invalid input, e.g., 0, 13, “A”, “#” or Null input (the user simply presses Enter without any data typed).

Example

Imagine the following situation:

1. The programmer has finished coding functionality A.

2. The tester checks functionality A and gives green light for release.

3. Ten minutes before the release, the programmer remembers something and makes a tiny change in the code of functionality A.

Theoretically, that “tiny change” should NOT affect anything, BUT in reality, functionality A stops working completely.

So we have a situation where

– the tester just wasted his time testing a not yet final version of the code

– the users got a buggy Web site

BTW

After the test case review meeting, send out an email to every participant and to those who were invited but couldn’t come to the meeting. In this email, list all improvements that you’ve talked about during your meeting. This email is very useful because

– you’ll refresh the suggested ideas in your brain;

– you’ll give others an opportunity to see that you understood them correctly.