Manual Testing

• In manual testing you need to write four important documents, Test scenarios , Test Cases, Summary Report.

• So, the first role that we have is the requirements engineer and the word requirements engineer means. that any person who deals with the requirements, the person who gathers the requirements and analyzes them.

• So, the requirements engineer is considered as the link between the client and the IT team.

• Business analyst, He analyzes the business, so this person sits with the customer He gathers the requirements with many techniques like qualitative interviews and quantitative interviews.

• Role as a software tester You might be sitting together with the business analyst while the requirements are written so that you review them .You need to find any ambiguities in them You might find some contradictions.

• The requirements that are written and gathered by the business analyst will influence your testing tasks .So, the tester mostly will create something that's called test scenarios or test cases.

• So, in order to generate those scenarios or cases, you need the requirements that are written by the business analyst.

• That we have a defect, and we should write something that's called a defect report.

• First, the business analyst gathers the requirements and writes something that's called SRS or BRD, and then delivers those requirements to the product owner who delivers them to the development team. So those are the two main
roles that are related to gathering and writing the requirements.

• After gathering the requirements project comes to the design that's called UI, UX designer.

• UI means user interface. So, the user interface is what you see is, when you open the application.

• On the other hand, the word UX means user experience. It is not talking about what is present on the screen. It talks about the whole experience of the user. While he is using your application, is he interacting with the application in
an easy way or not?

• Next, we will talk about development or coding.

• The front-end developer converts the design that is delivered by the UI designer into a code. So, for example, we have a design of a screen, login, sign up and so on. So, for example, the login button, this is not a button, this is just a
picture that says login. So, the front-end developer converts it into a button. And when I click on it, for example, it redirects me to the login page. Mostly he uses tools like CSS, HTML and JavaScript.

• sequential development
• analysis
• design
• implementation
• testing
• In sequential development there are two process
• waterfall method
• v model software development

• Water fall model

• Design
• Development
• Testing
• Deployment :Deploy the application to the end customer.
• Maintains
• The waterfall model has its advantages and disadvantages.

adv
• If you have a small team, let's say, for example, three persons, so you don't need a dedicated person for each step, the whole team can work on gathering the requirements, then the design, then development ,then testing and so on.
Another good situation in which using the waterfall is very beneficially, is when you have already known requirements. In waterfall, like we see after deploying the application, the user can use it only one time.

• dis
• In the waterfall, like we see after deploying the application, the user can use it only one time.
• We said that one of the disadvantages of the waterfall is that testing begins late in the life cycle.
• Requirements

• v model software development

Requirements Acceptance Testing

Specifications System Testing
Architectural design Integration Testing
Detailed design Unit Testing
Coding

• 1.Unit testing: means that you test each component or unit individually, so anything that can be tested.

• 2.Integration Testing: You test the integration between different components or units. Okay, so when you sign up, Am I be able to log in with the same user or not? After this, you get a whole system.

• 3.Acceptance Testing: So acceptance testing is the last step of testing that ensures that the application is ready for deployment or for usage by the end user.

• 4.System Testing: Most of the software tester tasks are in system testing, in many projects or in most projects.

• Unit testing and integration testing are the responsibility of the developer. And the acceptance testing is the responsibility of the client or the product owner or the business analyst. We begin by writing those requirements, the
business requirements. And after this the tester begins to review those requirements. So, begin reviewing those requirements for ambiguity, for contradiction, for anything, and then find any problems in those requirements.

• Agile Development

○ So Agile means the ability to move quickly and easily. So, in Agile in a general way, we have 4 values and 12 principles which we will discuss later. But the main idea behind Agile development is to deliver continuous feedback to
the customer. The main idea behind Agile development is to deliver continuous feedback to the customers.
○ We have Agile and inside Agile, we have Scrum, Kanban, spiral and so on and of course XP.

notes Page 1
○

scrum process

○ 1.in this the srs and brd is called as product back log. It includes requirements in the form of something that's called user stories. this users stories are written by product owner.

course start from here

