1.

WHAT DOES A SOFTWARE QUALITY

ASSURANCE ENGINEER DO ?
• A software quality assurance engineer is involved in tasks that
include software design, writing source code, control of source
code, reviewing code, configuration management, change
management, program testing, integration of software, and release
management process.

• Software quality assurance engineers must also be able to see to it

that the final product not only meets with company but also reaches
the consumer market at the time appointed by the company.

• Software testers test parts of the software at different stages of

development, whereas a software quality assurance engineer
oversees the entire development process, which includes
software testing, from start to finish.

www.qaitive.rs
2. INTRODUCTION TO SOFTWARE TESTING

www.qaitive.rs
 2. INTRODUCTION TO SOFTWARE TESTING

• It includes a set of activities conducted with the intent of finding

errors in software so that they could be corrected before the
product is released to the end-users.

• In simple words, software testing is an activity to check whether the

actual results match the expected results and to ensure that the
software system is defect free.

www.qaitive.rs
3. ROLES AND RESPONSIBILITIES

Project Manager
• Provides Go/No Go authorization that product is ready for release as
part of implementation planning and launch process
• Prioritizes issues and defects, and manage technical resources
• Makes decisions on unresolved issues

Business Analyst
• Define business requirements and expected results for business
acceptance
• Execute user acceptance testing
• Write business requirements

www.qaitive.rs
3. ROLES AND RESPONSIBILITIES

Scrum Master
• They are responsible for managing the exchange of information
between team members.
• A Scrum Master leads a scrum. Scrums are daily meetings
conducted by Agile, self-organizing teams that allow the team to
convene, share progress and plan for the work ahead.

Product Owners
• Members of the leadership team who manage the entire product
development process within an organization.
• They'll research and determine the clients' needs to determine which
features to include on products and will pitch ideas for product
features to stakeholders.

www.qaitive.rs
3. ROLES AND RESPONSIBILITIES

Developers
• Database Administrator
• Write application code
• Resolve defects
• Support testers

QA
• Write test plan to include test scenarios and cases
• Build test scripts
• Perform user acceptance testing

www.qaitive.rs
4. ENVIRONMENTS

Development environment (DEV)

where all done features/fixed issues are deployed first by developers.
Developer is responsible to configure all required changes in
development environment for functionality to work.

Test environment (TEST)

where all features/bug fixes previously resolved and deployed to
development environment (and verified in terms of basic scenarios) by
developer, are then deployed for detailed testing and verification by
QA.

www.qaitive.r
s
4. ENVIRONMENTS

Production environment (PROD)

Actual production environment where application is deployed for end
users. QA can (and should) perform some of the additional verification
of targeted features/bug fixes after deployment of version of application
to PROD environment to make sure everything is propagated well to
final environment.

www.qaitive.rs
5. ISSUE WORKFLOW

www.qaitive.rs
6. TYPES OF TESTING

Black Box Testing: Testing an Application Under Test (AUT) without

referencing the internal structure is called the black box testing. Testing
will be done by visualizing the application as a black box.
White Box Testing: Testing an application with reference to the
internal structure of the software component is called white box testing.

www.qaitive.rs
6. TYPES OF TESTING

Based on scope of testing, we can write different types of test:

• Positive
• Negative
• Relation
• Performance
• Regression
• Smoke
• Automated
• Acceptance
• Integration
• System
• Security
• Compatibility

www.qaitive.rs
• Performance test cases
It is a good idea to have some performance test cases designed for each release to
ensure that each release maintains adequate performance.
Area Testing; Test each critical area of your software, logged in with different accounts
(accounts with small amounts of data, accounts with large amounts of data...).

• Regression test cases

Regression Testing is required when there is a :
- Change in requirements and code is modified according to the requirement
- New feature is added to the software
- Defect fixing
- Performance issue fix

• Smoke test cases

