This document provides an overview of software development lifecycles and testing. It discusses the typical phases of the SDLC, including planning, analysis, design, implementation, and maintenance. It describes two common SDLC methodologies: the waterfall model and agile/scrum model. It also defines different types of testing like static vs dynamic, verification vs validation, functional testing, regression testing, and smoke testing. Finally, it provides details on unit, integration, system, and user acceptance testing.

1. QA Analyst Training
reference document
A COMPLETE GUIDE TO SOFTWARE TESTING
DINESH POKHREL

2. MODULE: 1-09/07/2016
 What is Software development life cycle
 Phases of SDLC
 Various Documentation done in each phase of SDLC
 Architecture of Software
 Models of SDLC-Waterfall, Agile and Agile Scrum

3. A- SDLC - Overview
 SDLC, Software Development Life Cycle is a process used by software industry to
design, develop and test high quality softwares. The SDLC aims to produce a high
quality software that meets or exceeds customer expectations, reaches completion
within times and cost estimates.
 SDLC is the acronym of Software Development Life Cycle.
 It is also called as Software development process.
 The software development life cycle (SDLC) is a framework defining tasks
performed at each step in the software development process.

4. What is SDLC?
 SDLC is a process followed for a
software project, within a software
organization. It consists of a detailed
plan describing how to develop,
maintain, replace and alter or enhance
specific software. The life cycle defines
a methodology for improving the
quality of software and the overall
development process.
 The following figure is a graphical
representation of the various stages of
a typical SDLC.

5. Stage 1: Planning
 The objective of phase 1 is to conduct a preliminary analysis, propose alternative
solutions, describe costs and benefits and submit a preliminary plan with
recommendations.
 This is done by IT Planner, Directors, Software Architects etc.

6. Stage 2: Systems analysis, requirements definition
 Defines project goals into defined functions and operation of the intended application. It is the process
of gathering and interpreting facts, diagnosing problems and recommending improvements to the
system. Analyzes end-user information needs and also removes any inconsistencies and incompleteness
in these requirements.
 This is done by Business Analyst or Business system Analyst or Quality Assurance Professionals or
technical writer in companies.
 The requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done through
.SRS. . Software Requirement Specification document which consists of all the product requirements to
be designed and developed during the project life cycle.
 Business Requirement Specification or BRS, System Requirement Specification or SRS, Business
Requirement Document or BRD are different document names used for Requirement document in the
market.

7. Stage 3: Design
 Based on the requirements specified in SRS, usually more than one design approach for the product architecture
is proposed and documented in a DDS - Design Document Specification.
 A design approach clearly defines all the architectural modules of the product along with its communication and
data flow representation with the external and third party modules (if any). The internal design of all the modules
of the proposed architecture should be clearly defined with the minutest of the details in DDS.
 Functional Design Document or FDD, Design Document Specification or DDS or Functional Document are
commonly used name for design document in the companies.
 This document is prepared by Senior Developer, Architect, software architect or software engineers.

8. Stage 4: Implementation
 This consists of Coding , Testing & Deployment of the software testing life cycle.
Coding – Software is written using different programming languages. Integration of software
to do testing is done during coding phase. Coding is done by Developers.
Testing: All integrated modules are tested and defects re reported for fix using Requirements.
Testing is Done by QA Analyst, testers, software testers, software test engineers.
Deployments: Final mode of application to go live for real users.
Deployment is done by Developers, networking engineers and system analysts, support
analyst. Depends on company to company.

9. Stage 5: Maintenance
 During the maintenance stage of the SDLC, the system is assessed to ensure it
does not become obsolete. This is also where changes are made to initial software.
It involves continuous evaluation of the system in terms of its performance.
 Maintenance is handled by support teams. But it depends on company to
company process. Sometimes its maintained by Developers or system analysts.

10. Software Development Methodologies
1. Waterfall Methodology
2. Agile Methodology (Scrum)
3. Spiral Methodology
4. V Model
5. Big Bang Model
6. Iterative Model

11. 1. Waterfall Methodology
This methodology is mostly used by all companies. The waterfall model is a sequential
development approach, in which development is seen as flowing steadily downwards (like
a waterfall) through several phases, typically:
1. Requirements analysis resulting in a software requirements specification
2. Software design
3. Implementation
4. Testing
5. Integration, if there are multiple subsystems
6. Deployment (or Installation)
7. Maintenance

12. 2. Agile (Scrum) Methodology
 Agile SDLC model is a combination of iterative and
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of working software product.
 Agile Methods break the product into small
incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about
one to three weeks. Every iteration involves cross
functional teams working simultaneously on various
areas like planning, requirements analysis, design,
coding, unit testing, and acceptance testing.
 This is used in most of the companies to release
software faster.

13. MODULE: 2- 09/08/2016
Testing types ?
 Static Testing, Dynamic Testing
 Verifications and Validations
 Functional Testing
 Regression Testing, Retesting, Smoke Testing, ad-Hoc Testing
 Unit Testing, Integration Testing, System Testing, UAT,
 Alpha Testing, Beta Testing,
 White Box and Black box testing
 Non-functional Testing
 Performance Testing
 Load Testing
 Stress Testing
 GUI Testing
 What are the Different Environments in IT ?

