Jobs For Nagpur

Jobs For Nagpur
Get Jobs

February 2013

Software Testing Life Cycle (STLC)

Software Testing Life Cycle (STLC)

A Software Testing Life Cycle is made up of series of phases.
1.       Requirement Gathering and Analysis
Requirements analysis is critical to the success of any project. The scope and boundary of the proposed software solution is drawn. Identifying stakeholders such as customers, end-users, system administrators etc. is the next step in requirements analysis. This is one of the most important steps in the whole process as proper identification of stakeholders enables the business analyst to draw a road map for gathering requirements. Testing Team identifies the testable requirements. Requirement can be functional or non functional. Scope of Automation (if any) is also considered.
Activities
·         Prepare Requirement Traceability Matrix (RTM).
·         Identifying the approach or setting the priorities module wise.
·         Identification of areas to be tested automatically and those requiring manual testing
Out-Put After This Phase
·         Requirement Traceability Matrix (RTM).
2.       Test Planning
A test plan is a document is created which provides detail of a systematic approach to testing. Testing Effort and Cost Estimation for the project would be calculated.
Activities
·         Project scope and expectations definition
·         Technology and methodology selection
·         Preparation of test plan document for various types of testing to be performed.
·         Testing effort estimation 
·         Definition of QA metrics
·         Resource Planning and identifying the roles and responsibility. 
·         Testing Tool Selection.
Out-Put After This Phase
·         Test Plan
·         Testing Effort Estimation
3.       Test Case Development
After Requirement is freeze followed by initial understanding, testing team starts creating Test Case or Test Scripts along with test data, which are later reviewed followed by rectifying the issues reported by reviewer. Categorization of Test Case as per their priority is also set.
Activities
·         Create test cases or Test scripts (if applicable).
·         Categorization of Test Case.
·         Create Test Data
Out-Put After This Phase
·         Test Cases/Scripts
·         Test Data
4.       Test Environment Setup
A testing environment is a setup of software and hardware on which the testing team is going to perform the testing of the software product. This setup consists of the physical setup of hardware and software setup that includes Server Operating system, client operating system, database server, front end running environment, browser (if web application) and other software components required to run this software product. These setups are done by support staff. Testing team has to ensure the conditions are met before testing is taken off. Followed by Smoke Test which verifies the Test Environment as well as stability of the build delivered to Test Team.
Activities
·         Ensure the required Hardware and Software or different combination of machines are ready
·         Perform a Smoke Test on the build delivered for Testing
Out-Put After This Phase
·         Test Machine or Test Lab
·         Smoke Test Result
5.       Test Case Execution
Test Case execution is a process of executing test cases/scripts in a logical sequence with specific test data (if available). If any Test Case/Script or Test Scenario fails, Testing Team logs the bug in Bug Tracking tool (Bugzilla, Jira, TTPro, etc.). Simultaneously a dedicated team of developers would be fixing the bugs and release the fixes in next build. Testing team shall verify the reported bug and accordingly update the Bugs logged. This cycle continues till all the bugs identified in product are fixed. Finally a Regression or Ad-hoc Testing is performed after which Test Report is prepared if all goes well.
Activities
·         Execution of Test Cases
·         Log bugs in bug tracking tool
·         Create Test Result document
·         Map defects to Test Cases in RTM
·         Verify the bug logged in new build
·         Update the bug status in bug reporting tool as per verification status
Out-Put After This Phase
·         Test Result
·         Defect Report
·         RTM with execution status
6.       Closure - Product Release
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 noted down and used as a reference for future projects. Later a Causal Analysis and Resolution (CAR) Report is prepared where in best practices and cause of failures occurred are noted down.
 Activities
·         Test Metrics based on Test coverage, Cost, Time, Quality etc is prepared
·         Test Closure Report Preparation
·         Test Result Analysis is performed to calculate the defect distribution by type and severity.
·         Causal Analysis and Resolution (CAR) Report is prepared
Out-Put After This Phase
·         Test Closure Report 
·         Test Metrics
·         Causal Analysis and Resolution (CAR) Report
Note: There are different process and methodologies followed in various organizations. The above content is as per my experience in industry so far.
Please feel free to write comments if you like my post or else if your opinion is different or you may like to add any more points in them.

=====================================================================
Sponsor Ads

1) Online World Travel Guide
2) Cheap World Travelers
3) World travelers
4) World Travel Home


Bug Life Cycle Or Defect Life Cycle

Defect (Bug) Life Cycle

A Defect/Bug Life Cycle is made up of series of phases.
1. New
    When the bug is identified and logged in bug tracking tool for the first time, its state will be "NEW".
2. Open / Closed
    After a QA has posted a bug, the QA lead validates the bug. If bug is valid then he changes the state as "OPEN" and if the bug is invalid then the lead changes its state to "CLOSED".
