Concluding day of GMI Training

I collected my feedback and bid farewell to all my colleagues who assured to be in touch forever. I collected my experience letter from AMIT and the two completion certificates on Testing and Quality Management. I am extremely grateful that I had a chance to get real industry exposure and learn a lot of new things, made new contacts. This is something i can cherish for a lifetime and awarded by top managements at GMI for exhibiting core value of Creativity.

Quality Management At Sapient

Quality Management At Sapient

Sapient|Approach emphasizes on quality delivery being the responsibility of each team member. Our processes and tools are geared towards enabling each team member in ensuring quality of their respective deliverables.

The guiding principles of Sapient’s Quality Management approach are to “make quality a way of life” and to “catch defects as early as possible”. To this end, our QM approach includes industry best practices for Quality Planning, Quality Assurance, Quality Control and Quality Improvement, and covers the entire life cycle of a product/software.

Below is a representation of the focus areas of our Quality Management approach: 

Sapient Quality Management

Test Driven Development: Test Driven Development (TDD) is a technique whereby developers code unit tests first. The tests determine what system code needs to get written. Using this technique ensures that there is unit test coverage for each functionality that gets developed and that there are no system code changes unless there is a failing test case. This technique also enables us to develop functionality in incremental steps and refactor as we go along, always ensuring that the developed code is of good quality. This leads our teams to maintain an exhaustive suite of automated unit tests using the best practices tools available.

Continuous Delivery: The design principle behind Continuous Delivery (CD) is to that “every change is releasable”. Continuous Delivery is about having a deployment pipeline and a team that work towards ensuring that the software is releasable at any point of time. This technique enforces discipline within the software project team and ensures that the continuous integration and deployment infrastructure required is setup - including version control, automated builds, automated unit, functional, acceptance and regression testing, and builds packaging. Sapient has a dedicated Delivery Agility team that has expertise in the industry leading tools that enable us to setup a continuous delivery framework for a project team.

Automation: Automation is an integral part of our delivery approach and helps increase efficiency by automating repeatable tasks. Listed below are some of the candidates for automation:

·         Test Automation: The design principles built into our test automation framework are to “Support multitude of test cases without linearly increasing level of effort” and to “Make the framework keyword driven, extensible and modular”.  Test Automation using industry best practices and tools enables our teams to shorten testing times, ensure consistency, allow for extensibility and improve predictability.

·         Process Automation: Our teams always look for opportunities to automate repeatable components of project processes. Our teams have also built excel macro-based program dashboards that present a snapshot of project status on demand.

Full Life Cycle Quality Assurance: Each project team has dedicated Quality Assurance personnel embedded within, that ensure quality of deliverables throughout the lifecycle of the project. Test lead and QA engineers work in parallel with the developers, business analysts from the beginning of the project until final acceptance. Test lead is responsible for test strategy plan (including tool selection) and its execution. Testers are responsible for designing, executing and automating functional/integration/system tests.

These focus areas, along with quality gates and continuous improvement enabled by our iterative development approach ensure that quality is given prime consideration throughout the project lifecycle.

UFT Settings

UFT Settings

•Global Testing Options

Global testing options affect both how to work with tests and the general appearance of UFT. For example, choose not to display the Start Page when UFT starts, or set the timing-related settings used by UFT when running a test. The values set remain in effect for all tests and for subsequent testing sessions.

Set global testing options using the Options dialog box (Tools >> Options) or by inserting statements in the Expert View.

•Individual Test Settings

Use the Test Settings dialog box to set testing options that affect how UFT works with a specific test. For example, instruct UFT to run a parameterized test for only certain lines in the data table. The individual testing options specified are saved when a test is saved.

Set Individual Test settings using the Settings dialog box (File > Settings )

Phases in Quick Test/UFT testing process

1.PREPARING TO RECORD

oBefore recording a test, confirm that application and Quick Test/UFT are set to match the needs of your test.

2.RECORDING A SESSION ON THE APPLICATION

oNavigate through the application or Web site, Quick Test/UFT graphically displays each step that is performed as a row in the Keyword View

3.ENHANCING THE TEST

oInserting checkpoints to search for a specific value of a page, object, or text string, which helps in determining whether application or site is functioning correctly.

oParameterize the code to check that application performs the same operations with multiple sets of data.

oAdding logic and conditional or loop statements to add sophisticated checks in the test.

Recording Modes

Normal Recording Mode

oRecording based on events performed on the objects in the User Interface.

oDefault recording mode, is it also known as context sensitive.

oRecognizes objects in application regardless of their location on the screen.

Analog Recording

oAnalog recording is used for applications in which the actual movement of the mouse needs to be recorded. E.g. Drawing a mouse signature or working with drawing applications that create images by dragging the mouse.

oThe track of the operations recorded are stored in an external data file.

oUFT adds to your test action or scripted component a single RunAnalog statement that calls the recorded analog file. You cannot edit analog recording steps from within UFT

oTypes of Analog Recording:

oRecord relative to a specified window

oRecord relative to the screen

Low Level Recording

oLow-Level Recording is used when the need is to record the exact location of the operation on your application screen