○ Definition of testing
○ We as testers receive a build from the developers. We begin testing it and reporting the defects to the developer .We begin testing it and reporting the defects to the developer. We are not the one who remove the defects.
The removal of defects which is called debugging is a development activity. This is a developer responsibility but after the developer removes the defects by debugging we begin confirmation or retesting. We test the software
again in order to make sure that the defects that we already reported is really fixed.

 objective of testing

○ Work products = The work products are anything that is produced while we are working inside our software whether it is the requirements, the code, the test cases, test plan, the design, the summary reports all of these are
considered as work products.

○ Requirements fullment = So we evaluate the work products. we ensure requirements fulfillment we ensure that our software fulfills the requirements of the client.

○ Building confidence = We need to make sure that our components and systems are good enough.

○ Finding defects and prevent defects

○ Of course we try to find defects and we try to prevent defects by early testing. If we begin testing early especially static testing that will prevent defects from occurring late in the lifecycle.

○ Providing information to stack holder = We provide information to stakeholders. The stakeholders like the team leader, the manager, the client, and the user. We give them enough information about the level of the quality so
that they can decide is this software ready to be delivered or not.

○ Reduce risk = We reduce the risk of failures in user operation like we said.

○ Comply with laws and regulations = If we have a contract with the user we try to make sure that our product satisfies this contract.

○ Objectives may vary = depending on the type and the level of testing that we are performing now.

○ The removal of defects which is called debugging is a development activity. This is a developer responsibility but after the developer removes the defects by debugging we begin confirmation or retesting. We test the software
again in order to make sure that the defects that we already reported is really fixed.

 Test process = he test process is the steps that we go through in order to test our software. Any test process consists of three basic parts.

 Stages in test process = planning, design and execution

□ planning = so at the beginning we write our test plan, our test strategy. We analyze our software then we design our test cases, our test scenarios.

notes Page 2
 □ design = We choose our environment. We write our testing scripts which is the code.

□ execution = test report , defect tracking and analysis , report.

 Test process activities

Test planning : A test plan is a document detailing the objectives, resources, and processes for a specific test for a software or hardware product. The plan typically contains a detailed understanding of
the eventual workflow.

Monitoring and control :

Then while we are moving in our project we begin to monitor our progress. We begin to compare our actual progress to the expected progress that is written inside the plan. If they are the same we continue in our
project. If there is a difference between them we perform control activities so control activities or any corrective actions.

Analysis :
Then we analyse our requirements, with read the requirements. We search for defects inside it and we analyse it in order to find the test conditions or the test scenarios. The test conditions are: for example we read
the requirements so we can say we have a test condition
Design: We begin to write our test cases so the test condition which is verify Login for example is divided into more than one test case. The test case writing is a very important skill for software testers and we will
discuss this skill in the We begin to write our test cases so the test condition which is verify Login for example is divided into more than one test case. The test case writing is a very important skill for software testers and
we will discuss this skill in the.

Implementation: We organize our test cases into test suites. We design our test environment and the environment is the place that we will begin our testing on. So the environment maybe a simulator or an emulator
or Google Chrome, Firefox, Android 7.1,Windows 10 and so on then we execute the tests, find defects, report them, perform retesting and regression.

execution :

completion :

 Test levels : The levels of testing are groups of test activities that are organized and managed together. Each test level is an instance of the test process.

Unit or Component testing : This level tests anything that is separately testable.

Integration testing : Integration testing focuses on interactions between components or systems. So this is known as integration testing. In this testing The second level is integration testing. Integration testing focuses
on interactions between components or systems. And we have two types of integration testing. Component integration testing and system integration testing. Component integration testing focuses on the integration
between components. This level is also performed by the developer. integration testing means that we have a big project and this project consists of many systems. so like we said component integration testing is often
the responsibility of developers. Then we have system testing. System testing tries to test the system as a whole. This is the most important test level for testers.
So 90 % of the testing for the software tester is performed inside system testing, not unit, integration or acceptance testing.