14. Static Testing, Dynamic Testing
 Static Testing:
 Example of static testing is verification:
 static testing is an important testing technique that takes the form of Business requirement review, Functional requirement review,
design reviews, code walkthroughs and test documentation review. It is a continuous activity and not done just by testers.
 Static Testing : It is the process of testing the application code(and/or related documents) with out running it, it can be code review,
walk through etc.
 Dynamic Testing:
 Example of Dynamic testing is Validation.
 The dynamic testing part is more hands on and happens on the product itself and not on an artifact or a representation of the
product. A much formal process of test case/condition identification, coverage considerations, execution and defect reporting all
mark the dynamic testing methods.
 Dynamic Testing : It is the process of testing the application/code by running it. (ie black box testing).

15. Verification & Validation Differences
 Validation: Are we building the right system?
validation is concerned with checking that the system will meet the customer’s actual needs. Evaluates the final product
to check whether it meets the business needs. It determines whether the software is fit for use and satisfy the business
need. Checks “Are we building the right product”? Is done with executing the software. Includes all the dynamic testing
techniques.
 Example includes all types of testing like smoke, regression, functional, systems and UAT
 Verification: Are we building the system right?
verification is concerned with whether the system is well-engineered, error-free, and so on. Verification will help to
determine whether the software is of high quality, but it will not ensure that the system is useful. valuates the
intermediary products to check whether it meets the specific requirements of the particular phase. Checks whether the
product is built as per the specified requirement and design specification. Checks “Involves all the Are we building the
product right”? This is done without executing the software. static testing techniques
> Examples includes reviews, inspection and walkthrough

16. Functional Testing
 Functional testing verifies that each function of the software application operates
in conformance with the requirement specification. This testing mainly involves
black box testing and it is not concerned about the source code of the application.
Each and every functionality of the system is tested by providing appropriate
input, verifying the output and comparing the actual results with the expected
results. This testing involves checking of User Interface, APIs, Database, security,
client/ server applications and functionality of the Application Under Test. The
testing can be done either manually or using automation
 Example of functional testing: login functionality, Register, Forget Password etc.

17. Regression Testing
 Regression testing is a type of software testing that verifies that software previously
developed and tested still performs correctly after it was changed or interfaced with
other software. Changes may include software enhancements, patches, configuration
changes, Defect Fixes etc.
 EG: You have running Skype Voice call application. You want to integrate new
functionality on skype with Video call abilities. Now the Regression testing will be done
on the voice call functions to make sure the video call functionality will not impact the
already running voice call feature of the application.
 Most of the Regression testing are encouraged to do automated (Automation testing)
to save time and money.
 This testing is done both ways> Automated or Manual

18. Retesting, Smoke testing
 Re-testing: Re-testing is something we have to test after and after for validation
purpose. Example: Once defect is fixed we need to re-test the defects to make sure
failing function/operation passes. If first time re-test fails we again need to re-test after
second fix. Retesting is done to make sure that bug is fixed and failed functionality is
working fine or not, This is kind of verification method followed in testing field for the
fixed bugs.
 Smoke Testing: Smoke Testing is to make sure all most important(Critical)
functionalities are working as expected after developed.
These test cases are executed prior to start actual testing to
check critical functionalities of the program is working fine. This set of test cases
written such a way that all functionality is verified but not in deep. The objective is not to
perform exhaustive testing

19. Sanity Testing
 After receiving a software build, with minor changes in code, or functionality,
Sanity testing is performed to ascertain that the bugs have been fixed and
no further issues are introduced due to these changes. The goal is to
determine that the proposed functionality works roughly as expected. If sanity
test fails, the build is rejected to save the time and costs involved in a more
rigorous testing.
The objective is "not" to verify thoroughly the new functionality, but to
determine that the developer has applied some rationality (sanity) while
producing the software. For instance, if your scientific calculator gives the result of
2 + 2 =5! Then, there is no point testing the advanced functionalities like sin 30 +
cos 50.

20. Smoke Testing VS Sanity Testing
Smoke Testing Sanity Testing
Smoke Testing is performed to confirm that the critical functionalities of the
program is working fine
Sanity Testing is done to check the new functionality / bugs have been fixed
The objective of this testing is to verify the "stability" of the system in order to
proceed with more rigorous testing
The objective of the testing is to verify the "rationality" of the system in order to
proceed with more rigorous testing
This testing is performed by the developers or testers Sanity testing is usually performed by testers
Smoke testing is usually documented or scripted Sanity testing is usually not documented and is unscripted
Smoke testing is a subset of Regression testing Sanity testing is a subset of Acceptance testing
Smoke testing exercises the entire system from end to end Sanity testing exercises only the particular component of the entire system
Smoke testing is like General Health Check Up Sanity Testing is like specialized health check up

21. AD-Hoc Testing
 Adhoc testing is an informal testing type with an aim to break the system. This
