Friday, December 27, 2013

Software Testing Life Cycle - STLC

STLC comprises of the following phases:


  1. Requirement analysis
  2. Test Scenarios preparation
  3. Test cases preparation
  4. Reviews
  5. Test scenarios/cases updating
  6. Build deployment in testing environment
  7. Smoke testing
  8. Functional testing
  9. Bug Tracking
  10. Build deployment and testing in Client region
  11. Security testing
  12. Performance testing

Analysis and Test Scenarios preparation


Test Cases preparation

Once the test scenarios baselines, SQA team prepares the test cases, test data, xmls and database test queries.

Build deployment in SQA environment


Smoke testing



Functional testing

Bug Tracking

Build deployment and testing in Client region


Once all the major test cases are passed and no blockers are there in the build, build will be deployed in client region and team performs the interface testing. SQA team sends the release notes, if no major issues are observed

Security Testing

 SQA team performs security testing once the application is stable and intimates any issues identified. From here again bug life cycle starts.

Performance Testing

 SQA team performs performance testing once the application is stable and intimates any issues identified. From here again bug life cycle starts.

Web Services Testing

·         Thoroughly understand the requirements from the specifications.
·         List out the services provided by the vendor and the in-scope services.
·         In general companies prefer to perform handshaking testing before functional testing.
·         Prepare the request XML based on the data mapping provided by the vendor.
·         Make sure you prepare request XML using BVA and ECP testing techniques and also satisfying below conditions.
A.      All mandatory information and no optional information
B.      All mandatory information and all optional information
C.      Missing mandatory information and all optional information
·         Post the XML to vendor and validate the response XML's received from the vendor i.e., receiving success acknowledgments for the requests satisfying happy flow and Failure for the rest of XML's.
·         Validate whether the failure responses or acknowledgments carry proper error messages or not.
·         Once handshaking testing is success then go for functional testing. i.e., integrate the web service to application and invoke XML through appropriate triggering point.
·         Here validate the application generated XML with the data map; make sure all mandatory information within valid boundaries and classes exists, any optional information available in application also available in the request XML.
·         Validate the responses received and the response data to be stored in database are stored or not, also any files received in the XML are properly decoded and stored in respective places or not.
·         Validate any subsequent events to be carried out based on the vendor response are taken care by the application as expected or not.
·         Validate the application behavior when invalid XML is received from the vendor.
·         Once all results are satisfactory then go for load test by increasing the requests and also by increasing the responses with different file sizes.

Web Services advantages and disadvantages:


Advantages:


1. Web Services are virtually platform-independent
2. Security (such as SSL) is already built-in. HTTP has support for secure socket layer (SSL).
3. Web services are re-usable i.e., web service developed for one client can be used for another client with minimal or no changes.

4. The HTTP standard is allowing more systems to communicate with one another.
5. SOAP (built on XML) standardizes the messaging capability on different systems.
6. UDDI standardizes the publishing and finding of Web services.
7. WSDL standardizes the description of Web services so providers and requesters are speaking the same language.


Disadvantages:


1. Web service requests are larger than requests encoded with a binary protocol. The extra size is really only an issue over low-speed connections, or over extremely busy connections.
2. Connecting to the servers longer times is not possible. For this extra effort is required.
3. A server must usually rely on a timeout mechanism to determine that a client is no longer active. If a server doesn't receive a request from a client after a predetermined amount of time, it assumes that the client is inactive and removes any client information it was keeping. This extra overhead means more work for Web service developers.

Thursday, December 26, 2013

ETL Testing

ETL - Extract, Transform and Load.



Extract:

Extracting a desired subset of data from database.


Transform: 

Converting the extracted data into the required form using rules or lookup tables.
Cleaning (e.g., "Male" to "M" and "Female" to "F" etc.)
Filtering (e.g., selecting only certain columns to load)
Splitting multiple columns into a column (Last Name and First Name into Full Name) and vice versa etc…


Load:

Writing the resulting data (either all of the subset or just the changes) to a target database


Data Validation:

1.     Are all the required columns in destination are with expected constraints (NOT NULL, UNIQUE, Primary Key, Foreign key, Check, Default and Surrogate keys etc)?
2.     Is number of rows count in source matches with destination?
3.     Is data transformed correctly according to system requirements and business rules?
4.     Are there any duplicate records in destination?
5.     Is source and destination data apart from the columns on which business rules are applied are exactly same?