An overview about the Software Tester profession for international students

1. Software Testing for
International Students
Yes! You can test it!

2. I will talk about…
 I wish to share the title of my project today: 'Software Testing for
International Students - Yes! You Can Test it!'
 In my presentation I will show facts, histories and funny things about software
testing. But I will not be so technical! I will just explain some basic concepts e
techniques. At the end of the presentation, I thinking to do a simple activity,
in groups of 3 students. I'm focus in produce something not boring, but
interesting for you!!!! :-)
 Also, I intend to share some facts about the Software Tester profession,
weekly;

3. Facts – Week 1
The evolution of testing – Part 1

4. The Evolution of Testing – Part 1

5. The evolution of testing – Part 1
Some decades ago, systems were smaller, less complex and didn’t communicate
with other systems. So, a single professional could have knowledge about the entire
system. The same professional designed, developed and tested the system. There was
no reason to exist professionals like Test Analysts or Software Testers to exist.
However, the software systems have become bigger and more complex. Different
software systems have started to communicate to each other. Now was impossible a
single professional keep all the knowledge. Professionals like Business Analyst,
Software Architect and Test Analyst/Software Tester have became indispensable to
create systems with quality.
Today, the systems are very integrated to each other. For example, imagine an
online shop where you can buy and consult your orders both by an app in your phone,
or by a browser in your laptop. These two different platforms now have to access the
same database to provide the information that you request.
A team developed the web system and another team developed the mobile
system. Now the knowledge is split into different teams and different professionals.
Someone have to test both systems to guarantee that they are working fine. That
professional is the Test Analyst and the Software Tester. Today these professionals
have became indispensable.

6. Facts – Week 2
The evolution of testing – Part 2

7. The evolution of testing – Part 2
Today, it is very common for software to need improvements, updates and failure fixes. Every new
version is tested before be released to users. However, the software is not tested only in that feature which
was fixed or improved: the ENTIRE software must be retested to guarantee that the other functionalities
are still working well. This kind of testing is called ‘Regression Testing’.
As the systems can be very complex and big, testing the entire system can be a hard task, taking too
much time. Now, imagine that the fix is something extremely important (a safe fix for example) and a
Regression Testing can take days to be finished. We can not wait days to release this fix, right?
In fact, we can’t wait. Today the testing activities have to be very agile and quick in order to not
impact the releases of new software versions. So, to improve the testing activities, we use ‘Automation
Testing’.
Basically, ‘Automation Testing’ is the activity of recording the actions during the execution of manual
testings in a automation tool, and then ‘playing’ again these actions in newer versions of the software under
testing. The advantage? Saving time!!! The tests which could need days to be executed manually, now can
be executed in a few hours because the execution becomes very quick when automated.
In addition, the software companies have awoken to the importance of automation testing, then they
are investing hardly in this kind of testing, adopting automation tools in their processes of system
development. They are looking for professionals capable of working with these tools, but still aren’t enough
professionals available in job market. Automation testing looks like be the future of testing.

8. The Cake
Following the instructions

9. Instructions for Baking a Cake
Instructions to baking a cake
1. In a bowl, put:
2 cups of flour;
1 cup of sugar;
2 eggs;
1 spoon of yeast;
2. Put all the ingredients from
previous instruction inside a
pan
3. Put the pan inside a oven
4. Wait for 45 minutes
RESULT: ???????
Have you ever baked a cake? If yes, you probably followed some
instructions to bake the cake. Were the instructions clear?
Let’s take the example to the right. What will be the result if you
follow the instructions? Well, if you have previous experience with baking,
the result can be satisfactory. However, if you don’t have experience, the
result will be a disaster… Why?
Look the last item of the first instruction: what kind of yeast do we
have to use? The chemical yeast or the biological yeast? The information is
not clear.
Another example: the second instruction says to put all the
ingredients in a baking dish. Do we have to mix the ingredients before
putting them inside the pan? Or do we have mix the ingredients inside the
pan? Obviously, an important instruction is missing: mixing the ingredients.
By the way: In what order do we have to mix the ingredients?
If you don’t have expertise with baking, and resolve following only
what is inside these instructions, your cake will not by cooked. Why? Look
at the instruction: Is there an instruction saying “turn on the oven”?