testing is usually an unplanned activity . It does not follow any test design
techniques to create test cases. In fact is does not create test cases altogether!
This testing is primarily performed if the knowledge of testers in the system under
test is very high. Testers randomly test the application without any test cases or
any business requirement document.
 Adhoc Testing does not follow any structured way of testing and it is randomly
done on any part of application. Main aim of this testing is to find defects by
random checking. Adhoc testing can be achieved with the testing technique
called Error Guessing. Error guessing can be done by the people having enough
experience on the system to "guess" the most likely source of errors.

22. Unit Testing, Integration Testing, System
Testing, UAT,(Testing Levels)
 Unit testing: Unit testing of software applications is done during the development (coding) of an application. The
objective of unit testing is to isolate a section of code and verify its correctness. In procedural programming a unit
may be an individual function or procedure. The goal of unit testing is to isolate each part of the program and show
that the individual parts are correct. Unit testing is usually performed by the developer.
 Integration Testing: Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase
in software testing in which individual software modules are combined and tested as a group. It occurs after
unit testing and before validation testing.
 System Testing: In the world of software testing, system testing is the testing of a complete and fully integrated
software product. Usually software is only one element of a larger computer based system. Ultimately, software is
interfaced with other software/hardware systems. System testing is actually a series of different tests whose
sole purpose is to exercise the full computer based system. System testing falls under the black box testing
category of software testing. White box testing is the testing of the internal workings or code of a software
application. In contrast, black box or system testing is the opposite. System testing involves the external workings of
the software from the user's perspective.
 UAT: UAT = User Acceptance Testing: This testing is done after Unit, Integration, System testing. This testing is
done by real application users to make sure system meet business requirement.

23. Alpha Testing, Beta Testing,
Alpha Testing: This is done before product goes live by client or real users to meet their expectations.. Alpha testing
performed by Testers who are usually internal employees of the organization. Alpha Testing performed at developer's
site. Reliability and security testing are not performed in-depth Alpha Testing. Alpha testing involves both the white box
and black box techniques
 Alpha testing requires lab environment or testing environment. Long execution cycle may be required for Alpha
testing. Critical issues or fixes can be addressed by developers immediately in Alpha testing. Alpha testing is to
ensure the quality of the product before moving to Beta testing. Beta testing: This testing is done with a some group
of real users in production environment to meet their requirement expectations.
Beta Testing:
 Beta testing is performed by Clients or End Users who are not employees of the organization. Beta testing is
performed at client location or end user of the product
Reliability, Security, Robustness are checked during Beta Testing. Beta Testing typically uses black box testing. Beta
testing doesn't require any lab environment or testing environment. Software is made available to the public and is said
to be real time environment. Only few weeks of execution are required for Beta testing. Most of the issues or feedback is
collected from Beta testing will be implemented in future versions of the product. Beta testing also concentrates on
quality of the product, but gathers users input on the product and ensures that the product is ready for real time users.

24. MODULE: 2- 09/09/2016- Day 3
 Module two continued from day 2.
 White Box and Black box testing
 Non-functional Testing
 Performance Testing
 Load Testing
 Stress Testing
 GUI Testing
 What are the Different Environments in IT ?

25. White Box and Black box testing-1
 White Box Testing: is a method of testing software that tests internal structures or
workings of an application, as opposed to its functionality. White-box testing is a method
of testing the application at the level of the source code.
 White box testing technique is used in below levels:
 Unit testing. White-box testing is done during unit testing to ensure that the code is working as
intended, before any integration happens with previously tested code.
 Integration testing. White-box testing at this level are written to test the interactions of each
interface with each other.
 Regression testing. White-box testing during regression testing is the use of recycled white-box
test cases at the unit and integration testing le

26. White Box and Black box testing-2
 Black Box Testing: Black-box testing is a method of software testing that examines the functionality of
an application without peering into its internal structures or workings. This method of test can be
applied to virtually every level of software testing: unit, integration, system and acceptance.
 Specific knowledge of the application's code/internal structure and programming knowledge in general
is not required. The tester is aware of what the software is supposed to do but is not aware of how it
does it.
 Test cases are built around specifications and requirements, i.e., what the application is supposed to do.
Test cases are generally derived from external descriptions of the software, including specifications,
requirements and design parameters. Although the tests used are primarily functional in nature, non-
functional tests may also be used. The test designer selects both valid and invalid inputs and
determines the correct output,

27. Non-functional Testing-checks how system
operates
 Non-functional testing is the testing of a software application or system for its non-functional
requirements: the way a system operates, rather than specific behaviors of that system.
 Non-functional testing includes:
 Baseline testing, Compliance testing
 Documentation testing, Endurance testing
 Load testing, Localization testing and Internationalization testing
 Performance testing, Recovery testing
 Resilience testing, Security testing
 Scalability testing, Stress testing
 Usability testing, Volume testing

28. Performance Testing
 Performance testing, a non-functional testing technique performed to determine
the system parameters in terms of responsiveness and stability under various
workload. Performance testing measures the quality attributes of the system, such
as scalability, reliability and resource usage.
 This includes below levels of testing.
 Load testing - It is the simplest form of testing conducted to understand the behavior
