Enroll into QATUTOR Video Course on 

By Degree Of Isolation Of Tested Components

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”.


Please note that I’ve deliberately chosen not to illustrate this section with existing ShareLane functionalities. I did that to give you a feeling about test planning for software that doesn’t exist yet.


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.



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.

Brain Positioning

Remember that when you change a global setting (e.g., the system time) or do global DB manipulation on a shared test environment, you should ALWAYS ask those who use the same environment if it’s okay to make those changes. You don’t want to mess up their work!

The need for global modifications for the purpose of testing is one of the reasons why it’s a very good idea for each tester to have his own test environment on his own Linux machine. With the low prices of hardware and all the free software (e.g., Linux, Apache, Python, MySQL), this shouldn’t be a financial burden for a company.

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


As a shortcut, instead of creating new user accounts, you can pick two legacy users and manually update the DB with the necessary amounts – i.e., $1000.01 and $1002 – for those users.

Brain Positioning

You have to really know what you are doing when you hack into the DB – i.e., when you perform a manual modification to DB data. Even if your SQL query achieves its goal, you can end up with a situation where the data integrity* is seriously compromised.

*Data integrity can be defined as the correctness, completeness, wholeness, soundness, and compliance with the intention of the creators of the data (definition taken from TechWeb.com).

When you make a manual modification to DB data, you almost always affect data integrity the question is to what extent. In some situations, nothing will break, but in others bugs will show up in the most unexpected places, and the programmer will have to spent hours to debug the problem, only to realize that those were not real software bugs, but consequences of violated data integrity.

So, again: Know what you are doing.

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.


In our case, the certificate code is a combination of 10 alphanumeric characters (i.e., letters and numbers) in uppercase (e.g., LKJHG61123).


In our case, the data file must have a comma-delimited format – e.g., data blocks that are separated by a comma. Here is the layout:

<first name><SPACE><last name>,<email>,<certificate code>

Here is an example of the file:

Ferdinando Magellano,f.magellano@trinidad.pt,QWERT98362

James Cook,james.cook@endeavour.co.uk,ASDFG54209

Ivan Kruzenstern,ikruzenstern@nadejda.ru,LKJHG61123

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.


>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.


How do we simulate October 21, November 17, or any other date? Depending on the software design, the date is usually taken as the server system time or as some value from the DB. Therefore, we just need to change the system time or value in the DB.


Make sure that it’s okay with others if you make a global change on a shared environment.

Be sure that the data integrity will not be seriously impacted if you change the date in the DB.





Cert. code

Gets 5% discount?



Type of






User 1



Normal case




User 2



User 2



User should not get a discount using the code again




User 3



Cannot use cert. that doesn’t belong to you even if code is valid




User 5



User 6



This is combination of positive and negative testing to see if code still works after another user tried to use it.




User 7



User 7



This is a combination of positive and negative testing to check if a user can use his/her own code after a previous attempt failed




User 12



No discount should be given for invalid code


* This cert. doesn’t exist

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





Cert. code

Gets 5% discount?



Type of






User 9



Date: November 17




User 10



Date: November 18




User 11



Date: November 19*


* 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.


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)


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.


Let’s say that you executed a system test as a first test case, and no emails have been received. You filed a bug and went to talk to Willy. Willy looks into the code and tells you that Component 1 has several major problems. Naturally, you’ll skip component testing for Component 1 and start doing component testing for Component 2 instead.


Speaking of emails, let me share a couple of things with you:

Thing 1:

The email address consists of the following parts:

email alias


mail server domain


top level domain

Your work email will likely have an alias made up of the first letter of your first name plus your full last name – e.g., rsavenkov – so my email at ShareLane might be: rsavenkov@sharelane.com.

When we test Internet projects, we usually have to create hundreds of user accounts. The problem is that each user must have a unique email address. If you register a user with the email rsavenkov@sharelane.com on Main, you cannot reuse that email. What can you do? Should you create countless accounts on Gmail and Yahoo, or there is a simpler way? The simpler way is this: ask your IT person to tune up your mail server in such a way that mail with the following format comes through:

<email alias>+sometext@<mail server>.<top level domain>

So, if I want to create a new user, I simply use this email rsavenkov+test1@sharelane.com, and if this email has already been used, I try something like this: rsavenkov+test1new@sharelane.com, etc.

BTW, it’s a good idea to use something descriptive for your test email aliases: for instance, rsavenkov+component1@sharelane.com.

Thing 2:

In some cases, our testing requires that we enter a unique email address, but we don’t need to check if an email from the system was actually received by the recipient. I’ve noticed that some testers will enter a meaningful email address like my email qatest@gmail.com. Please don’t do that; instead, use an email like this (with a valid format, but no chance that it’s a real email): apsdofaspdioh@iasudfhasdifuhasi.com – this abracadabra is even faster to type than qatest@gmail.com! Here are three reasons for not using emails that might be real:

– It’s not nice to send junk mail (your company can actually get sued for that).

– It’s not secure to send emails that contain sensitive data.

– It’s not good for your company’s image when somebody receives a test email. Next ->

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