Software Development Life Cycle

The following are the major phases or major activities involved in developing a software
application.

SDLC Models:
Software Development Models will explain the way of constructing a project. There are two
ways of generally constructing the project, incremental approaches and sequential
approaches. Waterfall model and V models comes under sequential methodology. Agile
model comes under incremental methodology.s

Sequential Models:
The sequential models are recommended for developing small size of projects.
Waterfall Model and V Model are the best examples for sequential models.

Waterfall Model:
 Waterfall model will be chosen for developing small size projects where the
requirements are very clear like a School Management System, Hospital Management
System, etc. . As the requirements are very clear, chances of making mistakes during their
development would be less. Hence, testing is carried out after the development i.e., Only
validation no verification in Waterfall model projects.

V Model:
 V-Model will be selected V model will be selected for developing small size of projects
where the requirements are confusing or where the requirements are complex(sensitive).
Even if the requirements are few, but every feature is important and minor mistakes also not
accepted. In this situation, we go for V model. If a CT Scan machine generates a wrong report
and no working as expected, doctor may not proceed for further treatment.
As the requirements are complex, chances of making mistakes during development
would be high. So, to find out the mistake at early stages, testing carried out testing is
carried out right from the requirements that is both verification and validation both
verification and validation.
Examples of Small-scale projects where the requirements are few but complex are Medical
Treatment Software, Airplane navigation system, Traffic signals application, etc.
Actually, number of requirements are very few in traffic signals application showing the
directions but a minor mistake also not agreed. Two sides it is giving a green signal, accidents
will happen. In Traffic signals application, a pilot will drive the plane based on the signal
generator and if it is produced a wrong signal, he will go in a wrong direction. Such kind of
software application where number of requirements or number of functionalities are very
few but every functionality is very important, a minor mistake also not agreed, to develop
such a critical application, such a sensitive application, management will choose to go with V
Model.
In V model, as the left side is the input to carry out right side activity, the diagram took
in the direction as shown above. Almost it looks like a V shape, people named as V model.
Verification activity introduced from the V model. Once verification was introduced,
people have observed advantages of doing verification to find out the mistakes at early
stages, it is continued in all remaining models. Only in the waterfall model, testing is
performed after the development i.e., only validation. Rest of all software development
approaches, both verification and validation are performed.

Incremental Models:
Incremental models are recommended for developing big size of projects. In
incremental models, a big project is divided into smaller modules then module by
module system gets implemented. RAD model, prototyping model, spiral model and agile
model are the examples for incremental models.
Agile model is the most popular(used) incremental model.

Agile Model:
In Agile model, a big project is divided into modules, then each module further divided into
smaller components called Sprints. Then sprint by sprint, software gets implemented. Two-
three major business requirements are considered to implement at One schedule or one
Sprint.
A small piece of a module can be called as a sprint i.e., short schedule made for developing a
product can be called as a sprint.
let's say totally 40 requirements to be implemented in a product. In waterfall model, we plan
a lengthy schedule- three months of schedule- all 40 requirements will be implemented at
One schedule, whereas in agile model, totally 42 implemented but this will be split into
multiple phases- not three months of schedule, but one week of schedule, maximum 10 days
of schedule. Rather than making a lengthy schedule, make short schedule - one week of time,
ten days of time, not more than that. Consider two three major business requirements to
implement at one short schedule rather than asking developers, rather than asking testers
you develop 40 requirements and you test 40 requirements, work will be split like this- this
week you develop the home page, login page, user registration page, you write scenarios and
test cases for testing user registration, login and home page, we test those. Once those two
requirements is fully finished, I demonstrate to my client that this week these are the two
features we implemented for your business, if you say okay, then we go further. Once the
customer confirmed, next week we plan other two, three major business requirements, next
week you plan other two three major business requirements. Like these small schedules are
made and all 40 requirements will be implemented in 10-20 schedules.
What is the advantage of this approach? If I am giving a lengthy schedule for a person
the work will go slowly. If there is a short schedule, very aggressively work will go. If I ask my
developer you have to develop these 40 functionalities three months of time, first one or two
months this developer will not work aggressively. If I ask my team member you write test
cases for the 40 requirements, the work will go very slowly. Instead, if I say the developer
that next two days you develop the homepage, you develop user registration page, you
develop the login page, next two days you write scenarios and test cases for home page, you
write scenarios and test cases for user registration, you write scenarios and test cases for
login in three days of time. After three days, there is a review meeting, you have to
demonstrate the output to the scum Master project manager, I'll have a review. You need to
demonstrate the test cases to the project manager; I have a review. If I have any comments
about these two requirements, I'll give my updates, again modification, once I am happy with
the output, I'll show to my client so this week these four functionalities we have
implemented for you it's okay or if you have any comments on this and customer given some
comments. Based on the customer given comments, if required again modification, again
testing, again project manager will have a final output review, again demonstrate to the client
and if client said okay keep it aside, plan next two - three requirements. Rather than asking
developer 30 days you develop this, ask three days you develop this. Rather than giving 10
requirements to developer on 30 days of time, give only one or two requirements to
developer and give two days of time. No chance of skipping even one hour. That too rather
than understanding 40 requirements, you are focusing on understanding only two
requirements where the understanding levels would be high. Instead of planning all works
together, you plan small works, do it and go for next to requirements, do it next go for to
requirements. In this way, you will get a very productive output. It's a practical proven
scenario that 30 percent of the budget can be saved if you go with agile model instead of
when you compare with waterfall model. If I am developing 40 requirements in waterfall
model of three months of schedule, the estimated cost is 100 dollars. When the same project
will be opted for agile model, same project can be finished within 70 dollars. Budget saved,
time saved, very productive output, and every two three requirements you are showing to
the client, getting the approval, no chance of project failure and the frequent
communication with the client will give you the better output.
Note: Any compiled format of the application is called ‘build’ or ‘release’ or ‘version’.
If you are working on agile model projects, automation testing will start from the
beginning. Today, mostly projects are agile model projects. Every week, every 10 days, there
are some updates are happening and every updated version need to be retested. Doing this
retesting every time demands more man power, more time. This increases the cost. To
minimize this, we are planning automation testing when you are working with agile model
projects. If you are working on waterfall and V model projects, mostly manual testing is
there because in these models, testing is one time activity.
Software Testing Techniques or Approaches or
Methodologies:

Software Testing is classified into Verification and Validation. Verification is also called
as Static Testing and Validation is also called Dynamic Testing. Now a days software testing
approach is both verification and validation. Old approach is only verification.
Why Verification is called Static Testing?
On the entire verification(Reviews and walkthroughs), no code is executed, no
application is getting executed. Hence the verification process is called Static Testing. We are
testing whether we are building the right product or not by not executing the code.
Once the code is implemented, programmer will run(execute) the code and check her
code is working or not. This is called Dynamic testing.

Verification: (Static Testing)

There are many technical activities involved in building a product. At every stage of
building a product, not after building the product, if you have a check, are we building the
right product or not, that is called verification. If we check whether the developed product is
right or not according to the client requirement, then it is called validation.
Verification is carried out in organizations by conducting ‘reviews’ and ‘walkthroughs’.
Review:
Examining(cross checking) any project development related work(job) is called as a
review.