of the system under a specific load. Load testing will result in measuring important
business critical transactions and load on the database, application server, etc., are also
monitored.
 Stress testing - It is performed to find the upper limit capacity of the system and also
to determine how the system performs if the current load goes well above the expected
maximum.

29. Graphical USER Interface (GUI Testing)-1
 GUI Testing is to test look and feel of the application. GUI testing involves checking the screens with the controls like menus, buttons, icons, and
all types of bars - toolbar, menu bar, dialog boxes and windows, etc.
 What do you Check in GUI Testing?
 The following checklist will ensure detailed GUI Testing.
 Check all the GUI elements for size, position, width, length and acceptance of characters or numbers. For instance, you must be able to provide inputs to
the input fields.
 Check you can execute the intended functionality of the application using the GUI
 Check Error Messages are displayed correctly
 Check for Clear demarcation of different sections on screen
 Check Font used in application is readable
 Check the alignment of the text is proper
 Check the Color of the font and warning messages is aesthetically pleasing
 Check that the images have good clarity
 Check that the images are properly aligned
 Check the positioning of GUI elements for different screen resolution.

30. Graphical USER Interface (GUI Testing)-2
GUI Testing Techniques:
Manual Testing
Using Automated script (Record & Play) Using Automation tools. Example QTP, Selenium etc.
GUI Automation Tools
Following are some of the open source GUI automation tools in the market:
Product Licensed Under URL
AutoHotkey GPL http://www.autohotkey.com/
Selenium Apache http://docs.seleniumhq.org/
Sikuli MIT http://sikuli.org
Robot Framework Apache www.robotframework.org
Watir BSD http://www.watir.com/
Dojo Toolkit BSD http://dojotoolkit.org/

31. What are the Different Environments in IT ?
 Development – Developer uses this environment to code the application.
 Dev.safeway.com> Development env.
 QA Environment – Used to test the applications
 Test.safeway.com
 Production Environment- Used by real time users. It is live system out there in the market.
 Safeway.com
First Developer develops the code in dev environment & Does the unit testing. Then code is integrated in development
environment & Copied over to QA for testing.
After complete testing sign off the code is deployed to production live environment. If they found any issues in QA during
testing developer will fix the code in Dev environment & Validate the unit testing of the defect and if it pass move it to
QA as a fix, assigns to tester for re-test. Tester tests it and if it pass gives sign off. Then they plan to do deployment in
production live environment.
> Deployments are done in a minimal planned time to eliminate the system downtime.

32. Module 4- Day 4- 09/10/2016
 STLC(Software Testing Life cycle)
 Test Plan
 Test design
 Test data
 Test Data Techniques
 Test cases
 RTM(Requirement traceability matrix)
 Test closures/Defect Reports
 Defect life cycle
 Test metrics
 Status reporting

33. STLC(Software Testing Life cycle)-1
 Software Testing Life Cycle refers to a testing process which has specific steps to be executed in a definite sequence to ensure that the quality goals have been
met. In STLC process, each activity is carried out in a planned and systematic way. Each phase has different goals and deliverables. Different organizations have
different phases in STLC; however the basis remains the same.
Below are the phases of STLC:
 Requirements phase: During this phase of STLC, analyze and study the requirements. Have brain storming sessions with other teams and try to find out
whether the requirements are testable or not.
 Planning Phase : In practical scenarios, Test planning is the first step of the testing process. In this phase we identify the activities and resources which would
help to meet the testing objectives.
 Analysis phase: This STLC phase defines “WHAT” to be tested. We basically identify the test conditions through the requirements document, product risks and
other test basis. The test condition should be traceable back to the requirement. There are various factors which effect the identification of test conditions:
– Levels and depth of testing
– Complexity of the product
– Product and project risks
– Software development life cycle involved.
– Test management
– Skills and knowledge of the team.
– Availability of the stakeholders.
 Design Phase: This phase defines “HOW” to test. This phase involves the following tasks:
– Detail the test condition. Break down the test conditions into multiple sub conditions to increase coverage.
– Identify and get the test data
– Identify and set up the test environment.
– Create the requirement traceability metrics
– Create the test coverage metrics.

34. STLC(Software Testing Life cycle)-2
 Software Testing Life Cycle refers to a testing process which has specific steps to be executed in a definite sequence to ensure that the
quality goals have been met. In STLC process, each activity is carried out in a planned and systematic way. Each phase has different goals
and deliverables. Different organizations have different phases in STLC; however the basis remains the same.
Below are the phases of STLC:
 Requirements phase, Planning Phase , Analysis phase, Design Phase
 Implementation Phase: The major task in this STLC phase is of creation of the detailed test cases. Prioritize the test cases also identify
which test case will become part of the regression suite. Before finalizing the test case, It is important to carry out the review to ensure the
correctness of the test cases. Also don’t forget to take the sign off of the test cases before actual execution starts. If your project involves
automation, identify the candidate test cases for automation and proceed for scripting the test cases. Don’t forget to review them!
 Execution Phase: As the name suggests, this is the Software Testing Life Cycle phase where the actual execution takes place. But before you