oAll the keyboard input and mouse clicks are recorded based on coordinates(X,Y)

Insight Recording Mode

oThis mode enables you to record on any control (object) displayed on your screen, whether or not UFT recognizes the object's technology.

oYou can switch to Insight recording in the middle of a recording session for specific steps.

oUFT recognizes controls based on their appearance, and not their native properties.

Running Test Script

•Run – Execute UFT Test Script

•RUN FROM : Run a selected part of your test. Enables you to check a specific section of your application or to confirm that a certain part of your test runs smoothly.

•RUN TO: You can instruct UFT to run from the beginning of the test or action (Expert View only)—or from the current location in the test or action—and to stop at a particular step.

•DEBUG FROM STEP: can begin debugging from a specific step in your test or action when editing a test or action.

•RUN CURRENT ACTION option to run a single action in your test.

Update Run Mode - Updates the test object description, Checkpoints properties, active screen images and values.

Maintenance Run Mode - UFT identifies discrepancies between the objects in the repository and those in your application and then offers a solution for updating your objects and steps in real time.

Analyzing Test Results

•When a run session ends, view the run session results in the Test Results window.

•The Test Results window contains a description of the steps performed during the run session. For a test that does not contain Data Table parameters, the Test Results window shows a single test iteration.

•If the test contains Data Table parameters, and the test settings are configured to run multiple iterations, the Test Results window displays details for each iteration of the test run.

•The results are grouped by the actions in the test.

•Filters can be used to filter down only failed, passed, warning result nodes.

Quick Test Pro Vs UFT XX (11.50,51,52,53)

Quick Test Pro Vs UFT XX (11.50,51,52,53)

·         Licenses for QTP or ST will work for UFT, but they can restrict some features. It’s recommendable to upgrade to UFT Licenses to take advantage to the complete functionality provided by the tool.

·         If you just need API Testing, you can use HP Service Test Standalone, however this option it’s not available for GUI testing.

·         HP Unified Functional Testing offers new Add-ins for GUI testing as such as: QT and Flex.

·         HP Unified Functional Testing is not considered to be newer version of either Quickest Professional or Service Test.

·         Insight Recording for GUI Tests, it enables us to record control(object) displayed on screen, even if it UFT does not recognizes the object technology.

·         Removed menus from UFT: Insert, Automation , Debug Menus

·         Added Menus under UFT : Search , Design, Record, Run, ALM

Unified Functional Testing - Introduction

Unified Functional Testing = Quick Test Pro (QTP) + Service Test(ST)

Here Quick Test Professional (QTP) is a functional automation testing tool and Service Test (ST) is used for API testing(non GUI)

UFT 11.5 can support mobile testing as well ,using this feature we can test out multiple mobile devices as well in simulators.

HP Unified Functional Testing [UFT] is a new tool released in December of 2012

Supported Technology: Windows 2012, Firefox 22-24, Chrome 27-30, IE10, HTML5 enhancement, .NET Framework 4.5, Citrix 6.5, PeopleSoft 9.53, Flex SDK 4.6.

Features:

New look and feel for BPT test editing inside UFT

Create web service activities from Network Capture Data (PCAP file)

Have checkpoints for PDF, Txt ,word , HTML AND RTF files

HP UFT Insight

Key Elements in UFT Window

Active Screen: Provides a snapshot of your application as it appeared when you performed a certain step during the recording session

Data Table: Assists you in parameterizing your test. The Data Table contains the Global tab and a tab for each action

Debug Viewer: Assists you in debugging your document. The Debug Viewer pane contains the Watch, Variables, and Command tabs

Information: Displays a list of syntax errors found in your test and function library scripts

Missing Resources: Provides a list of the resources that are specified in your test but cannot be found, such as missing calls to actions, unmapped shared object repositories, and parameters that are connected to shared object repositories

UFT Licenses Types Type of QuickTest/UFT Licenses

1.Demo

2.Seat License

3.Concurrent License

Add In

•Install all add-ins over a single UFT installation

•Select which add-ins to use for a particular QuickTest session

•Built-in support: Standard windows

•Other core add-ins: Web ActiveX Visual Basic

•External Add-ins DotNet Delphi SAP MultiMedia Terminal Emulator Java Stingray Siebel Small Talk Oracle PeopleSoft ………………………..and many more

UFT-11.5x Basics Training

•      Automation Concepts

•      QTP vs UFT

•      Overview of UFT, Licenses & Add-ins

•      UFT Settings (high level only)

•      Recording a Test

•      Running & Analyzing a test

Why Testing Tools?

Automated Testing Life Cycle

Which Test Case to Automate?

• Tests that need to be run for every build of the application (sanity check, regression test)
• Tests that use multiple data values for the same actions (data driven tests)
• Stress/load /Web-Service /Smoke Testing  test cases are good candidates for automation.
• Tests requiring a great deal of precision ,complex in nature and consume huge manual effort.
• Functionalities which are stable and live under production system.
• Test cases through which are required from good ROI perspective.
• Test cases which are mainly suitable from business user perspective.
• More repetitive execution! Better candidate for automation.

Introduction on Selenium Tool

