Cairo University

Faculty of Graduate Studies for Statistical Research

Department of Computer and Information Sciences

Software Processes
Lec. 6 outline: You’ll find all the information you need here on
Different Types of Testing, Who Is Testing What, Manual,
Automation QA Tester and Crowd – Testing
..., and so on..
Tarek Aly
01126182476
http://41.32.221.109:8080/DrTarekAly.htm
E-mail: tarekmmmmt@{pg.cu.edu.eg; egyptpost.org; gmail.com; yahoo.com}
 Requirements: Minimum Viable
Product (MVP)
 If we think about it, we will almost
immediately define the needed
requirements:
 It must have wheels.
 It must have a board.
 It must have some sort of mechanism that unifies
the board and the wheels together.
 It must move using the wheels attached to the
board.
 It must have a brake mechanism.
 These are indispensable requirements.
Without these our skateboard is not a
skateboard. Then you can define some
nice-to-have features, like beautiful design
of the board, ergonomics, jumping capacity,
electrical motor, whatever.
Software Processes
 Engineering: The Team Around
the Product
 Engineering: is about creativity, innovation,
technology, and processes. Even Wikipedia knows
this: Engineering is the creative application of
science, mathematical methods, and empirical
evidence to the innovation, design, construction, and
maintenance of structures, machines, materials,
devices, systems, processes, and organizations.
 That is why it is really important to have a technical
person with you. Let’s, for example, think of the
roadmap for the MVP skateboard.
 Build wheels: 2 weeks
 Build board: 1 week
 Attach wheels to the board: 3 weeks
 Attach the braking mechanism: 2 weeks
 Test: 2 weeks

Software Processes
The agenda for the kick-off
meeting
 The description of the project (10 minutes)
 Why are we doing this? (5 minutes)
 Discussion of requirements (5 minutes)
 Discussion of dependencies (e.g., technological needs or third-
parties dependencies) (10 minutes)
 Timeline and roadmap (15 minutes)
 Roles and responsibilities (10 minutes)
 Questions and answers (10 minutes)

Remember, every project is very unique and requires different

approaches to be kicked off.

Software Processes
Message’s three dots feedback when
someone is typing a message to you

Software Processes
Backend Development: About the
Stack
 In this chapter they are going to start our project by building our
backend application (Bootstrapping, data storage, … ) that will
support everything needed by the frontend application later. The
purpose is that in the end you get an idea on what you need in
order to build a backend application and how these pieces work
together.
 Actually, they don’t believe that there’s a “best stack”; they believe
there are a set of good stacks for what you want to do—some
better than others depending on the nature of the project (Ex:,
More comfortable with a specific programming language). They
decided to write the backend application in Java 8. Installations,
commands, etc., will be done using Ubuntu Linux version 16.04
LTS.

Software Processes
Where Does Frontend Start?
 While working on our backend,
we were already thinking how
we will pass the data to the
frontend.

 So, what is frontend? Frontend

is a visible part of our
application and a connection
between it and the backend.
Thus, besides being a face of
the application, frontend has
some invisible parts that
connect this face to the brain,
which is located on the
backend.

Software Processes
 Agenda
Different Types of Testing
 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing
 Regression Testing
Who Is Testing What
Manual, Automation QA Tester and Crowd – Testing

Software Processes
Different Types of Testing: Unit
Testing
 It means testing a small part (units) of code.
 In most of the cases, what’s being tested is a method, a class, or even a module,
and the test cases should be independent from each other (e.g., test B must not be
expecting that something is created by test A in order to pass).
 You might ask, “Why do I need to write this test if I can just verify if manually?”
 They often written during development since they provide a way to test code
immediately without having to have all other parts attached. It is also a good
practice to provide several tests that run different parts of the code, such as “if ”
branches or “loops.”
 It helps us to find inconsistencies or errors at an early stage of development.
Second, as mentioned before, it protects possible future changes or huge refactors
from breaking your code, especially if it’s written in a language with compile time
such as Java.
 The downsides of unit testing are that usually the person writing the test is the
same that wrote the code, which leaves the test biased.
Ex: assertThat(user.getUsername()).isEqualTo("[email protected]");
assertThat(user.getId()).isNotNull()
Software Processes
Different Types of Testing:
Integration Testing
 It in software development is used to assert that different modules can work
together. During this testing phase the interface contracts are checked, meaning
that it will be verified that module A and module B can work together given the
previously agreed interfaces. Ex: a set of tests between modules of the same
application or project, meaning modules within the backend application and
modules within the frontend application, but never between both of them.
 The big bang testing, as the name suggests, waits for the “perfect storm”—that is,
for all the modules to be ready in order to start writing or performing tests. In big
bang testing, all the modules are integrated in one go, hence eliminating the need
of stubbing or mocking other modules in order to start building tests. The downside
is that one needs to wait for all the modules to be ready in order to test them
altogether.
 You might use a bottom-up approach where the low-level modules and typically the
ones with less dependencies are tested first. For the top-down approach, it’s mostly
the other way around, so we start by testing the high-level modules—typically the
ones with several dependencies—and for that we will need to create stubs or
mocks.