Different Types of Reviews:

1. Requirement Reviews – By Business Analyst
2. Design Reviews – By System Architect
3. Code Reviews – By Developer
4. Test Case Reviews - By Team Lead(Tester)

Requirement Reviews:
Business Analyst and her team prepare the requirement documents. Once the
requirements are documented(SRS, FRS), Sr. BA(domain expert) will have check whether all
customer expectations are correctly documented or not. Verifying or reviewing the
requirement documents whether they are documented as per the customer expectations or
not is called Requirement Review.
In order to confirm the requirements are documented properly or not, no
code(application) is executed, only reading and checking the requirements documents.

Design Reviews:
Once the requirements are verified and approved, approved requirement documents
are given to the design team. Based on the requirements document, project architecture is
made, use case diagrams are made. Whether the design is made as per the approved
requirements or not, will be checked(verified) by the System Architect. This is called Design
Review.

Code Reviews:
one the design is reviewed and approved, the approved design will be hand over to the
development team. After building the code, a senior developer will have a check whether
the code is made as per the standards or not. A programmer should not write the code as
she wish.
Every code on the top, there should be some comment section. In a very simple English,
comment section should explain what is this program, what are the inputs for this program,
what is the output of this program, who prepared and when prepared. Rather than reading
the 100 lines of technical code, just by reading the comment section anybody should be able
to understand what for this program is made. Java program or Python program whatever,
before you start writing the technical code, first we need to put a comment section. The
comment section must explain description of the program i.e., what for this program is made,
what are the inputs, what is the output, who prepared and when prepared. So, instead of
reading the complete technical code by reading the comment section and in future anybody
should able to understand okay what is this program finally doing.
Programmer will declare some variables. They should not simply declare variables like
a or b or c. They should follow some naming rules. Say I am declaring a variable to store the
employee number, eno or empNo should be the variable name so that anybody can
understand okay this variable is used for storing the employee number. Instead of B, it is
preferred to declare a variable with a name called ename so that anybody can understand
okay this variable to store the employee name, so that in future also anybody can understand
what is the purpose of this code. Today these people involved in writing the code, tomorrow
they lest the company, I recruited other new two programmers but they are not
understanding what the code these people have prepared. It's a question mark for
continuation. So, there are some coding rules, coding standards to be followed for ease of
understanding the code, for ease of enhanciability, in future maintenance.
So, after writing the code, a senior developer will have a check whether the code is
made by following the rules, by following the standards or not. there are some coding
standards, developers should know them. Like we follow testing standards, they have to
follow coding standards. Such activity of verifying the code whether the code is written as
per the coding standards or not is called code review. Developer is responsible for doing
code reviews.

Test Case Reviews:

My team members created some test cases for validating a product. No guarantee
these test cases are enough. As a senior person(team lead), I need to have a check whether
the prepared test case are enough for testing the product or not. I ask my team members
you write test cases for these four requirements. The Created and submitted to me. What is
the guarantee these test cases are properly designed. They may miss one or two, they may
do some mistakes while documenting test data. So, I need to have a check whether the
prepared test case correctly documented or not and prepared test cases are
enough for testing this product or not. This activity is called test case review. We will
do test case review? Team members will prepare test cases, submit to the next level(lead
level). The lead will verify and confirm whether the prepared test case are enough for testing
the product or not. Team lead also belongs to tester category.
Requirement reviews, design reviews, code reviews and test case reviews are the
different types of reviews carried out in organization. By doing these kinds of reviews, we
confirm as we are building right product or not, not after building. In order to confirm are
we building the right product or not, at every stage of implementation, corresponding cross
check activity needs to be performed - requirements need to be reviewed, design needs to
be reviewed, code need to be reviewed, prepared test cases also need to be reviewed.
These are the different types of reviews carried out in organizations.
Walkthroughs:
Knowledge Transfer(KTs) are called Walkthroughs.
Or

Any training, any meeting or any discussion about a domain, about a

technology, about a process can be called as a walkthrough.

What do you mean by knowledge Transfer Sessions?

These four people working in our Organization for last three years. They have very
good experience in testing. But in the previous experience, they worked on a banking project
and they worked on the e-commerce project but they never worked on an insurance domain
project. Now the new client and new project is an insurance domain project. These people
are new to Insurance business domain, they have worked on banking earlier, they worked on
ERP, they worked on e-commerce, first time these four people working on the insurance
project and that previous project is closed. Now I move these team members to a new client,
new project that is insurance domain. They know how to write scenarios, they know how to
write a test cases, they know how to develop automation program, they have the experience
but they are new to domain i.e., Insurance domain. What to do? Will you fire these four
people and hire new people. What is the guarantee new people know about insurance
domain. Any good organization believes training a resource is a solution for a company not
firing a resource. Once, software organizations are recruited until there is a serious situation
condition, they do not fire because firing the employees will give a bad mark for the software
company, next time the employees will think about joining with the company. A good
organization, professionally managed organization will never fire the people. If one employee
not able to do it properly, if I am firing this person and hiring the new person, what is the
guarantee new person will do properly, second employee also not doing properly again I am
firing the second person and hiring the new person, what is the guarantee here. Finally, here
what I am doing? I'm focusing on firing and hiring not focusing on doing your business. In
businesses, I have to focus on doing the business not firing and hiring. So, train the people,
give the KT, explain the product, they will understand and they start doing the work because
any new client, any new domain, first we need to understand. So, in organization KTs are
given, trainings are given, meetings, discussions and knowledge transfer sessions all comes
under walkthroughs.

Other examples of Walkthroughs:

A senior person will explain the requirements of the team members called a
walkthrough. Suppose you are automation testing team. Your my automation testing team.
As of now we are using selenium 3 version for building the automation script. Today selenium
4.0 came into the picture. Next to version of the selenium released into the market. As a
senior person my responsibility is I need to explore what are the new features given in the
selenium 4. Maybe after some time I'll organize a KT to my team members because I have to
train my team, I have to guide my team, that is the lead responsibility. I'll give a KT about
what are the new features introduced in the selenium 4 version, I'll explain to my team
members, these are the new features introducing the selenium 4 version and from the next
project onwards we use this Selenium 4.0 for developing automation scripts, these are the
new features available. Any training, any meeting, any discussion about a domain, about a
technology, about a process can be called as a walkthrough.
Another example. Assume that in our company as of now we are recording the defects
in Excel sheet. Our management made a decision that hereafter we go with a bug reporting
tool like Jira. We bought the Jira tool. From here, our management made a decision, we use
Jira tool for our day-to-day Work Management. Now a senior person will give a training to the
team members like this we have to use a Jira tool, hereafter from next project onwards, we
use a Jira tool for managing our day-to-day job. These are how we have to make use of the
Jira tool. A small training is given. Any training, any meeting, any discussion about a
technology, about a process, about a domain comes under walkthroughs. Because
technology you know frequently updating. The senior people need to explore, training the
team, then make them ready for the work, that is the lead responsibility. Such kind of
discussion, such kind of meeting, such kind of trainings can be called as walkthroughs.
By giving KT,s by organizing reviews, we are trying to minimize the mistakes as many
as possible in development time testing all this comes under verification activity.

Walk through is nothing but explaining a product domain, explaining a