start your execution, make sure that your entry criterion is met. Execute the test cases, log defects in case of any discrepancy. Simultaneously
fill your traceability metrics to track your progress.
 Conclusion Phase: This STLC phase concentrates on the exit criteria and reporting. Depending on your project and stakeholders choice, you
can decide on reporting whether you want to send out a daily report of weekly report etc.
 Closure Phase: Tasks for the closure activities include the following: Check for the completion of the test. Whether all the test cases are
executed or mitigated deliberately. Check there are no severity 1 defects opened.
– Do lessons learnt meeting and create lessons learnt document.( Include what went well, where are the scope of improvements and what
can be improved)

35. Test Plan
 Test Plan: A Test Plan is a document describing the scope, approach, resources,
and schedule of intended testing activities. It identifies test items, the features to
be tested, the testing tasks and who will do each task (roles and responsibilities)
and any risks and its solutions. Test Plan is a dynamic document. The success of
a testing project depends on a well written test plan document that is current at
all times. Test Plan is more or less like a blue print of how the testing activity is
going to take place in a project.
 Test Plan template is attached below.

36. Test design
 Test Design means creating test cases based on test plan. Basically test design is
the act of creating and writing test suites for testing a software. Test analysis and
identifying test conditions gives us a generic idea for testing which covers quite a
large range of possibilities. But when we come to make a test case we need to be
very specific. In fact now we need the exact and detailed specific input. But just
having some values to input to the system is not a test, if you don’t know what the
system is supposed to do with the inputs, you will not be able to tell that whether
your test has passed or failed.

37. Test Data and Test Cases-1
 Test Cases: A Test Case is a document that describes step by step process how to test the application. A Test Case includes
Test Case ID, Steps Description, Expected Output, Actual Output, Pass/Fail, Remarks.
 Test Case Sample document is attached below.
 What document did you refer to write the Test Cases?
 Requirement document. (NOTE: It can also be Use Cases, or Design Document)(Note: It depends company to company. In
some companies, they use Cases. In some companies, they use Requirement Documents and in some companies, they use
Design Document. However, in practical scenario, most of the companies have requirement document at least).
Test Data: Test data is data which has been specifically identified for use in tests, typically of a computer program.
Some data may be used in a confirmatory way, typically to verify that a given set of input to a given function produces some
expected result. Test data is actually the input given to a software program. It represents data that affects or is affected by the
execution of the specific module. Some data may be used for positive testing, typically to verify that a given set of input to a given
function produces an expected result. Other data may be used for negative testing to test the ability of the program to
handle unusual, extreme, exceptional, or unexpected input

38. Test Data Generation Techniques
 What is Test Data Generation? Why test data should be created before test execution?
 Depending on your testing environment you may need to CREATE Test Data (Most of the times)or at least identify a
suitable test data for your test cases (is the test data is already created).
 Typically test data is created in-sync with the test case it is intended to be used for.
 Test Data can be Generated -
 Manually
 Mass copy of data from production to testing environment
 Mass copy of test data from legacy client systems
 Automated Test Data Generation Tools
Test Data Generation Techniques:
 Manually create data
 Copy data from production stores
 Get data from other vendors/tolls.

39. RTM(Requirement traceability matrix)
 RTM(Requirement traceability matrix): Is a document which is created to make
sure test cases are covered for each requirements. It maps test cases against
requirement. It makes sure testing got 100% requirement coverage. Tractability
matrix is used to cross check the test cases as per the requirement of the test
cases. In other words, it checks whether the each functionality is covered in the
Test Cases as per requirement document. (We create RTM using Quality Center
tool)
RTM template document is attached below.

40. Test closures/Defect Reports
 Test closure is a document which gives the information's about the testing status
before completing the testing process. This document consists of:
1)Total no of test cases
2)Total no of bugs found
3)Total no of bugs fixed
4)Total no of bugs not fixed
5)Total no of bugs rejected
 Test Closure template is attached. TBD

41. Defect life cycle
 Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle,
which a defect goes through during its lifetime. It varies from organization to
organization and also from project to project as it is governed by the software
testing process and also depends upon the tools used.
 All New, Assign etc. are status of defect given when we open a defect.
Defect Life Cycle States:
 New - Potential defect that is raised and yet to be validated.
 Assigned - Assigned against a development team to address it but not yet
resolved.
 Active/Open - The Defect is being addressed by the developer and investigation is
under progress. At this stage there are two possible outcomes; viz - Deferred or
Rejected.
 Test- The Defect is fixed and ready for testing.
 Verified - The Defect that is retested and the test has been verified by QA.
 Closed - The final state of the defect that can be closed after the QA retesting or
can be closed if the defect is duplicate or considered as NOT a defect.
 Reopened - When the defect is NOT fixed, QA reopens/reactivates the defect.
 Deferred - When a defect cannot be addressed in that particular cycle it is deferred
to future release.