10. The concept behind the cake
This example shows an important concept present both in testing and developing activities:
the clarity of the information. The information has to be clear, without ambiguity! Why is this
important? Because if the information is ambiguous, different interpretations can be made and,
as a consequence, a different result from what is expected can be obtained. The picture bellow
can be used as an example of the consequences:

11. Writing test instructions
Before testing activities, instructions about what tests have to be made on software can be
written. Each different test can be written as a sequence of instructions, similar to the example
of baking a cake. Each set of instructions is called ‘Test Case’. Basically, a Test Cause is a
compound of: a title, a sequence of instructions, and the expected result*. By the way, a single
instruction can also have an expected result – and this result must be written near of the
instruction.
So, different sequences of instructions can produce different results. Let’s look at the
following examples of Baking a Cake:
*A test case has other parts, but in order to facilitate our understanding, we will focus only in these three parts

12. Different instructions – different results
Test Case 1: testing the yeast
1. In a bowl, put, in this order:
2 cups of flour;
1 cup of sugar;
1 spoon of chemical yeast;
2. Mix the ingredients;
3. Put in the middle of the bowl:
2 eggs;
1 cup of warm water;
4. Mix all the ingredients;
5. Put all the ingredients from the bowl
inside a greased pan;
6. Put the pan inside an oven;
7. Wait for 45 minutes;
RESULT: The batter will cook and rise, but
will not be cooked
Test Case 2: baking the cake
1. In a bowl, put, in this order:
2 cups of flour;
1 cup of sugar;
1 spoon of chemical yeast;
2. Mix the ingredients;
3. Put in the middle of the bowl:
2 eggs;
1 cup of warm water;
4. Mix all the ingredients;
5. Put all the ingredients from the bowl
inside a greased pan;
6. Turn on the oven at 400°F;
7. Put the pan inside an oven;
8. Wait for 45 minutes;
RESULT: The batter will cook and rise and
be cooked properly.

13. Writing test instructions
As you can see, a single different instruction results in a different outcome. So, can you
imagine what can happen if the instructions are not clear? Yes! Anything can happen!

14. Communicating a
Failure
Working as a team

15. Communicating a Failure
The goal of a software tester is to find failures in the software as much as possible, but this
is only the first step. He has to communicate this failure, take evidence, make description of how
to reproduce the error and then send to someone to fix it.
For a software be successful, all professionals involved must work together as a team. But,
what does that mean? Well, let’s take a real example that happened this week:

16. Communicating a Failure
In this example, Tracy tried to edit a document from Google Docs using the browser Microsoft
Edge (Microsoft Edge is the substitute of the browser Microsoft Internet Explorer). However, in
this browser the edition of the document didn’t work!!! She ask me for some ideas to resolve
this.
So, the first thing I asked: can you describe what do you did to get this problem? Tracy described
the reasons to me why she wanted to use the Edge, so I asked for a screenshot with the message.
In addition, Tracy described me the reasons why she wish to use the Edge: if she uses the browser
Chrome, she will be logout of this account only a few minutes later, automatically. This behavior
was making Tracy waste a lot of time.
That browser’s behavior seemed weird to me. So I ask for more information: the version of
windows on her laptop. Then I had all the information I needed to try find a solution: the
browser, the version of Windows system, images of the error, a description about how to
reproduce the problem, and the impact of this problem on her activities.
In this story, Tracy was the tester and I was the analyst/developer.

17. Communicating a Failure
So, what does it mean to work as a team? Tracy gave me all the information I needed to try find
a solution. When a software tester finds a failure, he has to collect all the information that can
help the developer or the system analyst understand the problem. Everyone involved in a
software project has to supply each other with information as much as possible.
If the software tester is not clear when communicating a failure, the time to fix the problem will
be longer, or worse: another problem will be fixed, or the problem will be fixed partially. What
does that mean? That means a waste of time, waste of money and stress between the team.
Usually, before to collect the information about the failure, a software tester talks with
developers and analysts in order to be sure that this failure is really a problem. In this moment,
the software tester has to be very polite when he is talking about the problem.
As a team, the focus must be on fixing the problems, not accusing others for being responsible
for the problem. The software tester has to talk with developers and analysts wisely. How?