System testing :
System testing examines every component of an application to make sure that they work as a complete and unified whole. In other words, a computer system consists of a group of software to perform the
various tasks, but only software cannot perform the task; for that software must be interfaced with compatible hardware. Tester is responsible for System integration Testing

Acceptance testing : Acceptance testing is similar to system testing but the difference between them is that in system testing, we try to find as many defects as possible and it is the responsibility of the tester. On the
other hand, acceptance testing tries to make sure that the software performs correctly. So finding defects is not the major goal of acceptance testing and most of the times it is done by the users or the stakeholders. That's
why we have a type of acceptance testing which is called alpha testing and beta testing. Alpha testing means that we bring customers to the company and make them test in our premises. Beta testing means that we make
the customers test our application on their site at their homes. That's why you'll find some beta versions of antivirus or for Windows or Office. This means that this version is still under test. We give it to the customers so
that they make use of it and give us bugs if they find them.

 Testing Types :
Functional testing : functional testing means that we test the main functions of the software. So functional testing is the most dominant type of testing that we use in most of our jobs or most of our daily tasks .

Non Functional Testing :

this testing type tests how well the system behaves also usability. Usability means is the software easy to use? is the user interface appealing enough? In this case we cannot say yes or no. This is a point of view. This is an
objective way of testing, also security. We cannot say that this software is 100 % secure. No we say we have performed like a security threat analysis. And most of the vulnerabilities are covered. These are the
vulnerabilities that we covered while we are testing.

Black Box Testing : We have also black box testing. Black box testing is like a technique more than a type but some people consider it as a testing type. And black box testing means that we test without looking at the
internal structure of the software. So for example if I have a mobile app I will provide input and wait for the output. So this is black box testing. The application is like a black box. I will not open it and look at the code. I
would not look at the database .I will not look at or review the APIs. So this is black box testing. And this is easier ,this type of testing is very important but also it is easier to perform.

White Box Testing : You provide input to the software and you also look at the internal structure of the software, what is happening in the code, in the database, in the APIs, while I'm performing this input, while I'm
providing this input to go to the output. This is a more advanced topic of testing. White Box Testing and it is more challenging because in order to perform this type of testing you must understand the programming
language that this software is built on. So we have functional Vs. non-functional, black-box Vs. white-box. So can we have a combination between them. Of course. So for example we can be doing functional testing using
black box testing or functional testing using white box testing. If we are testing the functionality but looking at the code. Also we have dynamic testing, dynamic testing means that we are executing the software like we
said in the test process. there is something that's called execution. So if we run the code, this is dynamic testing. If we run the application this is dynamic testing. If we run the hardware component, we are doing for
example embedded testing.

notes Page 3
 Dynamic Testing :
Dynamic testing means that we are executing the software like we said in the test process. there is something that's called execution. So if we run the code, this is dynamic testing. If we run the application this is dynamic
testing. If we run the hardware component, we are doing for example embedded testing. This is dynamic testing. So for example in the login page, dynamic testing means that I must provide email, password, and provide
input to the software while it is functional or non-functional, black-box or white-box. All of these can be dynamic testing.

Static Testing : static testing is testing while we don't execute anything in the software. Like what? Like reviewing the requirements, reviewing the user stories. User Stories is a type of requirement that we will talk about
in agile testing. If we review the code that the developer wrote. If we review a prototype of the application UI and give some notes about it. All of this is considered as static testing. So we have dynamic and static testing.

Retesting Or Confirmation Testing :

Also we have some testing types that are related o changes that are performed by the developer. So if the developer for example had a defect in his code, we wrote a bug report, we sent it to the developer the developer
fixed it and then he is happy like this picture. He says "I solved the problem, this defect is not in the software" In this case we do not trust the developer. What we should do is that we perform retesting or confirmation
testing. What is this type of testing, in this type of testing We do the same steps that produce that effect and then we say this defect is solved or this defect is not solved. This is a very important testing type that we as
testers perform every day.