Smoke tests are simply a list of about 20 to 30 test cases that address the core
functionalities being tested.
If the Smoke Tests fail QA process should stop and wait until those are fixed, or it may be
that testing can progress with requirements that did not fail the test case.
• Automated test cases
Quicker Releases - By having our regression test cases run automatically, our software
quality team can concentrate on testing new features of our software and less time
regressing existing features.

• Integration test cases

The purpose of integration testing is to detect any inconsistencies between the software
units that are integrated together or between any of the software modules and the
hardware.

• Security test cases

Security testing is a process intended to reveal flaws in the security mechanisms of an
information system that protect data and maintain functionality as intended.
7. TEST SCENARIO AND TEST CASES

The scenario covers the complete "end to end"

functionality of the applications we are testing.

The test case is "How to Test" and the Test Scenario

"What to Test".

www.qaitive.rs
7. TEST SCENARIO AND TEST CASES

www.qaitive.rs
 8. CREATING OF TEST CASES

A test case can and should have the following elements. Note that normally a test
management tool is used by companies and the format is determined by the tool used.

Minimal set of elements required for creating of test cases:

• Test Case ID - The ID of the test case (should be unique)
• Test Title / Name - Test case title ‘Verify login page with valid username and password’
• Test Priority - Low/Medium/High, useful while test execution. Test priority should be set by
reviewer.
• Test Case Summary - The summary / objective of the test case
• Test Procedure / Test steps - Step by step procedure to execute the test
• Expected results - The expected result of the test
• Status - Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed and
‘Blocked’ if testing is blocked
• Executed By - The name of the person who executed the test
• Date of Execution - The date of execution of the test
• Defect ID / Link - If test status is fail, then include the link to defect log or mention the
defect number

www.qaitive.rs
Optimal or recommended set of elements for creating high quality test cases:

• Test Case ID - The ID of the test case (should be unique)

• Test Title / Name - Test case title ‘Verify login page with valid username and password’
• Test Suite ID - The ID of the test suite to which this test case belongs
• Test Priority - Low/Medium/High, useful while test execution. Test priority should be set by reviewer.
• Module Name - Mention name of main module or sub module
• Test Type / Keywords - Positive, negative...
• Parent test scenario
• Test Case Summary - The summary / objective of the test case
• Related Requirement - The ID of the requirement this test case relates to
• Preconditions - Any prerequisites or preconditions that must be fulfilled prior to executing the test
• Test Procedure / Test steps - Step by step procedure to execute the test
• Test Data - The test data that are to be used while conducting the test (really useful)
• Expected results - The expected result of the test
• Post conditions - Post conditions that must be fulfilled after executing the test
• Status - Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed and ‘Blocked’ if testing is
blocked
• Notes / Comments / Questions - Any comments on the test case or test execution
• Created By - The name of the author of the test case
• Date of Creation - The date of creation of the test case
• Executed By - The name of the person who executed the test
• Date of Execution - The date of execution of the test
• Test Environment - The environment in which the test was executed
• Defect ID / Link - If test status is fail, then include the link to defect log or mention the defect number
• Test Case Reviewed - Date of review
• Following info - Proofs, files, printouts, reports, screen grabs
• Automation is feasible - Yes / No
 EXAMPLE OF POSITIVE TEST CASE FOR LOGIN FORM

Step Task Expected Result

1 Open home page
2 Click on Sign In button
3 Enter valid data for username
4 Enter valid data for password
5 The user has successfully logged on his
Click on Login button account.
6
 EXAMPLE OF NEGATIVE TEST CASE FOR LOGIN FORM

Step Task Expected Result

1 Open home page
2 Click on Sign In button
3 Enter wrong data for username
4 Enter wrong data for password
5 Click on Login button User failed to log on his account.
6
Squash TM (Test Management)

Squash TM is the test repository manager found in the open source Squash
toolkit. It enables the management of requirements, test cases and campaigns
execution in a multiproject context.