Selenium is a free (open source) automated testing suite for web applications across different browsers and platforms. It is quite similar to HP Quick Test Pro (QTP) only that Selenium focuses on automating web-based applications.


Selenium is not just a single tool but a suite of software's, each catering to different testing needs of an organization. It has four components.


· Selenium Integrated Development Environment (IDE): selenium Integrated Development Environment (IDE) is the simplest framework in the Selenium suite and is the easiest one to learn. It is a Firefox plugin that you can install as easily as you can with other plugins.


· Selenium Remote Control (RC): Selenium RC was the flagship testing framework of the whole Selenium project for a long time. This is the first automated web testing tool that allowed users to use a programming language they prefer.


· WebDriver: It implements a more modern and stable approach in automating the browser's actions. WebDriver, unlike Selenium RC, does not rely on JavaScript for automation. It controls the browser by directly communicating to it.


· Selenium Grid: Selenium Grid is a tool used together with Selenium RC to run parallel tests across different machines and different browsers all at the same time. Parallel execution means running multiple tests at once.






Why do we need to automate?


§ To avoid human intervention


§ To make it fast and productive


§ To make it reusable or repeatable 

§ To make it reliable

What is Automation Testing

• Developing Scripts to Run the Test Cases Automatically and to Log the Results
•  Software Test Automation is the process of automating the steps of manual test cases using an automation tool Or utility to shorten the testing life cycle with respect to time…
•  When application undergoes regression, some of the steps might be missed out or skipped which can be avoided in Automation…
•  Automation helps to avoid human errors and also expedite the testing process…
•  To implement the Test Automation detailed planning and effort is required

Importance of Automation Testing

In today’s environment of reducing cycle times, test automation becomes an increasingly critical and strategic necessity. Especially in the new explosive pace of web-enabled deployment, if retaining satisfactory test coverage and reducing risk is required, then either more people have to be put on manual testing, or a greater level of test automation is required to keep the pace. After all, a reduction in project cycle times generally correlates to a reduction of time for test.

There are certain other aspects which make automation more helpful, some of them are listed below.

§ Increased speed of execution

§  Machine results are more replicable than human results

§  Parallel execution, Re-use of test cases etc are some additional   benefits.

Automation Fundamental Concepts

• Automation life cycle is a subset of the entire test life cycle…
•  Automation planning can be initiated in parallel to the test planning phase…
•  Factors to be considered in automation planning,
•             Stability of AUT (Application under test)
•             No of regression cycles to be performed
•             Compatibility of App platform with testing tools
•             Cost benefit analysis (ROI)
•             Availability of skilled resources

Defect Management

Defect Management Process

The primary goal of Defect Management is to detect and track the defects to closure, implementing the processes required for coordination between the teams for the defect prevention and defect closure. The Defect Management Approach defines

Defect Triage and Prioritization Process

o Stages of Defect

· Defect Discovery

· Defect Resolution

· Defect Tracking

o Defect Discovery

· Find a Defect

· Report Defect

· Acknowledge Defect

o Defect Resolution

· Prioritize: Determine the importance of fixing a particular defect.

· Categorize: Classify defects with end users.

· Fix: Developers fix defects in order of importance.

· Report: Developers notify all relevant parties how and when the defect was repaired.
Defect Tracking

§ Monitoring Defects from the time of recording until satisfactory resolution has been determined
Prioritization Process



Priority

Label

Description

Priority1

Critical

Priority 1 defects prevent the operation of the Site or Application


Priority2

Major

Priority 2 defects limit the ability to operate the business efficiently but a Loblaw’s approved workaround is defined.


Priority3

Minor

Minor defects that do not significantly affect the operation or appearance of the Sites.


Priority4

Trivial

Cosmetic defect which do not affect the flow of the workflow.


Table 4.1 Proirity

4.2 Defect Management Process



Figure 4.3 Stages of Defect



4.3 TEST STATUS REPORT
4.3.1 Daily Status Reports

The daily reports would be made by the testers which will be consolidated and submitted to the client. In these reports we would be updating the client regarding the daily proceedings with the various test cases i.e. which have been executed, which have not been executed and what all would be done on that day
4.3.2 Weekly Status Reports

These reports would be submitted by each track lead which would update the client regarding the work done on each of the tracks
4.3.3 Application Health Check Report

This would be submitted by the QA Manager telling the big picture regarding the overall work done.

4.4 OVERALL COMPLETION CRITERIA FOR TESTING



Figure 4.4 Completion Criteria

A critical aspect of monitoring the progress and acceptance of the end result of Testing for the Version 1.0 will be a clear understanding and agreement on completion criteria.

One key aspect of this is the successful identification and resolution of issues/defects.

Issues/defects are categorized as follows:

CRITICAL:

Causes system to crash or does not support critical functional requirements tied to Key Performance Parameters. No acceptable work-around. Unable to demonstrate completed business scenario.

HIGH:

Causes significant system degradation or a difficult work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with difficulty.



MEDIUM:

Causes moderate system degradation or a work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with moderate to minor impact to business process.

LOW

Causes minor system degradation or minor work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with minor to no impact to business process.



