Software Testing for International

StudentsYes! You can test it!

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;

Facts – Week 1The evolution of testing – Part 1

The Evolution of Testing – Part 1

The evolution of testing – Part 1Some 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.

Facts – Week 2The evolution of testing – Part 2

The evolution of testing – Part 2Today, 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.

The CakeFollowing the instructions

Instructions for Baking a CakeInstructions to baking a cake1. 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 oven4. 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”?

The concept behind the cakeThis 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:

Writing test instructionsBefore 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

Different instructions – different resultsTest 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 cake1. 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.

Writing test instructionsAs 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!

Communicating a FailureWorking as a team

Communicating a FailureThe 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:

Communicating a FailureIn 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.

Communicating a FailureSo, 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?

Communicating a FailureBellow 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?

Communicating a FailureBellow 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!

#funny: The Hard Life of a Tester

https://www.youtube.com/watch?v=_QV13mhwOkI

DocumentationWriting And Showing What You Have Done

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

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

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

#funny: Installing a New Software

#funny: Are you qualified to be a tester?

https://www.youtube.com/watch?v=t4Y-082CgHw