Regression testing : Regression testing refers to a type of software testing that is used to verify any modification or update in a software without affecting the overall working functionality of the said software. Selecting
Regression Testing Test Cases Select test cases where there are recent code changes or functional changes. Select test cases that map to the business requirements. Select test cases in the areas with frequent
bugs/defects. Select test cases for the areas which are visible to the user.

Smoke Testing : This type is asked a lot in testing interviews. Smoke testing means that we have an application like Facebook , Instagram. Any application this application has many too many features. So when the
developer changes a feature should we test the whole application like we said in regression testing. Sometimes we don't have time to do this so what shall we do? In this case we have some testing scenarios or test cases
that are called Smoke testing. These are the scenarios that test them in functionalities. The most basic functionalities is in the software. And depending on their results we say this build is stable enough so that we can
continue testing. the invalid scenarios and the negative scenarios, the non-functional characteristics or this build is not stable enough and we return it to the developers so that he solves the problems in it. So for example
like this picture says we'll get an initial build from the developer. And he gives us this build. Then before beginning our test cases we perform the smoke testing. It should take half an hour, one hour, two hours at maximum
but not three days. And if this testing passes, if the smoke testing passes, then we can perform functional testing, non-functional testing and all other types of testing. If this testing fails then we return the build to the
developer. Throughout our course we will talk about all these testing types in further details. We will begin to execute each type of testing using different testing tools and compare between these tools and talk about the
best techniques to find defects in our software.

Test Scenario Writing :

A scenario is a credible and coherent story about how someone can use an application. Test Scenarios are created to ensure that every functionality a website or app offers is working as expected. It is best to gather input
from clients, stakeholders, and developers to create real/accurate test scenarios. This helps effectively cover all possible user scenarios and enables comprehensive testing of all business flows of the software in question.
Test Scenarios are required to verify the entire system’s performance from the users’ perspective. When creating them, testers need to place themselves in the users’ shoes to clarify what real-world scenarios the software
will have to handle when made public.

How to create a Test Scenario

 Carefully study the Requirement Document – Business Requirement Specification (BRS), Software Requirement Specification (SRS), and Functional Requirement Specification (FRS) about the System Under Test
(SUT).
 Isolate every requirement, and identify what possible user actions need to be tested.
 Figure out the technical issues associated with the requirement.
 Also, remember to analyze and frame possible system abuse scenarios by evaluating the software with a hacker’s eyes.
 Enumerate test scenarios that cover every possible feature of the software.
 Ensure that these scenarios cover every user flow and business flow involved in the operation of the website or app.
 After listing the test scenarios, create a Traceability Matrix to ensure every requirement is mapped to a test scenario.
 Get the scenarios reviewed by a supervisor, and then push them
 to be reviewed by other stakeholders involved in the project.

Test scenario example : 1

For this sign up we have to write our Test scenario for sign up log in

notes Page 4
Test scenario example : 2
We have to write Test scenario for kfc sign-up

Test scenario example : 3

We have to write test scenario for face- book sign-up

notes Page 5
 This test scenario is used for user name log in

Mobile number or email address scenario

Password test scenario

Gender scenarios

It is a technique of software testing in which we divide the system into partitions, and each partition has similar output is called equivalence partitioning.

Test scenario example : 3

We have to write test scenario for face- book log in

notes Page 6
 Valid log in scenarios

Invalid log in scenarios

Test scenarios example : 4

Test scenarios for searching in any website

The test case Writing

Definition : A test case is a set of preconditions, inputs actions, expected results and post conditions developed based on test conditions. A test case is developed based on test condition.

Example for writing the test case log In page

1. Test case
Verify log in with valid username and password
2. pre condition
user is already registered using valid credentials
3. test steps
enter a valid user name

notes Page 7
 enter a valid user name
enter a valid password
click on sign in.
4. Expected results
User is logged in scucefully and redirected to the next page
5.Test scenario
Log in
6.test environment this three things are consider
The hardware
the software
network
7.

Example for writing the test case in the excel