technology, explaining a process to the team is called generally walk through. See
let's deliver a statement like this, one of our team members said yesterday we had a walk
through on banking domain meaning a meeting organized, a discussion organized, a training
given about the banking domain to the team members that is called walkthrough.
Walkthroughs will help the team members to understand the domain better. If you
understand something in a better way, we don't do more mistakes.
Finally, what is the purpose of this entire verification? Whatever the work
whatever the work we are doing what is the final objective of doing
verification? To minimize the mistakes as many as possible. By doing some reviews
and walkthroughs, we try to minimize the mistakes.

Validation: (Dynamic Testing)

Developed code and developed application is working as expected or not is called
validation or Dynamic testing.

Dynamic testing carried out at four levels

1. Unit testing
2. Integration testing
3. System testing
 4. User acceptance testing
Unit Testing and Integration Testing are collectively called White Box Testing. System Testing
and User Acceptance Testing are collectively called as Black Box Testing. The mixture of White
and Black box testing is called Grey Box testing. The things inside the Grey box are completely
not hidden, completely not visible. If we mix Black and white colors, grey color will come.
Data Base Testing is the best example od Grey Box Testing.

White Box Testing:

Testing conducted on the source code by Developers to confirm the developed code to
is producing the correct output or not is called White Box Testing.

Unit Testing:
A smallest, separatable portion in the source code of the application such as
functions, procedures are called Program Units or Code Units. Each program unit will have
some business logic written inside it. No guarantee this code is working properly. To confirm
this, after implementing the code, programmer will run the code programmer and check
the developed code is producing the correct output or not(correct output is deleting cookies,
launching the app in the below example). Once the code is implemented, login functionality
for ex., is developed, programmer will run the code and check developer code working or
not which called unit testing.

Integration Testing:
Once, all units are independently tested, developer integrates all units together and
then check the overall output at code level is called integration testing.
The purpose of doing this code level testing to minimize the mistakes as many as
possible at code level. To minimize the mistakes as many as possible at code level, at least
one time, code needs to be run and tested by the development team. This is the goal behind
doing White Box testing.
This unit testing and integration testing are collectively called white box testing carried
out by the development team to ensure developer code is producing the correct output or
not. Code level testing is called white box testing. Why the name white box? As a
programmer doing testing on the code which is visible to them, clear to them the name given
as white box testing. If I write something in the Whiteboard, it will be visible to you. Hence,
the name is given as white boxes testing.

System Testing:
Once, the code is tested, white box testing done, code translated into executable
format of the application and application is given to testing team. Testers validate the
functional requirements and non-functional requirements on the finished or on
the developed system in a client’s point of view is called system testing.

User Acceptance Testing:

After the system testing, we deliver the product to the client. Any customer before
making a final payment, before giving a sign off, will have a check whether the delivered
application is ready to go for live business or not which is called User level acceptance
testing.
System testing and User acceptance testing are carried out on the
application in a customer business point of view without having the access to
the code, without seeing the code because we are doing testing at the
application level, not at code level. As we are not seeing what is the code
inside, as nothing is visible what is inside, the process named block box
testing.
 Right from the requirement reviews, till the user acceptance testing, these are the
various testing activities carried out. Requirements are verified by the BA, design verified by
the architect, code verified by the developer, code reviewed and tested(white box testing) by
the developer. Test Cases we(testers) are preparing, we'll have a check whether the prepared
test case are enough for testing the project or not ,that is our job test case, reviews is our job
And executing the planned test cases to conduct the system testing, to perform system
testing in effective manner, proper manner, first we plan what to test, how to test, document
them. They are called test cases. Verify test cases and approved test cases will be executed on
the system for doing system testing. Approved test cases will be executed to test the
system that is called system testing. Once system testing is done, to our knowledge
everything is fine, we give the project to the customer. The customer will have a final check
before accepting the product called user acceptance testing. In this entire discussion our job
is this system testing.
 System Testing
Validating functional requirements and non-functional requirements in an end user
point of view, not in technical direction is called system testing.
Checking all the functional requirements are working properly or not as per the end-
user requirement is called Functional Testing. Once functional testing is done, we need to
focus on validating non-functional requirements such as appearance, usability, security,
compatibility, load handling and performance. Validating functional and non-functional
requirements is our job.
System testing can be broadly classified into function testing and non-functional
testing. Non-functional testing includes UI testing, usability testing, security testing,
compatibility testing, load testing and performance testing.
In any real-time company, this is your job. For doing this functional testing and non-
function testing companies are hiring test engineers.

For any project given to you, at first you start from functional testing or
non-functional testing?
Ans. Functional testing. In any project, the first priority and high priority goes
to functional testing. Non-function testing order may change from project from project.
But any project first priority and high priority goes to functional testing. And 90 percent of
our time, we invest for doing functional testing. If 100 of hours is the estimated time for
doing the entire system testing, I will say 90 percent of our time we invest in doing
only function testing. UI, usability testing will not take much amount of time. In the non-
functional testing, load and performance testing will take little amount of time. Doing load
testing, doing performance testing will need some good amount of time. Checking the logo
properly visible or not, background color good or not, system easily understandable or not,
application properly visible across various browsers or not will not take much amount of
time. 90 percent of our time we have to invest, schedule for doing only functional testing
job. This is the reason you'll find more job openings for doing function testing either
manually or using a tool like selenium.
Selenium is a tool used for automating functional testing areas in a project. Using
selenium, you cannot do UI testing, usability testing, load and performance testing. To
automate load and performance testing, we have some tools like load runner, JMeter
whereas Selenium is a tool specially made for automating functional testing. Don't think
using one tool Selenium, we can do everything. Different applications made for different
purposes. Similarly, Selenium is a software made for only automating functional testing job
in the project. UI testing and usability testing any project we can do manually
there are no tools in the market for automating UI usability, Security and
Compatibility. Two types of testing can be automated. Functional testing job can be
automated, load and performance testing job can be automated. To automate load testing
and performance testing, we have some tools like Apache JMeter introduced by organization
called Apache software Foundation and load Runner. There are many other tools in the
market specially made for automating load and performance testing. Selenium, QTP, Tosca
tools are made for automating functional testing job. So, finally validating the functional
requirement and non-functional requirement, not in a technical direction, in an end user
point of view is called system testing. Here, the first priority and high priority goes to
functional testing.
As functional testing on non-functional testing is our job, we have to learn the
functional testing and Non-functional testing in a detailed manner let us focus on this.

Functional Testing:
Validating or checking all functionalities working properly or not is called functional
testing.

How generally the functional testing carried out in organizations?

In order to do effective functional testing or in order to do functional testing in a very
effective manner, we have to follow some methods some techniques called functional
testing types. These techniques are different ways of doing function testing.

