How to Become a Software Tester (QA Engineer)

Lecture 6 - Classifying the Most Common Types of Testing -> Quick Intro -> By Knowledge Of The Internals Of The Software -> By The Object Of Testing -> By Time Of Test Execution -> By Positivism Of Test Scenarios -> By Degree Of Isolation Of Tested Components -> By Degree Of Automation

– Component testing

– Integration testing

– System (end-to-end) testing

Let’s define first and then illustrate.

Component testing is the functional testing of a logical component.

Integration testing is the functional testing of the interaction between two or more integrated components.

System (end-to-end) testing is the functional testing of a logically complete path consisting of two or more integrated components.

Let’s illustrate.

Programmer Willy was asked to write a code that would find the full names and emails of all users who spent more than $1000 shopping at ShareLane. We are going to send those users an email with a gift certificate giving them a 5% discount on a single purchase. Those certificates will be able to be used through November 17th. This feature is called “5% discount”.

COMPONENT TESTING

Let’s single out 3 components to test:

Component 1: Generation of certificate codes and the generation of a data file

Component 2: Generation of and sending emails

Component 3: Usage of certificate codes

Let’s plan our testing!

Component 1

Program cert_generator.py* has this logic:

>Check DB for qualifying users

* please, note that programs cert_generator.py and cert_sender.py are just examples, they don’t exist on ShareLane site.

IF qualifying users are found:

>Generate certificate codes and insert them into special DB table;

>Generate data file with full names, emails and certificate codes.

ELSE

>exit

Let’s narrow down our testing right away: We are not even going to consider a situation where there are no qualifying users, because we know for sure that we have plenty of them in production.

So, as a result of run of cert_generator.py, we should be able to check 4 things:

– Data in DB

– Data in file

– Format of certificate code

– Format of data file

When the code is ready for testing, we’ll perform testing on main.sharelane.com (“Main”). This test environment has its own DB, and, if necessary, we can manually change some data in it.

Test planning:

1. Login into the DB of Main and reset the total amount spent by each existing user to 0 (zero). We need this step to prevent legacy (existing) data from interfering with our testing.

2. Create data for positive testing – i.e., create new user accounts and make them big spenders (those who spend $1000.01 or more). I suggest that you create only two accounts (just trust me for now; you’ll learn why during our talk about Boundary Values):

– One account that spent $1000.01

– Another account that spent $1002 dollars

3. Create data for negative testing. You need two accounts:

– One that spent $1000

– Another that spent $998

Here again, we can also do testing by using two existing accounts and hacking into the DB to update the table with the spending history for those users.

4. Run cert_generator.py.

Expected results about the data:

– In the DB: 2 certificate codes are generated, 1 for each big spender

– In the file:

>the file has 2 records: 1 for each big spender

>for each big spender: first and last name, email and the certificate code are the same in the file and in the DB.

Expected results regarding the format:

– Certificate code

>It should have 10 alphanumeric uppercase characters. We can look in the file to check the format of these codes.

– File

>Each block must have the expected info. Look at the file format. The first block must have the first and last name separated by a space; the second block must have the email address; the third block must have the certificate code. Please note that we don’t check to see if the record has info about the qualifying users – i.e., users who spent more than $1000 (we’ve already tested that); we simply check the format.

>Blocks must be separated by commas.

Component 2

Let’s test this component in isolation. We’ll do that by creating the file manually. How do we create the file? Not a big deal; we can do it using a text editor like Notepad.

Test planning:

1. Manually create a data file and insert one record with the following data:

– A random first and last name

– A valid email, so you can check whether the software has REALLY sent the email with the correct content

– A random certificate code

2. Feed the file as input to cert_sender.py. This Python script

– Constructs email messages parsing the data file

– Sends out the emails

After cert_sender.py runs, there are two expected results:

– Email was received (positive testing)

– Email message has the correct content (positive testing)

Also, you can do negative testing:

1. Create several bad data files manipulating with absent and/or corrupt data, and/or wrong format. For example record has no email:

Ferdinando Magellano,,QWERT98362

2. Feed those files to cert_sender.py one by one.

Expected result: error message each time when bad file is used as input (negative testing).

Component 3

Let’s test this component in isolation. How can we do this?

As you recall, a certificate code is a combination of 10 alphanumeric characters – e.g., LKJHG61123. The certificate code must be entered during checkout, and if that code is valid, the total amount* should be reduced by 5%.

*At ShareLane, we offer free shipping on all orders, but if we had shipping charges the 5% discount would be applied to the total amount before shipping.

We can:

– Ask a programmer to generate some certificate codes for us

– Find out how to hack into the DB to manually insert some random certificate codes

– Write a helper script to generate those certificates

Test planning:

1. Get 11 valid codes. Let’s assume that we have these numbers:

11111AAAAA for User 1

22222BBBBB for User 2

33333CCCCC for User 3

44444DDDDD for User 4

55555EEEEE for User 5

66666FFFFF for User 6

77777GGGGG for User 7

88888HHHHH for User 8

99999IIIII for User 9

10000JJJJJ for User 10

11000KKKKK for User 11

no certificate for User 12

2. Set today as October 21 (or any date before November 17) and execute test cases from below.

* This cert. doesn’t exist

3. Before executing each test case, set time to date, as noted in Comment column.

* October 21, November 17, 18, and 19 have been picked by using the Boundary Values technique that you’ll learn soon.

We checked Components 1, 2, and 3 in isolation; in other words, we assumed that they are independent from each other. Now it’s time to test integration between those components.

INTEGRATION TESTING

There are three points of integration:

Component 1 – > Component 2 (data file generated by cert_generator.py is used by cert_sender.py)

Component 2 -> Component 3 (certificate code taken from email message constructed and delivered by cert_sender.py is used to get 5% discount)

Component 1 -> Component 3 (certificate code generated by cert_generator.py is used to get 5% discount)

Test planning:

Component 1 – > Component 2

1. Login into the DB of Main and reset the total amount spent by each existing user to 0 (zero).

2. Create one big spender account (e.g., $2000 spent) with legitimate email.

3. Run cert_generator.py.

4. Run cert_sender.py against the data file generated by cert_generator.py.

5. Check your email account. Expected result:

>Email was received

>Email has correct content (positive testing)

Component 2 -> Component 3 and Component 1 -> Component 3

6. Use the certificate code from the email to get a 5% discount. Expected result:

>Discount is granted (positive testing)

SYSTEM (END-TO-END) TESTING

A system test is a scenario to test a feature from start to finish – e.g., component1 – > component 2 – > … – > component n. In our case, the system test can be done by executing steps 1 to 6 inclusively used for integration testing.

We looked at the system test last, but I recommend that you create one test case with a simple system test as the first test case of your test suite. Why? Because it will serve as an acceptance test for that particular feature. In some cases, it doesn’t make sense to do component/integration testing if the system test fails.

Lecture 6 - Classifying the Most Common Types of Testing -> Quick Intro -> By Knowledge Of The Internals Of The Software -> By The Object Of Testing -> By Time Of Test Execution -> By Positivism Of Test Scenarios -> By Degree Of Isolation Of Tested Components -> By Degree Of Automation