Completion criteria for Pre-System Test have been established as following:

· Each business Test Case exercised

· Each required conversion, interface and enhancement completed

· No CRITICAL unresolved issues/defects, may allow HIGH if necessary, but have

· an action plan.

· Action plans exist for remaining HIGH, MEDIUM and LOW issues/defects

· Security and Privileges(Profiles) established and tested

Completion criteria for System Test have been established as following:

· Each business Test Case exercised

· Each required conversion, interface and enhancement completed

· No CRITICAL, HIGH and MEDIUM unresolved issues/defects remain

· Action plans exist for remaining LOW issues/defects

· Security and Privileges (Profiles) established and tested

Completion criteria for Beta Test have been established as following:

· Each business Test Case exercised and

· Each required conversion, interface and enhancement completed

· No CRITICAL, HIGH, MEDIUM and LOW unresolved issues/defects remain

· Security and Privileges (Profiles) established and tested

Business Users

A non-Sapient employee who serves as an independent observer/assessor of the system during testing. While acting as a Business User, the person represents others with the same functional specialty and provides input from that perspective. Input includes functional issues, any other business requirements and other documentation, and overall assessment of the system.

Business Users will be assigned to scenarios and testing sessions based on their skill set at Mercury Tours.

Changes

Changes to any of the testing documents will be done at the end of each testing cycle.

The only exception to this will be in the event of a change request event or change that is needed.

Test Scenarios

A test scenario is a string of business processes, which lead to an expected outcome.

Changes to the Test Scenarios must be submitted by the test team member to the Test Team Manager for signoff.

Communications

Communications between the entire Test Team and Mercury Tours POC is critical during testing. There may be many activities going on at one time and all resources will be called upon to assist in the successful execution of all testing cycles. It is everyone’s responsibility to review the issues database for progress on issues related to testing.

Testing Tool:

The following tools should be provided to the QA Team prior to commencement of testing:

1. Defect Logging and Tracking tool: Quality Center or JIRA

2. Selenium For Functional and Regression Testing



3. Apache Jmeter: For Load Testing.

TEST PROCESS

Work Products Creation (Deliverables)

During the Testing phases, various deliverables will be provided as outcome. These are listed as follows

· Gap Analysis Report

· Requirement Traceability Matrix

· Test Strategy

· Estimation Report

· HLP/MLP for the release

· High Level Test Scenarios

· Selenium Script

· Defect Status Report

· Test Completion Report
4.1.1 Gap Analysis Report

After getting the Project Requirements, we have logged our various queries in Requirement Query Log and discussed these in the client meetings. The Gaps in understandings were logged into this document.
4.1.2 Requirements Traceability Matrix (RTM)

After the requirements have been frozen by the client and the test cases are signed off by the user. The QA Team would form the Requirement Traceability Matrix and get it signed off from the client confirming that all the requirements have been covered
4.1.3 HLP/MLP

During this iteration for quality assurance, the team has been working in synchronization with the High-level plan and Mid-Level Plan
4.1.4 Estimation Report

Various Time and Effort estimations were included in the Estimation Report. These estimations are mapped with the HLP also.
4.1.5 Defect Status Report

Depending upon the outcome of each and every test case executed defects would be logged and the number of defects that are found would be logged and reported back to the stakeholders. All the defects encountered during test execution are logged in Jira and a Defect Status Report is generated.
4.1.6 High Level Test Scenarios (HLTS)

The High Level Test Scenarios have been created by test leads and the QA Manager.
4.1.7 Test Cases

All the test cases would be created by the Test Analyst and would be validated by the Test Lead to make sure that the test cases map back to the requirements the user had defined.
4.1.8 Test Scripts

All the test cases once manually tested will be automated into scripts using Selenium
4.1.9 Test Completion Report

After execution of all tests, it is recorded in the Test Completion Report which explains the number of test executed or gated or passed or failed and the overall test coverage.

4.2 Work Products Review Process
· Test Deliverables Review

Each of the deliverables would be reviewed by the test lead and the QA Manager before being delivered to the client.
· Maintenance of Test Cases/Scripts

The various test cases and scripts would be regularly updated and versioned by the QA Team in order to make things coordinate much better. If in case the test cases/scripts have been changed by the user depending upon change in defect or requirements, due to versioning of scripts we would be able to map defects to the version of case/script that caused it.

4.3 TEST MANAGEMENT

4.3.1 Test Environments
· System Test Environment

QA team will create both manual and automated test scripts based on the requirements mentioned in the wireframes and FSD’s. These scripts will be executed on the local QA environment which will consist of both authoring as well as publishing instances. This environment will be based locally within Sapient environment.
· System Integration Test Environment

Once all test scripts have been successfully executed on the system test environment and there are no open P1’s and P2’s on the test environment. Along with the system test scripts, QA team will create and execute End 2 End test scripts on the SIT environment. Please note that the SIT environment will be a scaled down version of the production environment which will consist of both authoring as well as publishing instances. This environment will be based locally within stakeholder environment.
· UAT Environment