42. Test metrics and Status reporting
 Test Metrics are used to do test status report to the development/management/business team or stake holders.
 Below are different types of reporting done during and after test execution. It is not 100% same across the companies but it is somehow
used by each and every companies.
 Below are mostly used test metrics to do reporting.
 Test case execution productivity metrics
 Test case preparation productivity metrics
 Defect metrics
 Defects by priority
 Defects by severity
 Defect slippage ratio
 Test Execution report weekly
 Test Execution report Daily
 Defect Fix report
 New Defect report

43. Status reporting
 Test lead will do the status reporting of testing. It can be done everyday or weekly
depends on the company requirements.
Status report is sent to manager/team members on what’s going on in the project
testing. Writing effective status report is as important as the actual work you did!
How to write a effective status report of your weekly work at the end of each week?
 Here I am going to give some tips. Weekly report is important to track the important
project issues, accomplishments of the projects, pending work and milestone
analysis. Even using these reports you can track the team performance to some extent.
From this report prepare future actionable items according to the priorities and make
the list of next weeks actionable
 Attached is sample Weekly testing status report.

44. Module 5- Quality Center | HP ALM ? Test
Management Tool- 09/11/2016
Quality Center | HP ALM ? Test Management Tool
 Creating Release
 Creating the requirements
 Writing the test cases
 Mapping the test cases and requirements
 Mapping the test cases and Test Lab
 Test execution
 Defect Reporting

45. ALM= Application Lifecycle Management
 ALM = Application Lifecycle Management
 Vendor = HP
 Older Versions: Mercury QC (Quality center).
 IT is used to manage defect/project management.
 Modules?
 Management, Requirements, Testing & Defects are four main modules used in ALM.
 http://alm.abc.com.com.com/qcbin/start_a.jsp
 If you click on the link the login screen looks like showing in right screenshot. It has login NAME= Ususally your company user id, Password: Company
password, Domain: It will get assigned to you by manager based on what domain you work.
 Project depends on what project you work. It will be given, or assigned to you by Manger/Lead.
History of QC
Quality Center was formerly known as Test Director, a product of mercury interactive. The below table provides us a better insights about the version history of
QC.
S.No# Commercial Name Version Numbers Owned By
1. Test Director v1.52 to v8.0 Mercury Interactive
2. Quality Center v8.0 to v9.0 Mercury Interactive
3. Quality Center v9.2 to v10.0 Hp
4. ALM v11.0 to v11.5x Hp

46. ALM- Release
 ALM Release module is first step in Project creation
in alm. Releases
 Creating releases is the first step in Quality Center. All
the work item such as libraries, test execution and
defects are tracked based on the release. Before
creating a release, one can create a container/folder
for the same by clicking on a new folder icon as
shown below.
 RELEASES Menu is available under Management
Menu of ALM. Before creating test cases,
requirements, defects, we need to create release &
Under release we need to create Milestones (Testing
timelines) & Cycles. Based on planned Release,
Milestones, Cycles test cases preparation, execution,
defect reporting and testing sign off is done.

47. ALM- Creating the requirements
 In order to do Requirement traceability with Test
cases we need to create requirements manually in
ALM Using Requirements Tab. We can map any
requirements to any test cycle-test cases from Test
Plan tab.
 Requirements are filled and written in ALM
Requirements tab.
 The Requirements module enables users to define,
manage and track requirements at all stages of the
software lifecycle. The following are the key
functionalities in requirements module and click on
each link to know about that particular module.
 Under requirement tab we have to create each line
of requirements and details of it is mapped with
the created test case to do 100% requirement
coverage.

48. ALM- Writing the test cases
 In ALM we write test cases under Testing> Test Plan Module.
 We can create folder for each project & Based on the requirement we can create test cases
in ALM. Usually Test case has below option to fill in manually in ALM. We also can upload
test cases written in Microsoft Excel format to ALM.
 Test Plan
 The crucial step in testing any application is developing a clear and a precise test plan. A
good test plan enables the team to assess the quality of the application under test at any
point in the software development life cycle.
 Following functionalities are very important in order to understand in the test plan module
better. Click on each one of the functionalities to know more about it.
Functionality Description
 Creating Tests This module describes how to create folders of test subjects in the test
plan tree and also to add tests.
 Uploading Tests Uploading Tests using ALM-MS Excel Add-ins
 Requirement and Test Coverage Enables how to define the relationship between the
requirements and tests.
 Test Configuration Specifies the subset of data or a run-time environment that the
test should use.

49. Mapping the test cases in Test Set of test
lab.
 In order to execute test cases ( Run
the test cases in ALM) We need to
use Test Lab module. Under this
module we need to create Test set
exactly same as in the requirement.
It makes sure it covers all
requirements we have during the
testing. After the test set is created
we need to add or assign test cases
from test plan module. We need to
assign test case based on what kind
of testing we are doing and what is
needed.
Attached screen shows the menu to
do the test case assignment.

50. Defect Reporting
 In ALM All defects found under one release or multiple
release of same project are created under Defect Module.
During test execution, when expected result does not match
with actual result, a defect should be logged. Now Let us
focus various functionalities associated with defects.
Navigate to defects Tab in Quality Center and Click on "New
Defects".
 Fill in the mandatory parameters such as defect summary,
