29 February 2016

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

23 February 2016

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

17 February 2016

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

15 February 2016

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

12 February 2016

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

04 February 2016

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.

01 February 2016

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.