18. Communicating a Failure
Bellow are some examples of how to NOT talk:
 Hey! I found a problem in your code!
 You made a mistake!
 Your code in that software are not good!
 You developed that page wrong!
 You didn't fix anything!
As you can see, this approach is blaming the others!
In our previous example, we know the needs and the ‘pains’ of Tracy with that problem. When
talking with developers and analysts to report a problem, the software tester must keep in mind
that they also have their ‘pains’, for example: they probably are working on many different
projects at the same time (work overload), or maybe they worked until late to release that
version for the software tester to begin his work. So, how to proceed?

19. Communicating a Failure
Bellow are some examples of HOW to talk:
 Hey! I have a question about that page! Can you help me?
 I think I’ve found something, but I’m not sure!
 There is something that is not very clear! Can you help me?
 Can you explain to me how that software works at this point?
 Does my test make sense in this case?
As you can see, this approach is focused on the problem. The software tester is looking for
resolve the issue, not find a responsible for it. Everyone is working together, as a team. In
addition, this approach gives also the ‘benefit of the doubt’. What does it mean? It means that
the software tester can also make mistakes. What looks like a problem to him can be just a
feature and, as a consequence, not a failure!

20. #funny: The Hard Life of a Tester
https://www.youtube.com/watch?v=_QV13mhwOkI

21. Documentation
Writing And Showing What You Have Done

22. Documentation
In the chapter ‘The cake – Following the instructions’, we talk about the importance of clear
instructions and a bit of test cases. Is a test case useful only for executing instructions?
Absolutely not!! The test case can be utilized by developers, analysts and even by the software
sponsor!!! Why?? Let’s see an example (This example is FICTIONAL, for didactic purposes only).
In the previous chapter (Communicating a Failure), we talk about an issue that Tracy had with
the Edge Browser. Imagine that she works for Microsoft as a test analyst, and she has to describe
this problem to Bill Gates – he will be the system analyst. Imagine that after a developer fixes
the problem, someone else will retest it to guarantee that the failure has been fixed.
So, Tracy has described the issue and has made a Test Case with the same steps that she made to
cause the issue. This document was sent to Bill Gates. There, Bill Gates reads the document and
realizes that the issue is a compatibility problem between Google Docs and the browser.
However, the compatibility problem is not in the Edge Browser, but in the Google Docs. So, Bill
Gates sends the failure description and the Test Case to Google. Meanwhile, Bill Gates suggests a
temporary solution: use the Internet Explorer Browser until the problem is fixed.

23. Documentation
In this fictional example, the test case was sent to two different companies. Without the test
case, the information about the problem wouldn’t be shared. In the real world, a test case is
used for test analysts, developers, analysts and even the sponsor. The test case is a document
that allows the specialists to know what tests have been executed in a given software release
and what results have been obtained, and SHARE this results with the team.
Also, they can be used as proof that the software was working well when it was released the
testing team. Here is a real and very common example: When software is released to the public
and doesn’t work, many times the first question is ‘The testing team didn’t get this (failure)?’.
With the test case and their results, it’s possible to prove that the testing team did made their
work well, and discovered that the problem was caused by a new code inserted into the software
BEFORE the software passed by the hands of the testing team.
Obviously, no new code can be inserted in the software version after being passed by the testing
team. If this happens, the software must be retested again before be released to users. But we
are in the real world!!! Emergencies happen and many times some fixes have to be inserted in
the software even when the testing team is testing the software – and there is not enough time
to retest all. A solution for this is the testing automation – as we saw in previous chapters.

24. Documentation
Ok, test cases are important as we have just seen. But, is it possible to have failures and errors
in the steps of a test case? YES!!! Are there some techniques to avoid this? YES!!!
When I was writing this chapter during the class, Tracy stayed at my side making a revision and
found a lot of grammar errors. Then I just fixed them. We have just made a peer review!!! This is
a technique used to find problems or ambiguities in a test case. Also, is a technique used for
review codes!!! Yes! Another developer can sit at the side of the developer who wrote a code and
then revise everything – and find failures before the software be sent to testing!
Usually a test analyst/software test analyzes the test case elaborated by another one. This
allows to these professionals to revise and improve the test case and find eventual errors.

25. #funny: Installing a New Software

26. #funny: Are you qualified to be a tester?
https://www.youtube.com/watch?v=t4Y-082CgHw