detected by, Severity and Description.
 Once a defect is posted, the same be accessed in Defects
Tab as shown below.
 f the defects are logged during the test execution the step
and description would be auto populated from test case
where as If a defect is logged by clicking on "New Defect" in
defect module the steps, description and summary needs to
be entered manually by the user.
 Many a times testers will NOT be in a position to enter all
field values in "New Defect" Window. Instead they can make
use of "Set Default Values" Option. It can be accessed from
"New Defect" Window as shown below.

51. ALM- Reports
 There are multiple types of
reports ALM can automatically
generate based on what you
need. Below are some
examples.
 Defect report
 Test Execution report
 All reports can be generated
using analysis menu for each
modules and tabs.

52. MODULE-6 –SQL-09/11/2016
 SQL (Structured Query Language)
 · Keys, DDL and DML statements
 · SQL Having Clause
 · Group by clause
 · Aggregate functions
 · SQL Joins
 Oracle, DB2, MySQL & MS SQL Server
 Interview questions on SQL

53. SQL- Structured Query Language
 SQL Stands for Structured Query language. It is used in most of the Relational database systems to query/get data results from
database.
 What is Database???
a structured set of data held in a computer, especially one that is accessible in various ways. Data is saved in tables in the form of Row &
Columns.
 What are the different type of database applications?
Relational Databases
 This is the most common of all the different types of databases. In this, the data in a relational database is stored in various data
tables. Each table has a key field which is used to connect it to other tables. Hence all the tables are related to each other through
several key fields. These databases are extensively used in various industries and will be the one you are most likely to come across
when working in IT.
Different database management clients?
 Oracle
 MySQL
 Microsoft SQL Server
 IBM DB2
 Microsoft access
 Mongo DB
All Database mentioned above saves data in structured way. If someone wants to get data they have to write sql query to get the results.
EG> Select * From schemaname.table_name where column_name = “Data Value”;

54. Database components
 Database client/management systems like DB2, Oracle, SQL
Server, MY SQL are installed in a server with specific memory &
Hard drive on it.
 When we install client no database are created during installation
of client.
 We can create database on the client not on the server. Client like
MYSQL, BDR, Oracle, SQL Server etc. can be used to create
database, schema, table names, column names & Insert, delete or
update the data (IN ROWS).
 SQL Language is used to create, update, drop, delete, insert the
data in database management systems. Most of the applications
in now a days has database in backend to sync & Save data for
user life.
 E.g.. When you do google search, google has backend database
which saves all of your search details in database and they use
that data to some other functional purpose in google search.

55. SQL: COMMANDS
 There are 3 different types of SQL commands
1. Data Definition Language (DDL)
2. Data Manipulation Language (DML)
3. Data Control Language (DCL)
Comma nd Descrip tion
CREATE Crea tesa new ta b le, a v iew of a ta b le, or other ob ject in d a ta b a se
ALTER M od ifiesa n existing d a ta b a se ob ject, such a sa ta b le.
DROP Deletesa n entire ta b le, a v iew of a ta b le or other ob ject in the d a ta b a se.
Command Desc ription
SELECT Retriev es c ertain rec ords from one or more tables
INSERT Creates a rec ord
UPDATE Modifies rec ords
DELETE Deletes rec ords
Command Desc ription
GRANT Giv es a priv ilege to user
REVOKE Takes bac k priv ileges granted from user
Data Definition Language- DDL
Data Manipulation Language- DML
Data Control Language - DCL

56. SQL - Syntax- (SQL Query)
 SQL AND/OR Clause:
SELECT column1, column2....columnN
FROM table_name
WHERE CONDITION-1 {AND|OR} CONDITION-
2;
 SQL IN Clause:
SELECT column1, column2....columnN
FROM table_name
WHERE column_name IN (val-1, val-2,...val-N);
 SQL BETWEEN Clause:
SELECT column1, column2....columnN
FROM table_name
WHERE column_name BETWEEN val-1 AND
val-2;
 SQL SELECT Statement: select the
data from columns
SELECT column1, column2....columnN
FROM table_name;
 SQL DISTINCT Clause: Select all
non
duplacte type of data.
SELECT DISTINCT column1,
column2....columnN
FROM table_name;
 SQL WHERE Clause: Conditional
data
SELECT column1, column2....columnN
FROM table_name
WHERE CONDITION;
 SQL LIKE Clause:
SELECT column1, column2....columnN
FROM table_name
WHERE column_name LIKE { PATTERN };
 SQL ORDER BY Clause:
SELECT column1, column2....columnN
FROM table_name
WHERE CONDITION
ORDER BY column_name {ASC|DESC};
 SQL GROUP BY Clause:
SELECT SUM(column_name)
FROM table_name
WHERE CONDITION
GROUP BY column_name;
 SQL COUNT Clause:
SELECT COUNT(column_name)
FROM table_name
WHERE CONDITION;

57. SQL - Syntax- (SQL Query)-2
 SQL HAVING Clause:
SELECT SUM(column_name)
FROM table_name
WHERE CONDITION
GROUP BY column_name
HAVING (arithematic function condition);
 SQL CREATE TABLE Statement:
create TABLE CUSTOMER_ID (name
VARCHAR(20), Address VARCHAR(90),
PHONE_NUMBER VARCHAR(20), sex
CHAR(1), birth DATE, death DATE);
SQL DROP TABLE Statement:
Drop table pet;
SQL CREATE INDEX Statement :
CREATE UNIQUE INDEX index_name
ON table_name ( column1,
column2,...columnN);
 SQL DROP INDEX Statement :
ALTER TABLE table_name
DROP INDEX index_name;
 SQL DESC Statement :
DESC table_name;
 SQL TRUNCATE TABLE Statement:
TRUNCATE TABLE table_name;
 SQL ALTER TABLE Statement:
ALTER TABLE table_name {ADD|DROP|MODIFY}
column_name {data_ype};
 SQL ALTER TABLE Statement (Rename) :
ALTER TABLE table_name RENAME TO
new_table_name;
 SQL COMMIT Statement:
COMMIT;
 SQL ROLLBACK Statement:
ROLLBACK;
 SQL INSERT INTO Statement:
INSERT INTO table_name( column1,
column2....columnN)
VALUES ( value1, value2....valueN);
 SQL UPDATE Statement:
UPDATE table_name
SET column1 = value1, column2 =
value2....columnN=valueN
[ WHERE CONDITION ];
 SQL DELETE Statement:
DELETE FROM table_name
WHERE {CONDITION};
 SQL CREATE DATABASE Statement:
CREATE DATABASE database_name;
 SQL DROP DATABASE Statement:
DROP DATABASE database_name;
 SQL USE Statement:
USE database_name;

58. UNIX/LINUX Commands09-13
 UNIX/LINUX
 Important UNIX commands,
 What is the Tester’s Role in Unix/LINUX
 How to login to UNIX / Linux using Putty tool
 FTP commands

59. UNIX/LINUX
 A Linux-based system is a modular Unix-like operating system, deriving much of
its basic design from principles established in Unix during the 1970s and 1980s.
Such a system uses a monolithic kernel, the Linux kernel, which handles process
control, networking, access to the peripherals, and file systems

60. UNIX/LINUX-Important UNIX commands,
 Who am I= Logged in user
 mkdir dinesh = created
directory dinesh
 Ls = list the files inside a
directory
 Ls –ltr = detailed listing eg:
drwxr-xr-
x 2 16976 16976 6 Sep 14 05:28
dinesh
Cp – copy the file
Mv- move the file
Rm – remove the file
 Sftp to do secure file transfer
from one server to another
server
 FTP
 TOP- CPU, RAM Usage
 Mail –s “Subject” email
address
 Many more things.
 TBD With tomorrow exercise.

61. LINUX/UNIX???
 www.tutorialspoint.com/unix/u
nix-useful-commands.htm
 Click on above link to see
mostly used LINUX/UNIX
Commands.
 TO connect to Unix/LINUX We
have to use SSH/TEL NET
 Putty is mostly used by
companies to connect to
Unix/linux box.
 You need to enter host/ip
address and load. Then enter
username and password for
the ip (Ip is give3n for each
server)

62. MOSTLY USED UNIX/LINUX Commands
 Command Description
 vi Opens vi text editor
 vim Opens vim text editor
 compress Compress files
 gunzip Uncompress gzipped files
 gzip GNU alternative compression method
 uncompress Uncompress files
 unzip List, test and extract compressed files in a ZIP arch
 zcat Cat a compressed file
 zcmp Compare compressed files
 zdiff Compare compressed files
 zmore File perusal filter for crt viewing of compressed tex
 ftp File transfer program
 rcp Remote file copy
 rlogin Remote login to a UNIX host
 rsh Remote shell
 tftp Trivial file transfer program
 Command Description
 cat Display File Contents
 cd Changes Directory to dirname
 chgrp change file group
 chmod Changing Permissions
 cp Copy source file into destination
 file Determine file type
 find Find files
 grep Search files for regular expressions.
 head Display first few lines of a file
 ln Create softlink on oldname
 ls Display information about file type.
 mkdir Create a new directory dirname
 more Display data in paginated form.
 mv Move (Rename) a oldname to newname.
 pwd Print current working directory.

63. Final Module- 09/16/2016- 09/18/2016
 Test Automation techniques
 Selenium/QTP
 Web Services, API Testing, Module, Build, Code management, Version Control
 Programming languages, Database, Scripting , Operating systems, Hardware,
software, Networking applications differences.
 Practice of all slides with MOCK Interview type of questions. ???
 Interview Preparation Questions & Answers sessions
 Resume Preparation & Practice for projects
 Apply the job? How to apply the job- how to get phone calls?
 Reply to the emails, How to response to the recruitment team?
 Prepare phone interview, Prepare In person interview
 Prepare for First day of office
 Prepare for First week of office
 Prepare for Manger/lead questions?
 Finally Join the job….. ????