This environment will also be used as the Production environment wherein UAT test scripts (created by Stakeholder) will be executed and finally a Go/No Go sign-off decision will be provided. Post UAT sign-off, application will be deployed on the Production environment (during the cutover phase) and application sanity will be tested on the production environment. Please note that all System Test scripts will not be executed on the production environment. This environment will also consist of both authoring as well as publishing instances.

4.3.2 Test Data Management
· Test Data from Production

The test Data would be provided to us by the client. The data should have been validated and be data from the production environment
· Test Data Creation

The dummy data provided to us would be used to create new data. We would use the front end applications of the user to create that data
· Test Data Maintenance



The data would be versioned and saved. This would help preserve the original data as well as show the various transitions in the data that might have happened as the data moved through the application

Testing Methods

4.1.1     Unit Testing

The developers test their module to check if individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation.

4.1.2     Smoke Testing

A quick high level test that the major functions of a piece of software work originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

4.1.3     Functional Testing

This test will confirm that all the functionalities mentioned in the requirement document are working correctly as designed. From the tester’s perspective, this test will be carried out from Unit Testing to all the way to the production.

4.1.4     Regression Testing

This is a repeated test to check whether the application is working as intended after a bug fix or after adding a new functionality in the application.

4.1.5     Pre-System Testing:

As the developers finish writing their code for Mercury Tours or are about to finish, the Mercury Test Team will create a test environment where the testers will test to check whether there is any major break down in the application. This test will also test the integration of components. Any critical defects (or high level defects in some cases) will be resolved immediately before it goes to System Testing environment. This testing will help create a cleaner application in the System Test environment.

4.1.6     System Testing

This activity will test Mercury Tours in the Test Environment upon the completion of pre-system testing, Mercury will create System Testing environment where the all the functionalities will be tested as per Use Cases. All the Test Cases will be executed and the defects will be logged as found. This environment will be environment for Mercury Test Team and will not be available for Mercury Tours Test Team. Once the System Test meets the exit criteria, then the system will be ready for Beta Testing.

4.1.7      Beta Testing

Upon completion of the requirements, development and system testing phase, Mercury will create a Beta Testing environment (the Beta site). The Beta site will be created within the Mercury network but will be available to the Mercury. The Beta site will be a scaled down version of the planned production environment and as such will not have all of the security and redundancy that a production environment would normally have. It will also not have the same performance as a production environment, but the performance will be adequate considering the minimal number of users accessing it. The network configuration and software codebase will be identical to the planned production environment. Mercury anticipates using the Beta site to continue our own internal testing, and the

Mercury or any of its designees will have full access to test any or all of the features. Mercury will create a test bed of data that the Mercury can use in their testing. These data will not be a full representation of the production site, but will allow a tester to complete an application and choose from a small subset of the member institutions, for example. A couple of supplemental forms will be available, and the e payment testing will use test credit cards and create test transactions. The Beta site is not intended for stress testing. If any problems are discovered, a mutually agreed upon process of reporting and tracking defects will be used. Mercury will use an iterative approach, fixing issues and releasing new code to be retested by the tester who reported the problem until the issue is resolved to the tester’s satisfaction.

4.1.8      Acceptance Testing (UAT)

After Beta testing is completed, Mercury will create a User Acceptance testing environment (the UAT site). The UAT site will be created within the production network environment in the AT&T Data Center and be fully available to the Mercury. The UAT site will be on the production hardware, and will have all the security features of our standard production environment. Redundancy will be added before going live. Performance will be identical to that in production.

Sapient will work with the Mercury to create a full test bed of data .  The UAT site is intended to verify the final configuration of the site and the data, and will be the basis for the production environment.

4.1.9     Stress Testing:

After the Beta Testing is complete, Test Team will perform this testing which will determine the stability of Mercury Tours This testing will be conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

4.1.10  Load Testing:

Load testing will be carried out by putting a computer, peripheral, server, network or application to a work level approaching the limits of its specifications. This testing will be done under controlled lab conditions to compare the capabilities of different systems to accurately measure the capabilities of a single system. This testing will be as per realistic and close environment.

The above three different types of testing will be done in three cycles:

1. Cycle 0

2. Cycle 1

3. Cycle 2

The QA Team will execute all scenarios

Communication Rules

§Rules to assist individuals in getting their message across clearly and working towards better communication
§Being Effective (two-way) – comment / response
§Recognize Barriers – different want / needs / attitudes
§Achieving Clarity – clear / concise / understood
§Choosing a Method – 5 Types: written / spoken (heard) / symbolic / visual / combination
§Combining Methods – combine from the 5 Types mentioned in previous point


§Select the communication medium based goal
§Vary communication based on need and audience
§Remember the 4 Ps
§Planning
§Practice
§Patience
§Persistence



Active process of Listening

Hearing---Understanding----Listening




Listening Process – Listening Tips

§Attention: Give complete attention to the speaker. Maintain eye contact
§Focus: Don’t let your mind wander even if you think you know what is coming next.
§Patience: Wait till the speaker finishes. Don’t interject
§Listen before you speak: Have you really understood the speaker?
§Main ideas: Understand the crux. Phrases like “The key point is..”
§Ask questions: Clarify whenever in doubt
§Visualize: Make mental picture of what speaker is saying
§Give feedback: Smile, frown, nod and laugh to show that you understand

