Test Participation - Project Office Staff. The project office should participate in testing as soon as possible. This may not be possible if the contractor performs some or all of the development at a remote location. At a minimum, the project office should participate in System Testing and all subsequent test phases. Where possible, the project office should participate in Functional and Integration testing. If the State will be maintaining the system, then the M&O staff should participate in unit testing, if possible. In some cases, the project office staff may request the IV&V vendor to participate in or execute some of the test phases to ensure an un-biased third-party opinion on the status of the system.
Test Participation - User and Sponsor. Often the sponsor and user elect to not participate until Acceptance Testing. However, SID recommends that the User participate or at least observe System Testing, and that the User and Sponsor participate as testers during Acceptance Testing. The User and Sponsor should participate in any test that formally verifies a business requirement to ensure their needs
have been addressed.
Test Environments. The Contractor usually provides the development and test environments, in addition to the production environment. How many environments, and which test environments can be co-located on the same hardware must be decided. If some of the development is being performed offsite, the RFP/ITP/contract should indicated which types of testing may be performed remotely and which must be performed on-site. Another consideration is whether the test environments are considered deliverables which will be retained by the State, or if the test environments remain the property of the Contractor.
Approach to Testing External Interfaces. Testing external interfaces is critical to ensuring a working system, and may help to identify performance issues before beginning production. Some external organizations have dedicated test environments, but most do not. Thus the Project Office must determine how to approach and coordinate testing of these interfaces. A tradeoff must be made about a reasonable level of confidence in the system/testing and the amount of risk the project is willing to accept, vs. the amount of work, coordination and ability of the external organization to participate in testing. The best approach is to include the external organization in the planning process early to determine what is and is not possible.
Approach to Testing COTS products. Although most COTS products are assumed to perform. correctly, there is some testing required to ensure that the COTS product correctly interfaces and supports the rest of the system. For any COTS other than the Operating System and DBMS, the outputs should be verified for typical and error cases. If data is being interchanged, then input and output formats should be verified for correctness. COTS testing should begin in parallel with Integration testing.
Scope of Acceptance Testing. The scope of acceptance testing may depend on what the Contractor is responsible for. Often testing needs to include the business processes, help desk functions (including knowledge base and procedures), backup and recovery, disaster recovery features, system administration tools, specialized hardware, M&O procedures, year-end and quarterly reports, and other user documentation.
Verification of Un-testable Requirements. In some cases, it may be difficult or impractical to test a given requirement. A method of verifying such requirements should be established. These un-testable requirements should be included in a test procedure/script(s) and verified during or just prior to Acceptance Test. The method of verification and appropriate witnesses and supporting documentation should be documented. Typical verification methods include code inspection, simulation using test tools, or, as a last resort, a certification letter from the contractor indicating they will be responsible for any damages resulting from failure of the requirement.
Criteria for Acceptance of the System. The criteria for acceptance is a critical decision that must be documented. Although not all criteria may be identified during the Planning phase, the majority should be documented as part of the RFP/ITP and/or contract. Acceptance criteria typically include (but are not limited to) satisfaction of all requirements (as stated in the RFP/ITP/contract and any associated change orders), approval of all deliverables, and satisfaction of all performance requirements. Some projects have required the system to be in production for a set period of time (to test system stability and its ability to satisfy the user's business needs) prior to conferring acceptance.
Pilot or Field Testing. The Project Office must decide if a pilot or field test (or several pilot/field tests) are warranted based on the type and complexity of the system being developed. The project should have an explicit, stated reason for conducting a pilot and a specific goal (e.g., verifying interfaces with other co-resident applications on the user's desktop). The type of user environment, volume of workload, types of work processed, location, and impact to day-to-day operations should be considered when choosing a pilot location. The outcomes of testing should also be considered: what happens if the pilot fails? what happens if it is successful? what constitutes "success" for the pilot? .
Performance and Capacity Requirements/Testing. Performance and capacity testing is critical for any system. The Project Office must work with the User and Sponsor to identify the performance and capacity requirements and then to determine how to verify the requirements have been satisfied. Large amounts of data will be required, and responsibility for gathering or generating this data must be determined. Specific methods formulas for measuring performance and capacity must be derived and reviewed to ensure that they are fair (often the Contractor does not have control over all of the network or the transmission lines; these should be factored out of the equation).
Friday, April 2, 2010
Typical test issues
Regression VS Retesting
Regression testing:-
Regression testing is a style of testing that focuses on retesting after changes are made. In traditional regression testing, we reuse the same tests (the regression tests). In risk-oriented regression testing, we test the same areas as before, but we use different (increasingly complex) tests.
Regression testing attempts to mitigate two risks:
• A change that was intended to fix a bug failed.
• Some change had a side effect, unfixing an old bug or introducing a new bug.
The essence of regression testing is exposure of problems that shouldn't be there, either because they were exterminated before or they weren't in the product the last time(s) it was tested.
Retesting
Retesting is a measurement or control process, a means of assuring that the program is as stable as it was previously.
For regression testing we execute the failed test cases (also updated and added testcases) and for retesting we use to execute passed testcases. So
Regression:- 10 testcases
Retesting:- 90 testcases.
Web Testing
Web Testing
Web-based applications present new challenges, these challenges include:
- Short release cycles;
- Constantly Changing Technology;
- Possible huge number of users during initial website launch;
- Inability to control the user's running environment;
- 24-hour availability of the web site.
The quality of a website must be evident from the Onset. Any difficulty whether in response time, accuracy of information, or ease of use-will compel the user to click to a competitor's site. Such problems translate into lost of users, lost sales, and poor company image.
To overcome these types of problems, use the following techniques:
1. Functionality Testing
Functionality testing involves making Sure the features that most affect user interactions work properly. These include :
· forms
· searches
· pop-up windows
· shopping carts
· online payments
2. Usability Testing:
Many users have low tolerance for anything that is difficult to use or that does not work. A user's first impression of the site is important, and many websites have become cluttered with an increasing number of features. For general-use websites frustrated users can easily click over a competitor's site.
Usability testing involves following main steps
· identify the website's purpose;
· identify the indented users;
· define tests and conduct the usability testing
· analyze the acquired information
3. Navigation Testing :
Good Navigation is an essential part of a website, especially those that are complex and provide a lot of information. Assessing navigation is a major part of usability Testing.
4. Forms Testing:
Websites that use forms need tests to ensure that each field works properly and that the forms posts all data as intended by the designer.
5. Page Content Testing:
Each web page must be tested for correct content from the user perspective for correct content from the user perspective. These tests fall into two categories: ensuring that each component functions correctly and ensuring that the content of each is correct.
6. Configuration and Compatibility Testing :
A key challenge for web applications is ensuring that the user sees a web page as the designer intended. The user can select different browser software and browser options, use different network software and on-line service, and run other concurrent applications. We execute the application under every browser/platform combination to ensure the web sites work properly under various environments.
7. Reliability and Availability Testing :
A key requirement o a website is that it Be available whenever the user requests it, after 24-hours a day, every day. The number of users accessing web site simultaneously may also affect the site's availability.
8. Performance Testing :
Performance Testing, which evaluates System performance under normal and heavy usage, is crucial to success of any web application. A system that takes for long to respond may frustrate the user who can then quickly move to a competitor's site. Given enough time, every page request will eventually be delivered. Performance testing seeks to ensure that the website server responds to browser requests within defined parameters.
9. Load Testing :
The purpose of Load testing is to model real world experiences, typically by generating many simultaneous users accessing the website. We use automation tools to increases the ability to conduct a valid load test, because it emulates thousand of users by sending simultaneous requests to the application or the server.
10. Stress Testing :
Stress Testing consists of subjecting the system to varying and maximum loads to evaluate the resulting performance. We use automated test tools to simulate loads on website and execute the tests continuously for several hours or days.
11. Security Testing :
Security is a primary concern when communicating and conducting business- especially sensitive and business- critical transactions - over the internet. The user wants assurance that personal and financial information is secure. Finding the vulnerabilities in an application that would grant an unauthorized user access to the system is important.
Difference between webserver & Application Server :
| Web Server | Application server |
| Webserver serves pages for viewing in web browser | application server provides exposes business logic for client applications through various protocols |
| Webserver exclusively handles http requests | Application server serves bussiness logic to application programs through any number of protocols. |
| Webserver delegation model is fairly simple,when the request comes into the webserver,it simply passes the request to the program best able to handle it(Server side program). It may not support transactions and database connection pooling | Application server is more capable of dynamic behaviour than webserver. We can also configure application server to work as a webserver.Simply applic! ation server is a superset of webserver. |
| Web Server serves static HTML pages or gifs, jpegs, etc., and can also run code written in CGI, JSP etc. A Web server handles the HTTP protocol. Eg of some web server are IIS or apache | An Application Server is used to run business logic or dynamically generated presentation code. It can either be .NET based or J2EE based (BEA WebLogic Server, IBM WebSphere, JBoss). |
| A J2EE application server runs servlets and JSPs (infact a part of the app server called web container is responsible for running servlets and JSPs) that are used to create HTML pages dynamically. In addition, J2EE application server can run EJBs - which are used to execute business logic. | A J2EE application server runs servlets and JSPs (infact a part of the app server called web container is responsible for running servlets and JSPs) that are used to create HTML |
The QA Philosophy
The QA Philosophy The inherent philosophy of Quality Assurance for software systems development is to ensure the system meets or exceeds the agreed upon requirements of the end-users; thus creating a high-quality, fully-functional and user-friendly application
Project Quality Management
•all activities of the overall management function that determines the quality policy, objectives and responsibilities…
•“implements them by means such as quality planning, quality control, quality assurance, and quality improvement, within the quality system”
Quality Assurance:
O Quality Assurance is involved in the entire project development life cycle
O Quality Assurance is a commitment by all project participants to the Total Quality of the Project.
The QA Process in Software Life Cycle :
Phase I: Requirements Gathering, Documentation and Agreement
Phase II: Establishing Project Standards
Phase III: Test Planning
Phase IV: Test Case Development
Phase V: QA Testing
Phase VI: User Acceptance Testing
Phase VII: System Validation
Difference between CMM & ISO
•CMM emphasizes continuous improvement
•ISO deals with minimum criteria of quality systems
•An ISO 9001-compliant organization would not necessarily satisfy all of the CMM level 2 key process areas (it would satisfy most of the level 2 goals and many level 3 goals.
•Some key practices in CMM that are not addressed in ISO 9000, it is possible for a level 1 organization to receive 9001 registration; similarly, there are areas addressed by ISO 9001 that are not addressed in the CMM.
•A level 3 organization would have little difficulty in obtaining ISO 9001
Capability Maturity Model
•Developed by the software community in 1986 with leadership from the SEI.
•Has become a de facto standard for assessing and improving processes related to software development
•Has evolved into a process maturity framework
•Provides guidance for measuring software process maturity
•Helps establish process improvement programs
The CMM is organized into five maturity levels:
–Initial
–Repeatable
–Defined
–Manageable
–Optimizing
•Except for Level 1 :
each maturity level decomposes into several key process areas that indicate the areas an organization should focus on to improve its software process.
Level 2 - Repeatable:
•Key practice areas –Requirements management –Software project planning –Software project tracking & oversight –Software subcontract management –Software quality assurance –Software configuration management
Level 3 - Defined:
•Key practice areas
–Organization process focus
–Organization process definition
–Training program
–Integrated software management
–Software product engineering
–Intergroup coordination
–Peer reviews
Level 4 - Manageable:
•Key practice areas
•Quantitative Process Management
•Software Quality Management
Level 5 - Optimizing:
Key practice areas
Defect prevention Technology change management
Process change management
Meetings
Client Meetings:
Some Time client will call testing team, find the staus of testing process.If Test Scenarios are created some time you have to discuss with the client regarding the scenarios.Some time you can directly talk to client regarding schedule of release final build.
Team Meeting:
Every End of Session there will be a meeting in between team,Reagarding Test Schedules, Reagrding Bug...
Staus Meeting:
Generally Every weekend This Meeting will held,Here discussion on Testing Process, How many Bugs raised in the last week, What type of bugs raiised(critical,Low..),Proceding Steps to the comeing week..
#. Obtain requirements, functional design, and internal design specifications and other necessary documents
#. Obtain budget and schedule requirements
#. Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
#. Determine project context, relative to the existing quality culture of the organization and business, and how it might impact testing scope, aproaches, and methods.
#. Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
#. Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
#. Determine test environment requirements (hardware, software, communications, etc.)
#. Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
#. Determine test input data requirements
#. Identify tasks, those responsible for tasks, and labor requirements
#. Set schedule estimates, timelines, milestones
#. Determine input equivalence classes, boundary value analyses, error classes
#. Prepare test plan document and have needed reviews/approvals
#. Write test cases
#. Have needed reviews/inspections/approvals of test cases
#. Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
#. Obtain and install software releases
#. Perform tests
#. Evaluate and report results
#. Track problems/bugs and fixes
#. Retest as needed
#. Maintain and update test plans, test cases, test environment, and testware through life cycle
What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed.
Reviews:
Reviews are conducted during and at the end of each phase of the life cycle to determine whether established requirements, design concepts, and specifications have been met. Reviews consist of the presentation of material to a review board or panel. Reviews are most effective when conducted by personnel who have not been directly involved in the development of the software being reviewed.
Informal reviews are conducted on an as-needed basis. The developer chooses a review panel and provides and/or presents the material to be reviewed. The material may be as informal as a computer listing or hand-written documentation.
Formal reviews are conducted at the end of each life cycle phase. The acquirer of the software appoints the formal review panel or board, who may make or affect a go/no-go decision to proceed to the next step of the life cycle. Formal reviews include the Software Requirements Review, the Software Preliminary Design Review, the Software Critical Design Review, and the Software Test Readiness Review.
Defect Metrics
Analysis on the defect report is done for management and client information. These are categorized as
Defect Age: Defect age is the time duration between the point of introduction of defect to the point of closure of the defect. This would give a fair idea on the defect set to be included for smoke test during Regression
Defect Analysis: The analysis of the defects can be done based on the severity, occurrence and category of the defects. As an example Defect Density is a metric which gives the ratio of defects in specific modules to the total defects in the application. Further analysis and derivation of metrics can be done based on the various components of the defect management.
Daily Summary Data :
In addition to entering new bugs and closing fixed bug in the bug tracking application,
• Number of test cases completed
• Number of new issues identified and reported
• Number of test cases, which failed
• Number of test cased blocked
• The executed test plans
• The current list of existing bugs by severity
• The test-tracking document. A sample test tracking document is show
Weekly Summary Report :
At the end of each week, creates a weekly report to provide our clients additional information. The weekly report contains bug information by test area.
End of Cycle Reports
QA engineers execute all test cases for a build, supply our clients a complete set of test results for the cycle. provide the following information:
• Each completed test plan
• List of bugs found in this testing cycle
• List of bugs fixed in this testing cycle
• List of bugs deferred to a later release
• Full test tracking document for the completed cycle
Types of Defects
Defects that are detected by the tester are classified into categories by the nature of the defect. The following are the classification
Showstopper (X): The impact of the defect is severe and the system cannot go into the production environment without resolving the defect since an interim solution may not be available.
Critical (C): The impact of the defect is severe, however an interim solution is available. The defect should not hinder the test process in any way.
Non critical (N): All defects that are not in the X or C category are deemed to be in the N category. These are also the defects that could potentially be resolved via documentation and user training. These can be GraphicUser Interface (GUI) defects are some minor field level observations.
Defect reporting by tester :
Defects or Bugs when detected in the application by the tester must be duly reported through an automated tool.
Particulars that have to be filled by a tester are :
Defect Id: Number associated with a particular defect, and henceforth referred by its ID
Date of execution: The date on which the test case which resulted in a defect was executed
Defect Category: These are explained in the next section, ideally decided by the test leader
Severity: As explained, it can be Critical, Non-Critical and Showstopper
Module ID: Module in which the defect occurred
Status: Raised, Authorized, Deferred, Fixed, Re-raised, Closed and Duplicate.
Defect description: Description as to how the defect was found, the exact steps that should be taken to simulate the defect, other notes and attachments if any.
Test Case Reference No: The number of the test case and script in combination which resulted in the defect
Owner: The name of the tester who executed the test case
Test case description: The instructions in the test cases for the step in which the error occurred
Expected Result: The expected result after the execution of the instructions in the test case descriptions
History of the defect: Normally taken care of the automated tool used for defect tracking and reporting.
Attachments: The screen shot showing the defect should be captured and attached
Responsibility. Identified team member of the development team for fixing the defect.
Monday, March 29, 2010
Test scenarios for testing a web site
As a Tester you should test GUI of the website,test whether the page layout and design elements are consistent through out the site,Whether all the links provided in the website are working properly,What are the expected loads on the server? performance of the website (check for webserver response time and database query time)under heavy loads.
The key things are:
1. UI testing
2. Session
3. Basic functionality
4. Negative testing
5. Penetration testing
5. Broken links
6. URL testing
7. Orphan page testing
TESTCASE :
. A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly.At this stage, the Tester has clarity on how the application is to be tested. It now, becomes necessary to aid the actual test action with test cases. Test cases are written based on the test conditions. It is the phrased form of test conditions, which becomes readable and understandable by all.
A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
Description: Here the details of the test on a specification or condition are written
Data and Pre-requirements: Here either the data for the test or specification is mentioned. Pre-requirements for the test to be executed should also be clearly mentioned.
Expected Results: The expected result on execution of the instruction in the description is mentioned. In general, it should reflect, in detail the result of the test execution.
Example
Description: Click on the hyperlink 'New Deposit' at the top left hand corner of the Main
Menu Screen
Expected Result: New Time deposit Screen should be displayed .Customer contact date should be prefilled with the system date
Pre-Requirements
Test cases cannot generally be executed with normal state of the application. Below is a list of possible pre-requirements that could be attached to the test case:
1. Enable or disable external interfaces
Example,
Reuters, a Foreign exchange rate information service organization server to be connected
to the application
Data definition
Data for executing the test cases should be clearly defined in the test cases. They should indicate the values that will be entered into the fields and also indicate the default values of the field.
Example:
Description: Enter client's name
Data: John Smith
(Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible. )
What is Bug : If the sofware does not meet the below criteria then it is bug.
- Any thing which is not defined by the client
- If Excess Things are added in the software
- software does not produce a expected result
- it is not userfriendly
What is the diffence between bug and error:
Error is a programitical mistake , if the function is not responding with expected result then it is error,Bug is any thing which is not added or excess added in to software or it is functionally not well defined and it is not a user friendly software.Then errors are also comes under bug.
Life cycle of a defect is explained diagrammatically below:
1. New:When bug raises then it is in the
2.Open : Developer Check the Bug Then it is in the Open state
3.Fixed : Developer Fixes the Bug ,
4 Close :Tester Checks again ,if bug is not raised then it is
5.Reopen: Again It is raised then it is in
Testing Classifications
Testing can be basically classified as :
White Box Testing
• Aims to establish that the code works as designed
• Examines the internal structure and implementation of the program
• Target specific paths through the program
• Needs accurate knowledge of the design, implementation and code
Black box testing
• Aims to establish that the code meets the requirements
• Tends to be applied later in the lifecycle
• Mainly aimed at finding deviations in behavior from the specification or requirement
• Causes are inputs, effects are observable outputs
Alpha Testing
A customer conducts the Alpha testing at the developer's site. The software is used in a natural setting with the developer recording errors and usage problems. Alpha tests are conducted in the controlled environment by the developer.
Beta Testing :
The beta testing is conducted at one or more customer sites by the end user{s) of the software. The developer will not be present in the customer's place. So, the Beta test is a 'live' application of the software in an environment that cannot be controlled by a developer. The customer records all the problems (real or apparent) that are encountered during the beta testing and reports to the developer at regular interval. As a result of problems reported during beta test.
Integrated Systems Testing
Integrated System Testing (IST) is a systematic technique for validating the construction of the overall Software structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested modules and test the overall Software structure that has been dictated by design. IST can be done either as Top down integration or Bottom up Integration
|
|
User Acceptance Testing:
User Acceptance Testing (UAT) is performed by Users or on behalf of the users to ensure that the Software functions in accordance with the Business Requirement Document. UAT focuses on the following aspects:
• All functional requirements are satisfied
• All performance requirements are achieved
• Other requirements like transportability, compatibility, error recovery etc. are satisfied
• Acceptance criteria specified by the user is met.
Sample Entry and Exit Criteria for User Acceptance Testing
Entry Criteria
♦ Integration testing signoff was obtained
♦ Business requirements have been met or renegotiated with the Business Sponsor or representative
♦ UAT test scripts are ready for execution
♦ The testing environment is established
♦ Security requirements have been documented and necessary user access obtained
Exit Criteria
♦ UAT has been completed and approved by the user community in a transition meeting
♦ Change control is managing requested modifications and enhancements
♦ Business sponsor agrees that known defects do not impact a production release—no remaining defects are rated 3, 2, or 1
PRODUCTION VERIFICATION TESTING :
Production verification testing is a final opportunity to determine if the software is ready for release. Its purpose is to simulate the production cutover as closely as possible and for a period of time simulate real business activity. As a sort of full dress rehearsal, it should identify anomalies or unexpected changes to existing processes introduced by the new application. For mission critical applications the importance of this testing cannot be overstated.
The application should be completely removed from the test environment and then completely reinstalled exactly as it will be in the production implementation. Then mock production runs will verify that the existing business process flows, interfaces, and batch processes continue to run correctly. Unlike parallel testing in which the old and new
systems are run side-by-side, mock processing may not provide accurate data handling results due to limitations of the testing database or the source data.
Sample Entry and Exit Criteria for Production Verification Testing
Entry Criteria
♦ UAT testing has been completed and approved by all necessary parties
♦ Known defects have been documented
♦ Migration package documentation has been completed, reviewed, and approved by the production systems manager
Exit Criteria
♦ Package migration is complete
♦ Installation testing has been performed and documented and the results have been signed off
♦ Mock testing has been documented, reviewed, and approved
♦ All tests show that the application will not adversely affect the production environment
♦ A System Change Record with approvals has been prepared
Performance Testing:
1. Performance testing is designed to test run time performance of software within the context of an integrated system. It is not until all systems elements are fully integrated and certified as free of defects the true performance of a system can be ascertained.
2. Performance tests are often coupled with stress testing and often require both hardware and software infrastructure. That is, it is necessary to measure resource utilization in an exacting fashion. External instrumentation can monitor intervals, log events. By instrumenting the system, the tester can uncover situations that lead to degradations and possible system failure.
Security testing:
If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorizedinternal or external access.
Exploratory Testing:
Often taken to mean a creative, internal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
'Benefits Realization tests:
With the increased focus on the value of Business returns obtained from investments in information technology,this type of test or analysis is becoming more critical.The benefits realizatioon test is a test or analysis conducted after an application is moved into production inorder to determine whether the application is likely to deliver the original projected benefits.The analysis is usullaly conducted by the business user or client group who requested the project and results are reported back to executive management.
Mutation Testing:
Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.
Sanity testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
UNIT TESTING :
Definition: By knowing the inner logic the program the test what you conduct is Unit Testing. or Testing the piece/unit of a program
Unit testing is a procedure used to validate that a particular module of source code is working properly. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed.
Benefits:
The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits.
1) Facilitates Change
2) Simplifies Integration
3) Documentation
4) Separation of Interface from Implementation
earn System Testing:
System testing is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of Black box testing, and as such, should require no knowledge of the inner design of the code
or.logic.
System testing is actually done to the entire system against the Functional Requirement Specifications (FRS) and/or the System Requirement Specification (SRS). Moreover, the System testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and test not only the design, but also the behavior and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software/hardware requirements specifications.Remainaing All Testing Models comes under System Testing.
System Testing
:
Test Stretegy
Test Stretegy :
Actual writing of a strategy involves aspects, which define other issues between the Testing organization and the client. Testers must basically understand some of the issues that are discussed in the strategy document, which are outlined below
1. End-to-End: :
The test path uses the entire flow provided in the application for completion of a specified task. Within this process various test conditions and values are covered and results analyzed. There maybe a possibility of reportingseveral defects relating to the segments while covering the test path. The advantage of using this approach is to minimize combination and permutation of conditions/values and ensure coverage and integration.
2. Automation Strategy:
Automation of testing process is done to reduce the effort during regression testing. In some cases automating the entire testing process may not possible due to technical and time constraints.
3. Performance Strategy:
The client specifies the standards for the performance testing. It generally contains
• Response time
• Number of Virtual UsersUsing the above information, a Usage Pattern of the application is derived and documented in the strategy.
4. Risk Analysis
Risk's associated with projects are analyzed and mitigation's are documented in this document,
Schedule Risk: Factors that may affect the schedule of testing are discussed.
Technology Risk: Risks on the hardware and software of the application are discussed here
Resource Risk: Test team availability on slippage of the project schedule is discussed.
Support Risk: Clarifications required on the specification and availability of personnel for the same is discussed.
5. Effort Estimation
The function points in the Functional Specifications will be used as the basis for the purpose of estimating the effort needed for the project. The average of the different estimates from the Peers in the test team will be taken as the basis for calculation of the effort required.
6. Infrastructure
Hardware and software requirements for the testing the application are documented. Apart from this, any other requirement should also be documented. Infrastructure that has to be provided by the client is also specified.
Software Requirements Specification (SRS) document
Software Requirements Specification (SRS) document, containing:
• Introduction
Purpose
Scope
Major Constraints and References
• Functional Requirements
Context Diagram
Functional Decomposition Diagram
System Functions
Database Requirements
User Interface Requirements
External Software Interface / Compatibility Requirements
Reports Requirements
Security Requirements
• Use Case Specifications
• Acceptance Criteria
Design Document:
1. The developers produce a "System Design" from the "System Specification". This takes the features required and maps them to various components, and defines the relationships between these components. The whole design should result in a detailed system design that will achieve what is required by the "System Specification
1.This process of designing exactly of the specifications are to be implemented. How the software to writen, including object modelwith properties and methods, Databse Designing,Cleint server architecture.
Out put of this Phase
- Detailed Design Document, containing:
• Architecture Diagram
• Detailed Sequence Diagram
• Detailed Class Diagrams
• Detailed Context Object Diagrams
• Implementation Plan for each Function
Stored Procedures
Function Description
•PhysicalDataMode
Project Manaager :
- Preparation of Software Requirements Specification (SRS)
- Formation Development Team,Test Team
- Management of requirements through out the project life cycle activities
- Preparation of Detailed Design Document
- Unit Test cases and Integration Test cases
- Guidance on programming and related coding conventions / standards
QA Manager :
- Preparation of System Test Plan
- Formation of Test Team
- Schedule Preparation
- Module Allocation
- Reviews on Test Process
- Client Intraction
- Verify Status Reports
Teast Team(Testers & Test Lead) :
Testing, is the core competence of any Testing Organization.
- Understand the Application Under Test
- Prepare test strategy
- Assist with preparation of test plan.
- Design high-level conditions
- Develop test scripts
- Understand the data involved
- Execute all assigned test cases
- Record defects in the defect tracking system
- Retest fixed defects
- Assist the test leader with his/her duties
- Provide feedback in defect triages
- Automate test scripts
- Understanding of SQL
Test Plan
This document is a deliverable to client. It contains actual plan for test execution with details to the minute.
Test Execution Sequence
Test scripts can either be executed in a random format or in an sequential fashion. Some applications have concepts that would require sequencing of the test cases before actual execution. The details of the execution are documented in the test plan.
Sequencing can also be done on the modules of the application, as one module would populate or formulate information required for another.
Allocation of test cases among the team
The Test team should decide on the resources that would execute the test scripts. Ideally, the tester who designed the test script for the module executes the test. In some cases, due to shortage of time or resource at that point of time, additional test scripts might have to be executed by some members of the team.
Clear documentation of responsibilities is done in the test plan.
Allocation of test cases on different passes
All test scripts may not be possibly executed in the first passes. Some of the reasons for this could be
- Functionality may some-times be introduced at a later stage and application may not support it, or the test team may not be ready with the preparation
- External interfaces to the application may not be ready
- The client might choose to deliver some part of the application for testing and rest may be delivered during other passes
Time frames for the passes have to decided and committed to the clients well in advance to the start of test. Some of the factors consider for doings so are
Number of cases/scripts: Depending on the number of test scripts and the resource available, completion dates are prepared
Complexity of Testing: In some cases the number of test cases may be less but the complexity of the test may be a factor. The testing may involve time consuming calculations or responses from external interfaces etc
Number of Errors: This is done very exceptionally, Pre-IST testing is done to check the health of the application soon after the preparations are done. The number of errors that were reported should be taken as a benchmark