Functional Testing Types: (Functional Testing Approach or methodologies or

procedures)
Smoke Testing and Sanity Testing:
There are many features to be tested in a project. Before we start testing all of the
features of the product in a very detailed manner first, we need to carry out smoke testing
or sanity testing.
Assume a new motherboard is manufactured. This motherboard will have lots of
components all are connected with some wiring. We need to test all functionalities of the
board working properly or not. So, what is the approach?
To test newly constructed motherboard functionalities, first we apply some power.
After applying the power, put it for observation for 5-10 minutes. Don't test it first. Observe
is there any smoke coming out. If any wrong connections are made, there is a chance of
getting of getting a smoke. The fuse may burst, the transistor may bust. After applying the
power rather than testing all of the features of the board one by one, indeed we will put it
for observation for 5-10 minutes. When no smoke coming, all connections are made
correctly, so it is in a testable position. Now we start testing all of the features one after
another. If there is any smoke coming, We don’t continue testing. Immediately, we remove
the power, rectify the issue, again we apply the power. Next 5 to 10 minutes put it for
observation, well no smoke coming, it is in a testable condition. Because of improper wiring
or improper connection, when there is some smoke coming, that board is not in a testable
condition. If it is testable, no smoke coming, then we continue further testing. If there is any
smoke, not any testable condition, we do not continue further testing.
Similar kind of test approach we have to follow for newly constructed applications
also. The first version of your project is created(new build). Many programmers made some
logic(code), integrated and the code compiled or converted into first version of the system
called version1 or build1. Any executable format of the code can be called as a build. Code
will be converted into that mobile APK or web application, that can be called as a build. The
first build you have received. So many features to be tested. Don't test immediately.
Generally, you know if you are testing a web application, There will a database server, there
will be one application server, your systems are accessing the code and data available in the
app server and database server. Lots of connections - database connections, app connections
are made. The first version created and given to us. Let's say there are about 100 features to
be tested. Before we start testing all 100 features of the product one by one, have a small
ruff check, first of all the given build( first bill ) is in a testable condition or not. So, what do I
mean by this? Supposing we are testing a banking product. Totally there are about 100
features to be tested, 10 days is a time schedule for QA for testing all 100 features. 10 days is
a time allotted for testing all hundred features of the product. At first, I started from the
home page functionalities. There are many links available in the header section and footer
section. one day of time we spent for testing the home page features. Second day, we have
tested login related, change pass related some other features. Like third day and 4th day are
over. 40 features already covered(tested) out of 100, four days finished. Fifth day I started
testing a functionality in the banking product called new customer registration. In the
banking application, there is a feature called new customer registration. If a customer
opening account in a bank, first she has to create the customer account, then deposit
withdrawals and other things are coming to the picture. There is some issue in the new
customer registration. When we enter all the details and click submit button, it is showing a
runtime error called connection time out or page cannot be displayed or something. Again, I
entered some data and click submit button, same error I am getting. I'm getting finally some
runtime error. This is a defect in new custom registration feature. The remaining features in
the banking product deposit functionality, withdrawal functionality, money transfer
functionality, online bills payment functionality. These are the remaining features need to be
tested. In the middle I encountered an issue customer registration functionality not working
the remaining functionalities - deposits, withdrawal, online money transfer, bills payment -
all are dependent to customer registration because for deposit functionality testing customer
account number is the first input. In which account you are depositing this amount, you
would want to make a withdrawal from which account you are withdrawing the amount like
money transfer online payment also. Here custom registration not working, when I
encounter this issue when I encounter this problem in the in the given scenario? fifth day.
Totally how much time given to you for testing this product? 10 days. Four days are over and
fifth day I encountered issue - new customer registration functionality not working, all
remaining features most of the remaining features are dependent to this customer
registration. What to do now? We report the problem to developer. Developer will take
some amount of time to resolve this work. Will we be able to continue further testing.
Deposits, withdrawal, online payment bills payment, online money transfer all are
dependent to customer registration. Because of this bug, until and unless this bug is rectified,
you cannot go further testing. Now you communicated to your team lead that the given
project is not in a testable position and remaining features we are not in a position to
continue further testing. You are reporting to your team lead after four or five days. If I'm the
lead my question to you is five days back application given to you for testing, after five days
you are saying there are many major issues, we cannot continue further testing. OK, they
give the modified version after bug fixes, again you have to start from the beginning. So,
meaning the four days of time whatever you spend is a waste for the organization. So, there
is a possibility, there is some risk like this, what is the professional way of doing testing?
Once you get the first version or second version or any new version for testing, don't
test it immediately in detail. Have a small ruff check or quick check where you verify all
major features are available or not, if all major features are available, now we make
decision that the build is in a testable condition. Make sure-Login functionality, customer
registration deposit, withdrawals, money transfer, online bills payment, all the critical areas
of the product( important features of the product) are working as expected. So, first have a
small ruff check that all major functionalities are available are not in the given project to
continue further testing. To make a decision whether the application is in a
testable condition or not, have a small quick check to confirm whether all
major features are available( working ) or not, the given application is
consistently operatable or not to make a decision whether to continue
further testing or reject the build back to the development team. Whenever
you receive a bill1 or Bill 2 or build3 or buils20 whatever, have a small
raff check in order to make addition first of all whether the given
application eligible to continue further testing or not. Definitely every build
will have some issues. Will you expect a bill from the development team with no bugs?
Definitely every application will have some bugs. But if these bugs are Show stoppers, until
and unless these blocks are rectified, we cannot do further testing, we can immediately
reject the build back to development team saying that there are many major issues so
given application not in a testable condition, we cannot continue further testing, look into
the issue. If all major features are available, I make decision that the build is testable. Now I
start continuing further testing.
I had a small check whether all basic functionalities are available in the given
application or not to make decision whether the given project is in a testable condition or
not. This kind of rough test or a quick test carried out on the given application to make a
decision whether it is in a testable position or not is called Smoke testing also called sanity
testing.

What is the objective behind doing smoke testing?

The purpose of doing this smoke testing or sanity testing is not to find out the bugs
because we are not testing anything in detail. smoke testing or sanity testing objective is not
finding the bugs. smoke testing and sanity testing are carried out on the given project to
make a decision that first of all whether it is in a testable condition or not eligible to
continue further in detail testing or not.
In the admin module of a Banking project, suppose new branch creation,
modification, deletion, new user creation, modification, deletion, new role
creation, modification, deletion, new employee creation, modification, deletion
are working properly. But the change password functionality is not working
correctly. It is giving a runtime error. After performing smoke testing(quick
check) on the admin module and finding the bug in Change Password
functionality, cam we continue further testing or reject the build back to the
developer?
 The objective of this smoke testing and sanity testing is either accepting the build to