Testers Role and Responsibilities

§Participates in Requirement Definition when playing the role of a System Analyst
§Participates in Requirements Verification to understand the Requirements and assist the Test Lead in verifying the quality of the Requirements with regards to:
§Testable requirement definition
•Test Design, Test Script, and Test Data Development
•Test Automation, Test Environment Configuration, and Test Execution
§Drafts Test Scenarios
§Provides inputs to Test Lead for refinement of Testing Estimates
§Participates in Functional and Technical Design Verification
§Facilitates Testing Environment set up
§Updates Test Scenarios
§Kicks off Test Script Development
§Reviews Test Strategy/Test Plan along with other team members
§Completes Test Script Development
§Completes Test Script Verification and ensure right categorization of Test Scripts is done
§Identifies reusable scripts
§Support Unit Testing with data Requirements
§Identify/Prepare/Obtain data for Test Execution
§Participates in Unit Test Checkpoint, if required participates in System, Integration, and Load Testing Checkpoints
§Creates a Low Level Plan for daily execution by taking inputs from the Test Lead and Mid Level Plan
§Sets up the Test Set for execution
§Executes Test Scripts and logs Defects
§Participates in the UAT sessions to provide application knowledge coverage to the end users, if required
§Performs Go-Live Testing
§Ensures Test Scripts modifications are complete
§Archives Test Scripts for reuse
§Participates in Root Cause Analysis with Test Lead
§Updates the testing artifacts like Test Strategy, Test Plan, Use Cases, etc.

Additional Responsibilities

§Provides inputs to Test Lead for creation of Testing/Quality slides to be included in the Project Health Assessment
§Creates Daily Plan during each Testing Phase
§Tracks to the Daily Targets and timely escalates slippages
§Creates a Daily Execution Status report for the Test Lead
§Assists the Test Lead in managing testing logistics
§Provide input to Test Lead for continuous process improvement
§Mentors new people on Testing Team on application knowledge, testing processes, and tools
§Ensures complete coverage for all the Requirements
§Ensures Defects are logged and end-to-end traceability between Requirements, Test Scripts, and Defects
§Ensures proper resolution comments are captured in Defects before closure
§Log Helpdesk tickets for environment issues
§Develop product and business specific expertise

SDLC Cont: Agile / Iterative Model

The software development project is divided into mini-projects, each of which is
an iteration that results in an increment.
 Each iteration deals with the most important risks and realizes a group of use
cases that together extend the usability of the product as developed so far.
 In the early phases, a superficial design might be replaced by a more detailed or
sophisticated one
 In later phases, increments are typically additive
 Agile model recognizes testing as an integral part of software development,
along with coding
 Testing and coding are done incrementally and iteratively, building up each
feature until it provides enough value to release to production

Agile Model – Pros & Cons
Pros
 Agile methodology has an adaptive team which is able to respond to the changing
requirements.
 The team does not have to invest time and effort and finally find that by the time they
delivered the product, the requirement of the customer has changed.
 Face to face communication and continuous inputs from customer representative
leaves no space for guesswork.
 The documentation is crisp and to the point to save time.
 The end result is the high quality software in least possible time duration and satisfied
customer.
Cons
 In case of some software deliverables, especially the large ones, it is difficult to assess
the effort required at the beginning of the software development life cycle.
 There is lack of emphasis on necessary design document and documentation.
 The project can easily get taken off track if the customer representative is not clear
what final outcome that they want.
 Only senior programmers are capable of taking the kind of decisions required during
the development process. Hence it has no place for newbie programmers, unless
combined with experienced resources.

Sapient Agile Testing Services
 Risk Mitigation by early integration and providing clients results sooner
 Increased Responsiveness ability to change or adjust course based on
learning from the first few iterations
 Early and continuous delivery of valuable software
 True transparent partnership with our clients

Testing of Stages
User Acceptance Testing
1. It’s when the users of the
application and the business
sponsors and owners have their
turn to test the application
2. The two primary methods of
testing:
• Script execution from a
subset of scripts already
created by the System
Analysts
• “Free Form” test, where
they are free to test the
application without any
scripts or scenario guidance
Who Performs it:
Alpha Testing: is performed by
members of the organization that
developed the software but who
are not directly involved in the
project (Development or
Testing).
Beta Testing: is performed by the
end users of the software. They
can be the customers
themselves or the customers’
customers.
Unit Testing
1. Test Driven Development (TDD)
approach to write the code
2. New functionality code was added in
the system in small chunks by writing
a new test, and then writing the code
to satisfy the test
3. “J-unit” test cases were written to
perform unit test
4. To validate each distinct module of the
application is implemented as per the
technical and functional specification
of the story at the unit level
Integration Testing
System & E2E Testing
1. To validate that different component /
modules of the applications are linked
correctly and are functionally operational
as an integrated unit
2. A dedicated testing team that gets involved
right from the iteration kick off when the
design and functionality to be implemented
is being discussed
3. Based on the story specifications, identified
the functional test scenarios covering
different navigation paths and erroneous
user behavior in order to test the
application in different user situations
4. The Integration tests strategy for the
application had 4 facets:
• Web Application
• Batch Pre-Processor
• Metric Computation/ Limit
Comparison
• Interface