3. Assign
    After QA lead changes the state as "OPEN", he assigns the bug to corresponding developer or developer team lead and the bug status is changed to "ASSIGN".
4. Rejected:
    If the developer feels that the bug is not valid or it has some technical limitations and cannot be fixed, he rejects the bug. He changes the state of bug to "REJECTED".
5. Duplicate:
    If the bug is logged is repeated twice or the two bugs reported has alike results and steps to reproduce, then one bug status is changed to "DUPLICATE".   
6. Deferred:
    If the development team lead decides to fix the bug in next release due to lack of time or the priority of the bug is low then he changes the state to "DEFERRED", which is later changes to "ASSIGN" when the bug is taken in consideration to be fixed.
7. InTest
    Once the developer fixes the bug, he assigns the bug to the testing team for next round of testing. Before that he changes the state of bug to "IN TEST". It specifies that the bug has been fixed and is released to testing team.
8. Verified
    Once the bug is fixed and the status is changed to "IN TEST", the tester tests the bug. If the bug is not reproducible in the software, he changes the status to "VERIFIED".
9. Reopened
    Once the bug is fixed and the status is changed to "IN TEST", the tester tests the bug. If the bug is reproducible in the software, he changes the status to "REOPENED".
10. Closed
    After the bug status is changes to "REJECTED" or "DUPLICATE" or "VERIFIED" the QA Lead verifies the comments added by the development or Testing team. When he is satisfied with the comments he changes the state to "CLOSED".

Note: There are different process and methodologies followed in various organizations. The above content is as per my experience in industry so far.

Please feel free to write comments if you like my post or else if your opinion is different or you may like to add any more points in them.

Testing /QA Interview Questions And Answers


1) Software testing:  Software testing is a methodology to find bugs in the software
2) Software Development Life Cycle( SDLC):

3) Software Testing life Cycle (STLC):  Click Her For Detail
4) Positive test case: - Test to check whether the system do what it is suppose to do.ie, checking for valid values only.
5) Negative Test Case: - Test to check whether the system will do what it is not supposed to do.ie, checking for invalid values.
6) Verification: It is a set of activity which confirms that the software is created accordance to the specification
7) Validation: Is a set of activity which confirms software is created is linked to user requirement or not
8) Retesting: Failed test case are executed to ensure that defect is really fixed
9) Regression: all passed test cases are executed on related module to verify that there is no injection of new defect to change in one of the module
10) Static: Reviewing artifacts rather than executing code
11) Dynamic: Testing Perform by executing code by giving i/p and verify o/p
12) Smoke: Is a simple test condition to ensure that the software is working properly at gross level so that further testing is done
13) Sanity: It perform to verify whether the application function according to specification or not
14) Defect: Defect indicate difference between expected and actual behavior
15) Defect Life cycle Or Bug Life Cycle: Click Here For More Details
16) White Box: It is done by developer. This require knowledge of internal structure and code of that application
17) Type of white box: 1) Statement 2) Decision3) Condition 4) path 5) loop
18) Black box: This is done by tester it mainly focus on functional requirement. By providing set of I/P and observe output.
19) Black box type: 1) BVA 2)    Equivalence class partitioning               3) state transition
 20) Alpha: It is done at developer side under controlled environment. Here developer is present
21) Beta: It is conducted at one or more customer site in live environment by end user .here developer is not present
22) Agile testing: It is testing methodology goes hand in hand to an agile software development model. Here release are quicker (within 2-3 week) and incremental are iterative in nature

23) Development Model:
1) Waterfall: It is sequential model which process through Requirement-> Design->Coding->Testing
2) Spiral: Divided into 4 phase 1) Plan2) Design3) Prototype4) test .In this model software in series of incremental realized. As we process through iteration more complete versioned is engineered product are visible. It is useful when user/developer are not cleared about the solution to developed and needs evaluator approach 
3) Agile: Here release as frequently as every week rather than month and continuous changes in requirement and welcome to be integrated

24) V-Model:
         It is extension of water fall model .here both the aspect  quality control and quality assurance are covered. Indicates that testing exits in every phase of SDLC life cycle
 


25) Test Case: test case is a set of input and output .here we pass the set of input and observe the output and system behavior
26) Test Scenario: Test scenario is a high level definition .here one can write one or more test cases
Example login
27) Test plan: Defines purpose, scope, approach, resource, responsibility of testing activities
Steps: Test Id, Intro, Scope and limitation, Test Objective, Assumption, Risk analysis, feature to be tested/Not to be, Roles and Responsibility, schedule, Test environment

Newer Posts Older Posts

My Blog List

becomeatester.blogspot.com design and developed by Devashish Jain. Powered by Blogger.