continue for the testing or rejecting the build back to the development team saying that
given system is not in a testable condition. There are two outcomes of doing smoke testing
or sanity testing - accepting the application and continuing further in detail testing or
rejecting the bill back to the development team saying that given application not in a
testable position.
In the admin module, only Change Password functionality isn’t working properly.
Remaining functionalities are working properly. For every minor issue, if we say to the
developer that the given application is not in a testable condition, we can’t continue
testing because every build will have bugs. For this reason, we are testing the build. Don’t
expect a bug free product from the developer. Definitely every build will have bugs. If The
bugs you have encountered during the smoke testing or sanity testing, if the problems
what you have encountered are the Show Stoppers, if until unless they rectified, they
cannot go further testing, there is no option we have to reject the bill back to the
development team. In the above case, we accept the admin build, we have to test all the
features one by one in detail but we communicate the change password problem to the
developer and we continue testing remaining functionalities because remaining all are
available. Supposing when I click branches it is not responding, when I click employees, there
is a runtime error coming, change password there is a runtime error coming. If there are
many issues, now you feel it's a waste of my time continuing for the testing. In that
scenario, we can reject. For one or two problems, for a very minor issue we should not
reject the build. In this scenario, a login as administrator. If The login is not working, it is a
showstopper bug. A Show Stopper bug is a bug until and unless the problem is rectified, we
can’t continue further testing.
So, Smoke testing or Sanity testing is a kind of a small rough test or small quick test carried
out on the given project to make a decision whether it is in a testable condition or not. The
objective of smoke testing or sanity testing is not finding the bugs but to make a decision first
of all whether the given build – build1 or build2 or build3, whatever - whenever you receive
an application from the developer, in order to continue further testing, first we make a small
ruff check whether this application is eligible to continue for further testing or not. Such a
small check is called Smoke testing or sanity testing.
Smoke Testing or Sanity Testing Definition:
Smoke Testing is a kind of a quick test or ruff test carried out on the given application
or project to decide whether it is in a testable condition or not.
In smoke or Sanity Testing, we only perform positive testing. We don’t perform
negative testing. For example, in case new branch creation functionality, to perform quick
check, we input some the basic details, click submit button. Am I able to create new branch
or not. New branch creation functionality available or not. We don’t focus on the conditions
such as the number of characters a branch name text box accepts. We don’t test the
functionality with different inputs. We only check New branch creation functionality
available or not. We just fill the basic details and click the submit button. If it results in a
runtime error, we reject the build back to the developer saying the build is not in a testable
condition because branch creation functionality is a very critical functionality.
In Smoke or Sanity testing, we only check whether the basic functionalities are
available(properly working) or not.
Smoke testing is a type of quick test carried out on the given project to determine
whether it is in a testable condition or not. It is a preliminary check to ensure that the basic
functionalities of the application are working as expected before proceeding with further
testing. The necessity of smoke testing lies in its ability to identify critical issues early in the
development process.

Difference between Smoke Testing and Sanity Testing:

 Beginning builds(buils1, build2, build3, ...) are fresh builds. They are just constructed
builds. They are unstable builds. In the beginning versions, we face many issues.
Windows 1, 1.1, 1.2 ---> Unstable Builds
Windows 9, 10, 11 ---> Stable Builds
In the very beginning builds - because just now program has created, first time the
code converted into one application( build1). Many programs are converted into first time as
first build(build1). There may be many issues in the very beginning versions(unstable builds) .
In the very beginning builds which are unstable builds, if you hide a small check whether
the build1 or build2 or built3 is in a testable condition or not it is called Smoke testing. Why
the name smoke testing here? In the Beginning versions, there are chances of failure, smoke
may come like the electronics example(motherboard example). In the later versions - build21
build22, build23 - meaning build21 meaning 20 builds already tested. Maybe at this point of
time, almost system will be stable. 20 times already tested if there are many bugs they will
be rectified by this time. The later versions like Build20, build21, build23, you had a small
check build21 is in a testable condition or not, build22 given to us is in a testable condition
or not. Such approach is called sanity testing relative at the end of the development life
cycle on the very stable builds is called sanity testing.
There's not much difference between smoke testing and Sanity testing. Approach is
same - quick check, objective is same - whether the first build or second build or build21 or
build22 or whatever, they are in a testable condition or not. Approach is same, purpose is
same but in the very beginning builds almost chances of getting a smoke, failures the
terminology we use as smoke testing. On the later version, almost at the end of the
development life cycle, fully stable version because 20 to 30 times already they have tested,
such testing approach is called sanity testing.
If we perform a quick test on the very beginning versions(unstable versions) it is
called Smoke testing and when we perform a quick test on the later versions(fully stable
versions) before we continue further testing, it is called Sanity testing.
See build21 given to me. Already many times the system was tested, bugs are
reported, they resolve the bugs, give the next build, next build, next build, next build. Every
build, we have tested, retested. Almost at this time(build21), some new features are added,
next version created, some new features are added, next version created. But 20 times
already tested, build is fully stable and almost no chance of getting a smoke. Initial stage of
a motherboard may be lot of mistakes in the soldering or wiring. Many times, motherboard
tested, now you are adding a new component, almost you don't get a chance of a smoke. If
we perform quick test on stable builds, it is called Sanity testing.

Can we automate Smoke and Sanity Testing?

Any work if you feel difficulty in doing it manually, then only we think about going
for automation. It can be any job, not only smoke and Sanity testing, any job if you feel
difficulty in doing it manually, then we go for automation. If we are working on a big size
project, we develop some script to verify all basic features are available or not. We can go for
automation. If we are working on a small project, the smoke testing and sanity testing, we
will do manually. Finally, we can do it manually and you can also automate this process.
When if I am working on a small project, I do this job manually when I'm working on a
bigger project, I'll write some code to automate it.
Build: An executable format of the application is called a Build.

