Test Strategy:
A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.
In the test strategy is described how the product risks of the stakeholders are mitigated in the test levels, which test types are performed in the test levels, and which entry and exit criteria apply.
The test strategy is created based on development design documents. The system design document is the main one used and occasionally, the conceptual design document can be referred to. The design documents describe the functionalities of the software to be enabled in the upcoming release. For every set of development design, a corresponding test strategy should be created to test the new feature sets.
Components of Test Strategy:
Purpose: Testing Scope and Approach
Out of scope: release or phase specific
Data Preparation: flat file, manipulation of data in SQL queries, ETL for web application
Test Environment: ETL, Dev3, Cordinati, Tibco
Defect Management and roles and responsibility: who is defect coordinator, who is manager, who is tech lead.
Entrance Criteria: pre requsite for starting the testing, Requirement must be freeze, documents sign off, application must be ready, Test strategy must be review & approved, there is should be any show stopper.
Exit Criteria:
· All high defects must be closed, all open, medium defects must be backed logged status, with comment from project owners.
· All the defect must have a status.
· Exit report must be prepared and approved by the mangers.
Risks and Contingencies: What if code deliver is delayed, so how to plan our testing dates or resources etc or unstable environment.
Planning Assumptions: Test Execution Schedule: how many test cases, how many rounds of test case is required. Need to plan for buffer plan.
Testing Deliverables and Artifacts
Share point.
Project stake holder’s review and approvals
Everything needs to be approval.
Test Plan:
A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from Test Engineers.
Or
A high level test scenarios, Scope or understanding on the functionality
Test Cases:
A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not.
A test script in software testing is a set of instructions that will be performed on the system under test to test that the system functions as expected.
A test case is also called as test case
Components of test case:
Brief Description
Pre Requisite
Data dependencies
Test environments involved
Actions
Expected result
Actual Restult
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code.
If the actual result does not match with the expected result then it is called as a defect or Bug
Defect Life cycle:
Defect Life Cycle:
Newà Open à Review -> Fixed à Test Ready à Retest à Reopen -> Closed
New à Rejected (If the defect is not a defect)
How to determine Severity:
· High (with 4 to 6hrs)
· Medium
· low
· Show stopper(with in an hour, immediately)
Testing Methods:
Black Box
White Box
Grey Box
Defect Reports:
How many total test scripts, how many have been tested, how many passed, how many failed, how many application defect, how many environment defects.
Base document to prepare Test plan, test case.
Requirement Doc, Design Doc, Usecase & Artifacts
Test Levels:
Functional Testing Levels:
Unit Testing - “Unit testing” focuses on testing a unit of the code. A functionality, module etc..conditional statement, procedures.
Integration testing -This ‘level of testing’ focuses on testing the integration of “units of code” or components.
System Testing - System Testing’ is the next level of testing. It focuses on testing the system as a whole. Once the components are integrated, the system as a whole needs to be rigorously tested to ensure that it meets the Quality Standards.
Acceptance Testing (UAT)
Alpha testing & Beta testing: Staging database, before production, the tested coded will be deployed and then test environment.
Regression testing:
Smoke/Sanity Test: after every build,
Non Functional testing levels: performance, scalability, security
Performance or Load testing
Stability testing
Usability testing: user friendly
Security testing
Internationalization and localization
Testing processes
Waterfall development
Agile model
ETL Tool - Development: Abinitio
Database: Oracle 10g,
A sample testing cycle (STLC)
Although variations exist between organizations, there is a typical cycle for testing[33]. The sample below is common among organizations employing the Waterfall development model.
▪ Requirements analysis: Testing should begin in the requirements phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests work.
▪ Test planning: Test strategy, test plan, test bed creation. Since many activities will be carried out during testing, a plan is needed.
▪ Test development: Test procedures, test scenarios, test cases, test datasets, test scripts to use in testing software.
▪ Test execution: Testers execute the software based on the plans and test documents then report any errors found to the development team.
▪ Test reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.
▪ Test result analysis: Or Defect Analysis, is done by the development team usually along with the client, in order to decide what defects should be treated, fixed, rejected (i.e. found software working properly) or deferred to be dealt with later.
▪ Defect Retesting: Once a defect has been dealt with by the development team, it is retested by the testing team. AKA Resolution testing.
▪ Regression testing: It is common to have a small test program built of a subset of tests, for each integration of new, modified, or fixed software, in order to ensure that the latest delivery has not ruined anything, and that the software product as a whole is still working correctly.
Test Closure: Once the test meets the exit criteria, the activities such as capturing the key outputs, lessons learned, results, logs, documents related to the project are archived and used as a reference for future projects.
Current Project description:
Brief about project - Symphony intends to facilitate thousands of CitiFinancial employees which include Branch Manager, District Manage and senior executives. Around 2,100 branches across US, Canada and Puerto Rico are expected to use this application to serve CitiFinancial customers. This application is designed to serve day to day activities like Registering Personal loan Application, Loan Payments, Product Advisor, and Cash Drawer, update Customer Information Manage Product Insurance etc. Symphony project will eventually replace many manual and tedious processes that branch employees currently follow.
functionalites – Payment & Cash Drawer end to end testing
Role - Test Lead - Testing Co-ordinator(Defect Coordinator, onsite coordinator)
Responsibility & deliverables, - Preparing Test cases, Test Review, Managing Offshore Team, Involve in Requirements Analysis & reviews, Involved during workshop & meetings.
my role: I’ve involved in the end to end testing. In this project I’ve to focus on two things mainly, ETL Testing & Web application. So for both, I’ve extensively worked in black box & gray box testing. The basic system infrastructure here is like web application, Action (Main frames) which is the key for customer data, Tibco (integration), Oracle database.
Customer data will be extracted from the existing database and it will be generated as a flat file in space delimiter formatted, and then it will be sent to ETL team. ETL team will pick up the file and load the data in to new database.
For ETL mainly I’ll prepare test script based on the standard layout and validate the data. then we will extract the flat files into excel using excel marco,
Web App we do both black & Gray testing. Need to make sure, payment relate information is feed into database.
We will split the user stories, sometime, so we do black box & gray box for both ETL & web application.
User Interface testing: UI Spec documents, icons, images, buttons label. (black box testing)
General Responsibilities: daily defect calls, daily reports, offshore call,
Web Application testing: Chordiant.
Validation: we will validate the data, whether it has been pumped in properly. Functional testing, we will have around 20 to 30 thousand record.
Data Reconciliation: Data mapping,
Data reconciliations element level checking where each element is valid. This includes matching the source and reflecting an accurate, valid value.
Database reconciliation focuses on the integrity and quality of the entire database or data set. Database reconciliation is a superset of data reconciliation.
We frequently use data reconciliation to address the integrity or accuracy of individual records of data quantities. Database reconciliation is frequently discussed at the completion of a data migration effort where we want to understand if the validity of the entire data set is still intact.
Data integrity testing. We will test it by writing SQL queries.
Migrating data from old database to new database, space delimited.
Gray box: Running sql queries in the database, (data manipulations, data validation), Any thing we create in backend called gray box testing.
White box testing: getting into the code and validating the code & conditions.(validated java code).
No comments:
Post a Comment