5) Agile process: • It is having multiple sub models like adaptive, Scrum, iterative model etc…The

model which we are going to use is scrum model. • It is an iterative and incremental model. Scrum
model is having the below activities. a. Scrum master b. User stories c. Scrum meeting/scrum
calls/DSM d. Sprint plan e. Sprint meeting f. Backlogs a. Scrum master: The scrum master is, who is
going to lead the project. The project manager or the client will acts as a scrum master. Scrum
master is responsible for scrum meetings and sprint meetings. b. User stories: The requirements will
be captured in the form of end user used flows (end user used ways). Hence we will call it as User
stories. BA is responsible to collect c. Scrum meeting: ➢ On daily basis all the team members will
participate in a quick meeting where they will describe what activities were performed yesterday and
what tasks are planned to perform today and is there any challenges. ➢ All the team members
including the scrum master and client have to describe. ➢ The main purpose of the scrum meeting is
to track the resources and also to maintain the transparency. d. Sprint plan: ➢ Sprint is fixed time
period can be one week/two weeks/three weeks etc. It will be decided by the scrum master. ➢
Sprint plan is, to collect user stories, analyze, develop, test and deliver to the client. ➢ During the
sprint if we are unable to complete any of the requirements the sprint won’t be extended. And the
pending requirements should be carried to the next sprint. Sprint is a fixed time period e. Sprint
meeting: Once the sprint is completed the next sprint plan will be decided under the sprint meeting.
They will discuss, if the current sprint is delivered successfully or not, is there any challenges faced. f.
Backlogs: During the sprint plan if any user stories are unable to accomplish, those will be taken as
Backlogs. These backlogs have to be completed in the next sprint. It is of two types, (i) Product
Backlog (ii) Sprint backlog Product Backlog: The Requirements (user stories) which we are going to
collect, develop, test and deliver it to the client as a part of sprint plan is known as product backlogs.
Sprint Backlog: The Requirements which are not completed as part of the sprint plan will be treated
as sprint backlog. Advantages: ➢ Each and every sprint will be tested multiple times by the testing
team and client, so we can ensure for quality. ➢ All the phases in SDLC are performed parallel y so
we can save time and cost. ➢ The requirement change can be accepted at any stage of the project
(even after delivery of sprint). ➢ Risk can be identified at the early stage and it can be prevented ➢
We can maintain transparency of the project. ➢ The client will also participate in scrum meetings, so
we can get the information very quickly. ➢ Each and every sprint is delivered to the client so we
doesn’t have delivery risk. ➢ We can gain the customer satisfaction by delivering all the sprints to
the client. ➢ Sprint is also known as iterative. Its and iterative and incremental model Disadvantages:
Maintaining all the sprint related information is a very challenging task, but we can overcome with
the help of test management tools like Scrum wise, Quality center, JIRA and test link etc. Functional
testing types (or) Black box testing types: 1) Smoke testing: ➢ Once the build is developed and
deployed it in any environment then the initial testing will be performed, that is known as smoke
testing. Initially the development team will deploy the build in development environment, and
perform smoke test. They will check each and every module related field is properly navigating their
pages or not and checks the main functionality of the application. The objective of smoke test is to
check whether the build is ready for further testing or not. The developer will concentrate on white
box testing ➢ If all these fields are properly navigating to the related pages then they will conclude
that smoke test is passed. 2) Sanity testing: ➢ Once the build is deployed in the test environment,
the testing team will perform the smoke test in test environment. It is known as sanity testing. ➢ In
sanity test the testing team will perform at least one round of the main flow functionality and check
whether its properly working or not. ➢ If sanity test is passed then the testing team will execute all
the test cases if it fails they will reject the build to the development team. Ex for Main flow: Create
an account in Gmail and login into that account and compose email and send it to one valid email
and check that whether it is properly delivered or not. Note: Once the sanity test is performed the
testing team (test lead) has to send an email with sanity test results to the development team. 3) Pre
SRN testing: SRN - Software Release Notes ➢ It contains the build status like, number of modules
available in the build for testing. ➢ Number of modules which are under development. ➢ Number
of stubs and drivers are available in the build. ➢ Number of bugs which are fixed and available in the
build. ➢ Number of bugs which are under development ➢ Deployment guidelines etc.. the SRN
document contains ➢ Before releasing the SRN document along with the build to the testing team,
the testing team will perform the smoke test in development environment. ➢ It is known as pre SRN
testing, it is also known as Build acceptance testing (BAT) or Build verification testing (BVT). Note:
Once the build is released to the testing team, the test engg's will review the SRN doc to know the
build status (what build contains). Then the testing will perform sanity test. 4) GUI/UI Testing:
Graphical user interface/user interface testing.The below five activities will be tested in GUI. ➢ Check
the spellings of all the fields. ➢ Check the font of all the fields where it should maintain the
consistency. ➢ Check the color and alignments of all the fields it should maintain the consistency. ➢
Check the overall look and feel of the page 5) Regression testing: Performing testing on already
tested functionalities on the iterative and incremental builds is known as ‘Regression Testing’. It will
be performed in two ways: ➢ Whenever any bug is identified it will be reported to the developer,
the developer will fix it then he will releasing the fixed bug in the form of new build(Build2) to the
testing team. The test engineer will test again, to check whether the bug is really fixed or not. ➢ The
test cases which are passed on the old build will be executed again on the new build and check that
whether these are working same as previous or not. Testing already tested functionalities is
regression testing. Testing the new functionalities is not the regression testing. It comes under test
case execution. Note: If any code update is there, then that new code may affect the existing code, so
we are performing the regression testing. 6) Retesting: ➢ Perform testing on the same functionalities
again and again with multiple sets of different test data on the same build is known as ‘Retesting’. ➢
Executing the failed test cases on the iterative and incremental builds is also known as “Re testing”.
Test data: The data which the testing team is using for testing is known as “Test data”. Ex: 1. Test the
login functionality of Gmail with multiple sets of different credentials. 2. Test the spicejet one way
search with the multiple sets of different origins and different passengers. Q: What is the difference
between Regression Testing and Retesting Q: What is the difference between Regression Testing and
integration Level Testing 7) End to End Testing: The test engineer has to identify all the end user used
scenarios of the application, and check that whether the End to End Scenarios are properly working
or not By performing End To End testing we can achieve Integration level testing Ex: The end to end
scenario for Gmail. 8) Compatibility Testing: ➢ Test whether the application is working same as
expected in all the targeted environments or not is known as ‘compatibility testing’. Environment is
combination of OS, Browser, Server, DB etc. ➢ Compatibility testing is two types ‘cross browser
testing’ and ‘cross platform testing’. ➢ Test whether the web application is working as expected in all
the targeted browsers like firefox, safari, google chrome, IE etc. is known as ‘cross browser testing’.
➢ Test whether the desktop application is working as expected in different platforms or operating
systems like windows, LINUX, MAC, Solaris etc. is known as ‘cross platform testing’. Ex for Cross
browser testing: Test whether the spicejet is working in the below environments or not. Windows –
Internet explorer, Firefox, Google chrome, Safari, Opera Linux - Internet explorer, Firefox, Google
chrome, Safari, Opera MAC - Firefox, Google chrome, Safari, Opera Ex for Cross platform testing: Test
whether the skype is working in the below platforms or environments Windows Linux MAC and
Mobile Note: Whenever we are performing compatibility testing we need to concentrate more on
GUI of the application