Smoke Testing:
If a quick test carried out on the beginning versions(unstable versions) to confirm
whether they were in a testable condition or not is called smoke testing.
Sanity Testing:
If the quick test carried out on the later versions(stable versions) to confirm whether
they were eligible to continue for further testing or not is called smoke testing.
Objective of smoke or sanity is to make a decision whether the given build is eligible to
continue for further testing or not, not to find out bugs.
Formal Testing and Informal Testing(Ad hoc Testing):
Formal Testing:
If we test a software application by following proper testing procedures and
proper documentation( like writing scenario, writing test cases, neatly we have to
document what to test, neatly we document how to test, then test ), it is called formal
testing.
It is the systematic way of doing testing. We follow certain process, certain
documentation to test the application.
If big companies, while testing a project inside a company, you don’t apply our own
procedures or methodologies. The company management define a process about how we
have to carry out testing.
1. first understand the requirement,
2. neatly document what to be tested(writing scenarios),
3. neatly document how to test each and every scenario(writing test cases,
4. submit to your next level(senior person) for the scenarios review,
5. once the scenarios are reviewed and approved and once the test case are verified
approved, then only we start executing the test cases,
6. If you find a bug, neatly we have to document the bug(defect report),
7. Send to the development team,
8. then retesting, regression testing many activities like this.
If really testing carried out by following this process with proper documentation it is called
Formal Testing.
let's say you joined with a very startup company who are not following any process
because they are dealing small local projects for forty thousand or eighty thousand or one
lakh of rupees. They are developing small websites. Do you think they will follow a
systematic process in development and testing? NO. May be the management knows the
importance of the process, but their budget, their resources and their infrastructure will not
permit to follow the process. Infosys company - big infrastructure company - they deal big
clients; they charge in crores for the services. They follow a systematic method. Startup
organizations who are dealing small local projects like online bus booking mobile app, a small
gaming application, a small Supermarket billing software, do you think they will follow any
process. No, in this scenario how this small software company people will do? they develop
the product, they test the product. But they do not follow any standard, they do not follow
any procedures and proper documentation but they also doing software business. If you test
a software application by following a certain process, proper documentation than it is called
formal testing. If you test as you wish then it is called ad hoc testing informal testing.
Organized way of doing the testing, the systematic way of doing testing is called formal
testing. Like understanding the requirements, writing test scenarios, writing test cases,
executing test cases, if you really follow such process, it is called formal testing. You test as
you wish, no documentation nothing, then it is called ad hoc testing. I understand the
product, no scenarios, no test cases but directly you start testing your product that is called
ad hoc testing(informal testing).
In big companies, very process-oriented organizations, you see formal testing. In
startup companies, you see ad hoc testing.

Software Testing Life Cycle(STLC) is all about is all about formal testing.

Ad hoc Testing(Informal Testing):

If we test a software application without following proper process and
documentation, it is called Ad hoc Testing.
In this type of testing, we test as we wish because process demands lots of time and
effort. If you really want to follow a process, documentation, time required and budget is
required. We are getting a small amount from the client, following this kind of process not
practically possible. They skip the process but they develop the product, they test the
product.
Retesting:
Developer change the code in 3 situations.
1. To fix the bugs
2. To add new requirements
3. To modify existing features
To resolve the bugs, to add new requirements , to modify existing features code need to
be updated by the developer. After changing the code, developer communicate back to you
that the build is ready. There is no guaranteed that code is properly changed or the changed
code may introduce side effects. As a tester, we should not take a chance because QA team
is responsible and accountable for the quality not the developer. So, as a tester, we need to
have a recheck the reported bug is correctly rectified or not, new functionalities that are
added are properly working or not and the modified existing functionalities are working
properly or not.
So, Whenever there a code change implemented by the developer, we need to test the
functionality whether the functionalities are properly working or not. This is called Retesting.
Testing a functionality in the modified build to make sure the modifications and Bug fixes
are made properly or not is called Retesting.
Retesting is the testing carried out on a modified version to make sure modifications or
bug fixes made properly or not, newly added functionalities are working properly or not.

Regression Testing:
To resolve the bugs, to add new requirements , to modify existing features code need to
be updated by the developer. This code change may introduce some side effects. We need to
identify the functionalities affected by the code change. We need to retest those affected
functionalities.
Testing various functionalities in the modified version where there is a chance of getting
side effect because of the code changes is called Regression testing.
While testing functionalities in the modified version, regression testing will not come
into the picture in the first build. From build2, something was modified. These modifications
are made properly or not need to be tested. What kind of modifications we reported a bulb
developer resolved it communicated
Whenever you receive a modified version, before performing Retesting and Regression
testing, first we need to have the clarity why this modified version created. i.e.,
1. We need to know what are the functionalities in which bugs are identified and fixed,
2. We need to know what are the are the existing features that are modified because of
client asking some changes in existing features,
3. We need to know what are the new functionalities added to the build.
 Without knowing the above three, we will not be able to identify the functionalities for
retesting and we can’t identify the other features which are connected to this modified area
for regression testing.
So, after testing a modified area ( retesting ), identify the other features which are
connected to this modified area. Those features need to be once again tested for the
confirmation sake. This approach is called regression testing.
Whenever you receive the modified version, first you need to get the information from the
developer development team why this modified version created.
The Retesting is carried out on a modified version to make sure modifications, bug
fixes are made properly or not. The Regression testing is carried out on the modified version
to identify the side effects which may occur due to these code changes.
The objective of doing retesting to ensure modifications are first of all correctly made
or not. The objective of doing regression testing to identify the side effect which may occur
because of this code changes.
The retesting and Regression testing are the continuously carried out, repetitively
carried out testing activities on a maintenance project or agile model projects. Whenever a
new version created, next version created, something need to be retested, its connected
functionalities need to be regression tested. In every build, modified areas need to be tested
and its connected areas need to be again tested. Instead of doing this retesting and
regression testing manually every time, it is preferred to go for automation because every
time doing retesting and regression testing with manual effort demands lot of time and
effort, increase my project costing. To minimize that, your management may plan to go for
automating retesting and regression testing areas in a product. Automaton will not take
much amount of time. Test development will take lot of time test execution will not take
much amount of time.
For the products where there are frequently changes are happening, every updated version
need to be retested and regression tested, instead of doing this retesting and regression
testing manually every time, we go for automation. The major idea behind going for
automation is to automate retesting and regression testing areas in a product. So,
you tell me if we are doing some job only one time or rarely, will you think about automating
it? Any work, not only testing work, if we are doing this work rarely ah one or two times not
very repetitively, we don’t think about automating the job, we do it manually. Every day or
every week, I'm doing same work then there is an option for automation, again that is your
decision whether to automate or doing it manually.

Automation is not mandatory, it is optional. But in some scenarios,

automation testing will help us to speed up our testing job. To speed up the testing, job we
can go for automation. Every week, every 10 days, a new person getting created, many
features need to be retested, doing these retesting manually every week demands lots of
time and effort and increase my project budget, increase the time. In this scenario, your
management think about going for automation.
 If my project is a school management system, one-time development, one-time
testing, give the project to school and the story is over. No need to automate anything here.
When I am working on an agile model project, every week, every 10 days some updated
version is getting created and every updated version need to be again tested. Instead of
doing this testing manually every time, we go for automation.
Remember, everything cannot be automated. When there is a chance to automate,
we automate. When there is no chance to automate, we go manual. Finally, a tester should
have the clarity on both manual testing and also automation testing skill. A doctor should
know about the human body (Conceptual Clarity). Also how to use a stethoscope, how to use
Xray machine, how to use CT Scan tool. Both are required. Tester should have the clarity on
the conceptual Clarity(Manual Testing) first and also using some tools(MS Word, Jira,
Selenium, Extent Reports, etc.) to speed up the job. that is a perfect skill set required for a
good tester.

There are a few steps involved in Regression Testing. They are

1. List out the functionalities in which bugs are identified and sixed, the functionalities
which are newly added to the build, the existing functionalities which are modified,
2. We need to identify the other features which are connected to the modified
functionalities,
3. Those features need to be retested again for confirmation shake.

In the modified version, no need to test everything again. We test the feature in which
bug is identified and fixed. And we also test the features which are connected to the modified
feature. In other words, only modified areas and its connected areas need to be tested
again.
Note: After informing developer about the bug, she takes some time to resolve the bug.
Meanwhile, as a tester, we don’t sit idle. We test remaining features.
System Integration Testing:
Checking the integration scenarios between two or more applications involved in the
business is called system integration testing.
Integration testing is done by the developer at code level. System integration testing is
done by the tester at the application level.
Ex1:

Integration Scenarios:
• Check a new employee registered in payroll application is getting recognized is
getting recognized by the biometric device or not.
• Check attendance recorded in the biometric system is automatically getting
updated in payroll database or not.

These kinds of integration scenarios working properly or not need to be verified.

Ex2:
We can able to withdraw amount from ICICI ATM machine even if we have account in
SBI bank. How ICICI ATM machine recognising SBI account? as per the RBI guidelines all Bank
servers data is integrated and maintained in a data server. Actually, it is called Data
warehousing concept (ETL concept). Maybe SBI banking server software may be different.
Assume that they are using SQL Server. ICICI Bank using Oracle database. Some other bank
using some other database. A software made in such a way that it will extract the data from
all the different servers available in different formats, formulate the data in the unique format
and maintain in a server. They are actually called Third party data centres (extracting,
transforming and loading into unique format – ETL). All banks data available in one more
third-party data server. Now let's say you have a balance of 10,000 rupees in our account. You
went to ATM machine and withdrawn thousand rupees of amount in ICICI Bank ATM
machine. This will be reflected in your SBI account server. There is some integration between
the ATM software and SBI banking software. This kind of integration part correctly working or
not need to be tested. You made a deposit into your account by going to the bank. You come
to ATM machine and generate a mini statement. The thousand rupees will be reflected here.
Ex3:
 We go to some grocery store supermarket; we buy some rice or some other material.
The person will put on a weighing machine and it is showing 2 kgs. Is this person entering the
2 kgs and price in the building system. What is happening? Automatically, it is reading the
data from the weighing mission and updating the data into the POS machine (the billing
software). How it is happening? Did You observe or not properly, that billing system will have
lots of connections, many wires will be there. The weighing machine which is electronic
device, connected to the computer system. There is a small program designed which read the
data from the weighing machine, supply the same data to the billing software. This program
is correctly functioning or not need to be tested - the integration between the weighing
Mission and billing software.
Finally, In now a days business applications, two or more applications involved
in the business. This integration part working properly or not need to be verified .
End – to – End Testing:
For the last three months, we are testing one product - some application. These two
people involved in testing module1, the other two people involved in testing module2, the
other two members involved in testing module3. For the last two three months 10 builds are
tested by our team members. Now my team member said to me here I'm the lead so in the
10th build all requirements are Justified, working properly. These people involved in testing
only module1, these two people involved in testing only module2, the two people involved in
testing only module3. These two people have the clarity only on Modern1, these two people
have the clarity only on module2, they have the clarity only on module3. Team Lead will have
the clarity on all and my team member said to me everything is fine, we can release the
product. I'll not take a chance. I will check all major business scenarios from beginning to
end i.e., from starting to end all major business scenarios in a very precise manner not in a
deep manner to make a decision whether to stop testing or not. Smoke testing objective is
to make a decision whether to start continue further testing or not. End to end testing can be
called as a overall testing. A senior person perform an overall check to make a decision
whether to stop testing or not. This approach is called overall testing - from beginning to
all, check all major business scenarios in a very precise manner to make a decision whether
to stop testing or not is called end-to-end testing or overall testing. Who will do this testing?
Preferably team lead who has the clarity on the entire requirements to make a decision
whether to stop testing or not.
Testing the overall functionalities of the system in a very precise manner to
make a decision whether to stop testing or not is called end-to-end testing is
called end-to-end testing.

Again, team lead don't test everything in deep. Testers have tested in deep. Just to
build the confidence, Team Lead will perform a small overall check that is called end to end
testing.
Exploratory Testing: ( Exploring --> Understanding --> Testing )
Exploring the application ( We browse the product that is called exploring the
application), understanding its requirements then testing it is called exploratory testing.
This exploratory testing comes in to the picture in the following two situations:
1. If requirement documents are not available,
2. Requirement documents are available but not providing proper inputs because they
are not properly documented. By studying the requirement documents, we are not
understanding the product properly. We keep them aside and directly we explore the
product and start testing it. Such kind of testing approach is called exploratory testing.
Explanation:
Any product / project we are testing, first we need to understand the requirements of
the product. If requirements are properly documented, by analysing the requirement
documents, we gain the knowledge of the product. Based on the knowledge that we have
gained from the requirement documents, we plan what to test, how to test and then we test
it. This is the formal process – a systematic way of doing testing.
If we asked to test a product for which requirement documents are not available or
requirement documents are available but are not properly documented – They aren’t
providing the proper inputs, by referring the requirement documents, we aren’t gaining the
complete knowledge about the product – How we proceed testing this product in this
situation?
Without having / gaining the knowledge about the product, nobody can test it. First,
we need to gain the knowledge about the application. In this scenario, we can gain the
knowledge about the product only by exploring the product. Exploring means browsing the
product. By browsing / exploring the product, we gain some knowledge about the product.
With this knowledge, we plan what to test, how to test and then we test it. This kind of
testing approach is called Exploratory testing.

Is it a suggested method? No. We are trying to understand the product by referring the
developed application, by exploring the already made product. As per the client requirement,
there are 10 menus required. Our developer implemented only 9 menus. One option missed
by the developer but we do not come to know about it because we are exploring the
developed product to understand it. Whatever we see we assume they are the
requirements because we don't have a requirement separately. It's not really a preferred
approach. When the requirement documents not present, this is the only optional left. Such
kind of testing approach is called exploratory testing. it's informal testing approach or ad hoc
testing approach. Any work carried out in a very procedural way is called formal. When a
work carried out not following the defined procedure then it is called informal. This is not
suggested method because we are understanding the product by referring the developed
product. While development, the developer may made some mistakes. We will not come to
know about them. We assume whatever we see in the application are the requirements.
The actual requirements may be are different. So, it is not a suggested mechanism but when
the requirement documents are not present, this is the only option left in to gain the
knowledge about the product. Small companies with low budget projects don't follow proper
documentation. Generally, by exploring the product we start testing it.

Monkey Testing:
Intentionally performing uneven operations or zigzag operations with an intention of
making the system fail is called Monkey Testing. Uneven operations means invalid data,
wrong operations, etc.
Almost Monkey Testing is a negative kind of testing because we are trying to make the
system fail. In negative testing, we try to prove that the system is doing what it is not
supposed to do.
Explanation:
In order to test some product, we have created some test cases say 100 test case are
prepared to validate various features of the product. As a manager or a leader, I estimated -
I have a team of four members - how much time required for executing this test cases. Eight
days of time needed. Now I plan working this way mostly. I asked my team members first
eight days you complete the test case execution. First eight days you execute all these 100
test cases. Last two days, you test as you wish. In addition to formal testing, after executing
the test cases, I may ask my team members last two days you test as you wish. Intentionally
perform some random actions or zigzag actions or uneven actions with an intention of
making the system fail. If you are really doing such kind of testing, there is a possibility of
finding some hidden or tricky defects. For extra testing nothing will go wrong. If the time
permits, budget permits, you can plan some extra testing activities where there is a chance of
finding some tricky bugs. Formal testing give the confidence that no risk in releasing the
product because to test all these 40 requirements, my team members plan what to test, how
to test properly documented, a senior person verified, approved yes if these 100-test case are
executed successfully and pass, 40 requirements are Justified. To ensure the 100
requirements coverage, to get the confidence that no risk in releasing the product to the
client, formal methodologies are suggested. In addition to this formal testing, you plan some
little amount of time for doing some random testing (ad hoc testing). It is also an ad hoc
testing - test like a monkey. Random testing, zigzag testing, uneven testing, jumpy testing are
the other names for monkey testing. So, generally when we are doing a formal testing
supposing there is employee registration form. First, we enter employee number, employee
name, designation, salary, date of birth, date of joining in a very systematic way we input the
details and click submit button to verify the functionality working properly or not. Sometimes
after entering the employee number, when I press Escape i.e., after entering the employee
number without containing the remaining when I do some unwanted action, there is a
possibility the program may enter into the loop and may not come out. Finally, there is a
possibility of finding some hidden, tricky defects when we are doing random testing. That is
called monkey. Testing just like a monkey - the intention is we are trying to identify few more
of defects. In addition to formal testing, it is suggested where there is a chance of identifying
few more hidden effects. Generally, in industry, I said eight days of time is enough for
executing the trust cases. I plan the work for 10 days, I ask my team members that first 8 days
you complete the planned test cases and last two days you test as you wish, try to find out
some more issues. Such kind of testing approach is called monkey testing or random testing
or Jumpy testing which is again ad hoc testing.
Exploratory testing and monkey testing comes under ad hoc testing because they are
not planned procedures.
Note: exploratory testing and monkey testing comes under comes under ad hoc testing.
Note: ****************************************************************
Let's assume we are working on some ERP (Enterprise Resource Planning) project - sap
Erp kind of application. Sales activities, finance activities, accounts activities, marketing,
production planning, Human Resource Management, all departments to computerize - to
automate the complete activities of a manufacturing organization are ERP application is
designed. The target audience for Erp products are manufacturing companies such as Cement
factories, Sugar Factory pharmaceutical company, etc.
Say we are working on some Erp project, some changes made to purchase order
functionality. What is this purchase order? In a Manufacturing Company, production
Department need some raw material to make the product. These people will not go to the
market and buy the material. These people will raise a Indian to inventory stores
Department. The stores Department people will check the stocks available or not. If available
dispatch, not available, raise a purchase order. The vendors give the quotation, the purchase
department will place a purchase order. Again, is the purchase order, they supply the material
to the company, Finance people will make a payment. That's the process - a simple life cycle I
have discussed. Say you are working on such kind of application, some modifications made at
purchase order. Some changes made to the existing purchase order functionality. What are
the other features need to be tested? We have to determine what are the other areas
connected to the purchase order. So, as a tester we need to find out what are the other
features connected to this purchase order and those features need to be once again tested.
It is called education testing. You answer me what are the other functionalities related to
purchase order in a Erp product? Without having the Erp domain knowledge nobody can
say. Without having this technical or domain knowledge we cannot identify the regression
testing area. Domain knowledge is mandate to find out the regression testing areas. Without
having the knowledge about the product domain, we cannot able to identify what are the
other areas may get affected because of the changes made here. Domain experience
domain, knowledge is mandate for identifying regression testing areas.
Companies are hiring experienced people because of the domain knowledge.
Supposing my new project (new client) is a Erp client or project. If I'm the project manager, I'll
ask my HR people that I need at least one person who has 5 to 8 days of experience in testing
and also previous working on ERP domain, at least one project on Erp domain. I need another
3 - 4 people who has 3 plus years of experience in testing (manual & selenium). In addition to
that, this person should have previous knowledge about previous projects Erp domain. One
person 5 – 8 years of experience, maybe 2 - 3 people 3 plus years of experience, remaining all
6 people are freshers. That 5 – 8 years of experience person I'll put him as a lead. 3 people
senior members, other four or five people, six people junior level people because these
Juniors do not know about the Erp domain. the 3 plus years of experienced people know
about the Erp domain because three years they worked. They'll be having sufficient
knowledge about the product domain. That 5 or 8 of experienced person can able to manage
a teamwork work collocation, work coordination, guiding and training everything. This will be
my plan for a new project if I need 10 people. If I hire all experienced people, all 10 people 3
plus years of experience, my cost, my budget will not permit because each person's salary
will be about eight lakhs or nine lakhs or ten lakhs. If I hire all freshers project will go. Finally,
any project is a combination of high-level resources middle level resources, junior
level resources.

I repeat today we received the modified version and I am the senior person working in
this team or I am the team lead for this project. I don't let all my team members you decide
the regression testing areas. First, I'll get a confirmation from the development team what
are the modifications made in this question They said A and B are modified. As I have
experience in testing and also experience in the product domain, I identify what are the other
features connected to A and what are the other features connected to B, I make a list, I
document them. Now I allocate over to my team members you do this, you do this. Every
junior level resource cannot able to identify regression testing areas correctly. This is the
job of the senior person to identify the regression testing areas, document them. In the
second build these 4 features need to be once again tested, documented them. Ask the
people to test. I can ask Junior person now you test these four features. I identified what are
the other areas may get affected, listed, now I ask my team member you tested this. This is
a practical process inside the company. So finally, some domain knowledge is mandate for
identifying the regression testing areas in a project. The people who are planning for
experience, if you are giving three plus years of experience, in addition to this testing
subject what we are learning, you have to decide what kind of projects we have to
highlight on the resume. Definitely you are going to put up some 2 - 3 projects in your
resume. You have to decide the projects which are in the demand in the market - Erp
applications, e-commerce domain, banking, Insurance, Finance, Retail. This is a happening
business in the industry - the big business, billion trillion dollars of business in a day. ICICI
Bank doing billions of dollars of a business in a day which is international brand, they invest
some portion of the amount for technology i.e., in these hundred dollars we have to invest
ten dollars for the Technology support. That is their budget planning. They keep on investing
the amount for the technology. The big companies will have a budget planning - in these
hundred dollars, we have to invest 10 percent of the budget for Technology support, ten
percent of the budget for advertising or marketing something like this. Here they give
continuous input to the software companies. Bigger organizations will take such kind of
projects where they get continuous investment, I mean continues amount from the clients.
School manager, School owner if you say above one lakh is the project cost, they will say I'll
maintain 200 Pages notebook. They will not put the investment for much technology. But
banking business needs a Technology support, Finance business needs a Technology support,
e-commerce business must need a technology. They invest the amount for the technology
because only technology run their business. You need to list out what are the hot domains in
the market, that is happening business in the market - Finance business is happening,
banking business, e-commerce business, Erp business, retail business. You select two projects
from any one of these domains. Let us say decide two projects. Whatever you decided you
need to gain some knowledge about the product domain. In Internet, there are many
applications available - Amazon is e-commerce domain, Flipkart is an e-commerce, any e-
commerce application will looks in the same fashion or if you Google, you'll get some
documentation about e-commerce domain - what is e-commerce domain, some requirement
documents for e-commerce domain you'll get something, you've decided banking project
what is banking domain, what are the models of banking, what are the detailed requirements
of the banking, you'll get many documents. Whatever the projects you decided, you Google
you get some documentation. If you give interview, maybe the interviewer will ask you will
you explain about your current project or will you explain about your current project domain.
You should able to demonstrate for about five minutes what is your project, what are the
modules available, what are the requirements something like this. most other people will
fail here. They copy some projects from other resume and paste and go to interview and they
will fail. School management system, Hospital management system will not work out. You
have to put a good project like Erp bromine project, e-commerce demand project, then only
your resume will be filtered. I said previously the scenario clearly when I am giving if I am a
project manager, I am giving the requirement to my HR team I need 10 people for this new
client, new project. In this one person or four people should have previous working
knowledge on e-commerce domain. I clearly mentioned. So, what HR people will do? They go
to naukri.com, they filter the profiles that contain Erp domain project in their resume. Only
such people interview will be scheduled because project manager clearly said I need four
people who have previous working experience in e-commerce domain. According to this
requirement only HR people will search and schedule the interviews. So, e-commerce, Erp,
banking, Finance is the happening business, you try to put up the projects related to these
domains. This is a winning mechanism rather than blindly putting some school management
system and going to an interview. Going to enter is not important, cracking the job is
important.

****************************************************************************