Software Life Cycle (SDLC) Models

 Waterfall Model
 V Model
 Agile / Iterative Model

Waterfall Model – Pros & Cons
Pros
 Simple and easy to use.
 Easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood
Cons
 Adjusting scope during the life cycle can kill a project
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Poor model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Poor model where requirements are at a moderate to high risk of changing
 Requirements change over time
 Maintenance not handled well

V-Model
 It emphasizes the significance of quality activities by defining several distinct
testing levels and illustrating how each level addresses a different stage of the
lifecycle
 V-Shaped life cycle is a sequential path of execution of processes

V-model - Stages
Business Case
 The first step in development is a business investigation followed by a "Business Case" produced by the
customer for a system.
Requirements
 The next broad step is to define a set of "Requirements", which is a statement by the customer of what the
system shall achieve in order to meet the need both functional and non-functional requirements. This is done
in collaboration with service providers Business Analysts.
System Specification - Check
 "Requirements" are then passed to developers, who produce a "System Specification".
 System specifications are compiled by Business Analysts, based on the Requirement captured during Fusion
workshops. This document has to be signed off by the customer.
System Design - Check
 Architects produce a "System Design" from the "System Specification".
Component Design
 Each component then has a "Component Design", which describes in detail exactly how it will perform its piece
of processing. This is also done by Senior developers and Architects.
Component Construction
 Based on Requirements and Design, the developers do their coding and Finally each component is built, and
then is ready for the test process.
Component Testing
 Starting from the bottom the first test level is "Component Testing", sometimes called Unit Testing. It involves
checking that each feature specified in the "Component Design" has been implemented in the component.
This is done by Developers.
Interface Testing
 As the components are constructed and tested they are then linked together to check if they work with each
other.
System Testing
 Once the entire system has been built then it has to be tested against the "System Specification" to check if
it delivers the features required.
Acceptance Testing
 Acceptance Testing checks the system against the "Requirements". This is done by the clients to confirm if
the system has been developed as per their expectations..
Release Testing
 Release Testing is about seeing if the new or changed system will work in the existing business
environment.
Regression Tests – Check
It seeks to uncover new software bugs in existing functional and non-functional areas of a system after
changes such as enhancements, patches or configuration changes, have been made to them.
One of the main reasons for regression testing is to determine whether a change in one part of the software
affects other parts of the software.
 It follows that all the above types of testing could be repeated at many levels in order to deliver the final
value to the business. In fact every time a system is altered.
V Model – Pros & Cons –
Pros
 Simple and easy to use.
 Each phase has specific deliverables.
 Higher chance of success over the waterfall model due to the development of test plans
early on during the life cycle.
 Works well for small projects where requirements are easily understood
Cons
 Very rigid, like the waterfall model.
 Little flexibility and adjusting scope is difficult and expensive.
 Software is developed during the implementation phase, so no early prototypes of the
software are produced.
 Model doesn’t provide a clear path for problems found during testing phases

What is a “Bug”?

§Error: A human action that produces an incorrect result
§Fault: A manifestation of an error in software. The actual 'mistake' in the code
§Also known as a defect or bug
§If executed, a fault may cause a failure
§Failure: Deviation of the software from its expected delivery or service
Examples of Software Bug : http://www5.in.tum.de/~huckle/bugse.html

Error - Fault - Failure

A person makes an error ...… that creates a fault in the software ...… that can cause a failure in operation

Spectacular Software Failures

 NASA’s Mars lander: September 1999, crashed due to a units integration fault

 Toyota brakes : Dozens dead, thousands of crashes

 Major failures: Ariane 5 explosion, Mars Polar Lander, Intel’s Pentium FDIV bug

 Poor testing of safety-critical software can cost lives :

 THERAC-25 radiation machine: 3 dead

 Northeast Blackout of 2003 :508 generating units and 256 power plants shut down, Affected 10 million

people in Ontario, Canada, Affected 40 million people in 8 US states, Financial losses of $6 Billion USD

The alarm system in the energy management system failed due to a software error and operators were not

informed of the power overload in the system

Energy Trading different from Financial Trading

•Energy trading involves both the physical settling trades (forwards and futures involving the physical delivery of commodity) and the financial trades (swaps and futures which are settled financially).
•Apart from the derivatives needed for hedging, there exists other trades in energy business due to its nature:
îA physical commodity is to be traded and there is a delivery structure or process associated with each commodity.
îDue to varied factors like liberalization, generation, transmission and consumption, each function has its own functions like the transmission facility has to maintain balance at storage points.


•All this results in trades like Storage Contracts, Capacity Contracts, Transport Contracts and Imbalance Contracts.


Gas Storage and Transport