Software Processes
Different Types of Testing: System
Testing
 It is a term that combines several types of testing. Usually this testing
phase occurs after the integration testing and aims at verifying that the
system can work properly as a whole.
 The black-box testing can be either functional or non-functional.
Functional testing focuses on checking if the system is meeting the
requirements specified early, whereas non-functional testing focuses on
checking how the system performs under heavy load and stress
situations.
 The advantages of this testing technique are that because the testers do
not have any information about the internals of the application, they can
help point out discrepancies between the specifications and the actual
implementation better than someone who has knowledge because they
are not biased. Also, these testers do not need to possess programming
skills to perform this task. Being nearly impossible to test all the cases,
thus leaving some paths left untested, is one of the main disadvantages of
this kind of testing technique.
Software Processes
Different Types of Testing:
Acceptance Testing
 It is one of the last levels of testing, especially when shipping a
new product.
 During this testing phase, the software application will be tested for
compliance between the specification and the implementation,
taking into account that the business requirements or contracts are
also being met.
 Like in the previous testing phase, this one is also carried out
using black-box testing.
 These tests are done on a high level of abstraction from the
implementation, with the focus on how the final clients will use the
product.

Software Processes
Different Types of Testing:
Regression Testing
 It is one of the most important test phases when maintaining and evolving a
product. Its purpose is to ensure that new code changes do not affect the
previously tested and stable version of the software.
 Believe us when we say that because sometimes you just don’t see it coming and
even if you know the whole code base from point A to point B, at some point you
will break something. Sometimes it is not even your code, but some framework you
are using.
 Just to give you an example, just by accepting empty lists on a function that is using
Hibernate queries with the IN clause can cause a bug in your code. Does it mean
they are wrong? Well it’s complicated. If you try to write a query in SQL using “...
WHERE column IN ()..:” it will fail, so who should take care of that? The mapping
library or the programmer? This might result in an endless discussion, So as you
can figure out, during regression you don’t write new tests; you just run the previous
ones against your new version. This is the reason why it is extremely important that
you cover your code with as many meaningful tests as possible. Regression tests
can be performed on any of the previous phases discussed in this section (Unit,
Integration, System, or Acceptance);

Software Processes
Who Is Testing What?
 When product owners define the features and pass them to the developers, they
can and should already define the acceptance criteria for each feature and the test
case scenarios. So in the end of the implementation it is easy to test what has been
done.
 Developers should guarantee that the code is covered by unit tests and that the
feature is functioning as described by its acceptance criteria. However, we believe
that the testing also should be done by people other than developers.
 It is important to check at least that the happy path is not broken.Happy path is a
full journey of the user through your product, imagining that no problem has
occurred. So, for example, if it is an e-commerce platform, the happy path starts on
the registration page and ends on the successful checkout page.
 There is no difference between cars and the software we build. Once we ship it, it
will run on a totally unknown road full of unexpected actions coming from our users.
That is why to properly test it, we need to try hard to break it. It is better that we find
breaches ourselves and fix them right away rather than our users running broken
software. Well, with that being said, let me ask you a question.

Software Processes
Who Is Testing What?
 When product owners define the features and pass them to the developers, they
can and should already define the acceptance criteria for each feature and the test
case scenarios. So in the end of the implementation it is easy to test what has been
done.
 Developers should guarantee that the code is covered by unit tests and that the
feature is functioning as described by its acceptance criteria. However, we believe
that the testing also should be done by people other than developers.
 It is important to check at least that the happy path is not broken.Happy path is a
full journey of the user through your product, imagining that no problem has
occurred. So, for example, if it is an e-commerce platform, the happy path starts on
the registration page and ends on the successful checkout page.
 There is no difference between cars and the software we build. Once we ship it, it
will run on a totally unknown road full of unexpected actions coming from our users.
That is why to properly test it, we need to try hard to break it. It is better that we find
breaches ourselves and fix them right away rather than our users running broken
software. Well, with that being said, let me ask you a question.

Software Processes
Manual, Automation QA Tester
and Crowd – Testing
 Manual testers are those who would spend time manually interacting with the
product, trying to come up to scenarios where features can be broken. For
example, consider the login form. A developer would probably test it by introducing
the correct e-mail and password and clicking on the “Login” button, whereas a good
tester would type any nonsense in the input field. Do you know this famous joke
about a QA engineer?
A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 9999999 beers.
Orders -1 beers.
 Automation testers use regression because regression would have to be run quite
often, and with time it will become a big waste of resources. There are lots of things
that can be automated in this process.
 In Crowd tester If you are not into hiring QA testers or allocating
resources for testing, you can always decide to go for a “crowd-testing”
platform, which is very popular nowadays. Basically, these platforms
connect your applications to thousands of testers all over the world.

Software Processes
Testing Our Product: Test cases for
login and register functionality

Software Processes
Testing Our Product: Simple bug
report for the login functionality

Software Processes
Thank You

2022-09-15 Software Processes 19/112