https://docs.google.com/spreadsheets/d/1qmSL0UPu3DhXAwoF1VLUZqG4nqU2Jct3K_7GxJPgxnE/edit#gid=509497296

Test case writing using excel sheet for username

This is the text case writing for user name

notes Page 8
 Test cases for email verification

Test cases for password

Bug reporting writing

We have three main steps.

1."Test Planning" When we write our plan, we begin to plan for our project.
2. test design, in which we begin to write our test.
3.executing the test cases, comparing between the expected result and the actual results.
Def for defect report : documentation of the occurrence, nature, and status of defect.

def. for bug: A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.

bug report def.: If bugs occur the person finding the bug should be able to report (document & send) the bug to people in charge of fixing that error or failure.
A bug report is something that stores all information needed to document, report and fix problems occurred in software or on a website. And in the best case scenario: This is done in the most efficient manner possible.

An imperfection or deficiency in a work product where it doesn't meet its requirements or specifications.is comes under
Defect. Bug. Fault.

Bug priority has 4stages

notes Page 9
Types of defects
1. Content
2. Performance
3. Suggestion
4. Visual
5. Functional

Example for defect report

Test Reports

Def: Test Reports are an essential part of Software Testing in any project. Reporting how your testing has progressed and how it is going helps the stakeholders of the project to make key decisions regarding the project's quality and its
subsequent release. there are two types of reports.

The test Progress Report: Is a type of testing report that's produced at regular intervals about the progress of test activities against a baseline risks and alternatives requiring a decision. We call it also test status report.
So, for example, we have a project that will take 6 months. We can write a report each week. So this report is a test progress report.

The test summary report: This report is produced at completion milestones.

What is the best work product to be given to the client as feedback on the quality of the product is given by test progress report.
It is a type of test report produced at completion milestones that provides an evaluation of the corresponding test items against exit criteria is given by test summary report.

Example For Test Case Writing

https://docs.google.com/document/d/1PmayrShEgUoz-ZNlY9gP2Fi1Qj1RJ-aE7cRnlpH0nng/edit?pli=1

Manual software testing interview questions

Basic Of Agile and Agile Testing

The four values of agile

1: Individuals and interactions

Previously, software developers would spend ages creating detailed documentation. That was before they even started writing a single line of code. And while documentation isn’t a bad thing, there comes a point when you should focus on
providing your customers with working software.
The Agile Manifesto places shipping software to your customers as one of the highest priorities. You can then gather feedback to help you improve future releases.

2:Working Software Over Comprehensive Documentation

Previously, software developers would spend ages creating detailed documentation. That was before they even started writing a single line of code. And while documentation isn’t a bad thing, there comes a point when you should focus on
providing your customers with working software.
The Agile Manifesto places shipping software to your customers as one of the highest priorities. You can then gather feedback to help you improve future releases.

3:Customer Collaboration Over Contract Negotiation

So, the relationship between us, the team and the customer is more important than the contract that we have with him. So, for example, if we have a contract with the customer that states that you should have 10 functionalities and we
agreed on these functionalities only and the customer told us, OK, I need to change some of these functionalities. I need to remove this one and add another one better than it or something like this. In this case, we should not say, no. We
agreed at the beginning, and we can't change anything. We can't change the functionalities. the scope of the project. the deadline or the release date of the project.
Agile says The more important is that you have customer collaboration. You must collaborate with the customer and try to make sure that he is satisfied with the software that he gets.

4: Responding To Change Over Following Plan In Traditional Software Or Projects

Can you imagine a time where you would draw up a roadmap and it would never change? Well, in the past that’s exactly what happened. The trouble with static roadmaps is that we don’t live in a static world. Needs and requirements are
always shifting, and priorities are always changing. That static roadmap will soon grow outdated.
That’s why the Agile Manifesto suggests that a software team should have the ability to pivot and change direction whenever they need to, with a flexible roadmap that reflects that. A dynamic roadmap can change from quarter to quarter,
sometimes even month to month, and agile teams are able to keep up with those changes.

12 Principles of agile

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

notes Page 10
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

notes Page 11