•Natural gas storage facilities provide capacity and other services like transportation etc. Customer can buy the storage capacity from the gas facility. There are storage points and delivery points (injection points and withdrawal points).
•"Delivery" means the transfer of gas from an interstate pipeline or other transporter to the Company at a point of interconnection to the Company's distribution system.
•"Redelivery" means the transfer of gas from the Company to the Buyer at the meter at the Buyer's facility.
•"Delivery point" means any point on the Company's gas distribution system at which an interconnection exists with an interstate pipeline or other transporter to enable the Company to receive gas owned by the Buyer for redelivery to the Buyer's facility.
îInjection point: delivery point where gas will be injected by the buyer of storage.
îWithdrawal Point: delivery point where gas will be withdrawn by the buyer of storage.

Options Basics: What Are Options?

An option is a contract that gives the buyer the right, but not the obligation, to buy or sell an underlying asset at a specific price on or before a certain date. An option, just like a stock or bond, is a security. It is also a binding contract with strictly defined terms and properties.

Still confused? The idea behind an option is present in many everyday situations. Say, for example, that you discover a house that you'd love to purchase. Unfortunately, you won't have the cash to buy it for another three months. You talk to the owner and negotiate a deal that gives you an option to buy the house in three months for a price of $200,000. The owner agrees, but for this option, you pay a price of $3,000.

Now, consider two theoretical situations that might arise:
It's discovered that the house is actually the true birthplace of Elvis! As a result, the market value of the house skyrockets to $1 million. Because the owner sold you the option, he is obligated to sell you the house for $200,000. In the end, you stand to make a profit of $797,000 ($1 million - $200,000 - $3,000).
While touring the house, you discover not only that the walls are chock-full of asbestos, but also that the ghost of Henry VII haunts the master bedroom; furthermore, a family of super-intelligent rats have built a fortress in the basement. Though you originally thought you had found the house of your dreams, you now consider it worthless. On the upside, because you bought an option, you are under no obligation to go through with the sale. Of course, you still lose the $3,000 price of the option.

This example demonstrates two very important points. First, when you buy an option, you have a right but not an obligation to do something. You can always let the expiration date go by, at which point the option becomes worthless. If this happens, you lose 100% of your investment, which is the money you used to pay for the option. Second, an option is merely a contract that deals with an underlying asset. For this reason, options are called derivatives, which means an option derives its value from something else. In our example, the house is the underlying asset. Most of the time, the underlying asset is a stock or an index.

Calls and Puts
The two types of options are calls and puts:
A call gives the holder the right to buy an asset at a certain price within a specific period of time. Calls are similar to having a long position on a stock. Buyers of calls hope that the stock will increase substantially before the option expires.
A put gives the holder the right to sell an asset at a certain price within a specific period of time. Puts are very similar to having a short position on a stock. Buyers of puts hope that the price of the stock will fall before the option expires.

Participants in the Options Market
There are four types of participants in options markets depending on the position they take:
Buyers of calls
Sellers of calls
Buyers of puts
Sellers of puts

People who buy options are called holders and those who sell options are called writers; furthermore, buyers are said to have long positions, and sellers are said to have short positions.

Here is the important distinction between buyers and sellers:
Call holders and put holders (buyers) are not obligated to buy or sell. They have the choice to exercise their rights if they choose.
Call writers and put writers (sellers), however, are obligated to buy or sell. This means that a seller may be required to make good on a promise to buy or sell.

Don't worry if this seems confusing - it is. For this reason we are going to look at options from the point of view of the buyer. Selling options is more complicated and can be even riskier. At this point, it is sufficient to understand that there are two sides of an options contract.

The Lingo
To trade options, you'll have to know the terminology associated with the options market.

The price at which an underlying stock can be purchased or sold is called the strike price. This is the price a stock price must go above (for calls) or go below (for puts) before a position can be exercised for a profit. All of this must occur before the expiration date.

An option that is traded on a national options exchange such as the Chicago Board Options Exchange (CBOE) is known as a listed option. These have fixed strike prices and expiration dates. Each listed option represents 100 shares of company stock (known as a contract).

For call options, the option is said to be in-the-money if the share price is above the strike price. A put option is in-the-money when the share price is below the strike price. The amount by which an option is in-the-money is referred to as intrinsic value.

The total cost (the price) of an option is called the premium. This price is determined by factors including the stock price, strike price, time remaining until expiration (time value) and volatility. Because of all these factors, determining the premium of an option is complicated and beyond the scope of this tutorial.

Bond Basics: Introduction

The first thing that comes to most people's minds when they think of investing is the stock market. After all, stocks are exciting. The swings in the market are scrutinized in the newspapers and even covered by local evening newscasts. Stories of investors gaining great wealth in the stock market are common. 

Bonds, on the other hand, don't have the same sex appeal. The lingo seems arcane and confusing to the average person. Plus, bonds are much more boring - especially during raging bull markets, when they seem to offer an insignificant return compared to stocks. 

However, all it takes is a bear market to remind investors of the virtues of a bond's safety and stability. In fact, for many investors it makes sense to have at least part of their portfolio invested in bonds. 

This tutorial will hopefully help you determine whether or not bonds are right for you. We'll introduce you to the fundamentals of what bonds are, the different types of bonds and their important characteristics, how they behave, how to purchase them, and more.