Showing posts with label Manual Testing. Show all posts
Showing posts with label Manual Testing. Show all posts

December 3, 2010

Some helpful docs for testers

December 03, 2010 4
Some helpful docs for testers

Test Matrices sample

December 03, 2010 1
Test Matrices sample
Metrics means measurement. Metrics is just a series of measurements.
Test Matrices Sample ___________________________________
Question:
I need information about Metrics, which is used to find faults. it is something related with measurement. I need to know how it is used in Quality Assurance.

Answer:
You can measure the arrival and departure times of developers, if you have them clock in, but that won't tell you much since not all work is done in the office (and it doesn't mean that they're working when they're in the office). This is, however, still a metric.

The same holds for a true "quality metric". The most familiar one is defects per thousand lines of (uncommented) code. But this metric assumes that:
1) you count the lines of code
2) the complexity of the code isn't an issue
3) the programmers aren't playing games (like using continuance characters
so that what could have been written in one line isn't done in five lines)
4) all defects are uncovered in the code in a single pass
5) each defect discovered is all others
6) defects are uncovered in a linear manner between revisions or builds

The fact is that first you need to know what your goal is. Then you need to
discover or create a metric that will help you achieve that goal. Then you
need to implement it and be prepared to adjust it.

You can't use measurements (metrics) to find faults, at least not in software, so that's not a reasonable goal. You can use metrics to help determine if most of the defects have been discovered already. You can use them to tell you how much longer it will take to uncover a reasonable amount of defects. For either of these metrics you will need to know how previous projects of similar size and complexity (using similar languages, etc.) were done in order to get a reasonable comparison.




Test Case: File Open #
Test
Description
Test Cases/ Samples
Pass/
Fail
No. of
Bugs
Bug#
Comments
N/A
Setup for [Product Name] setup
-
-
-
 
1.1
Test that file types supported by the program can be opened
1.1
P/F
#
#
 
1.2
Verify all the different ways to open file (mouse, keyboard and accelerated keys)
 1.2
 P/F
 #
 #
 
1.3
Verify files can be open from the local drives as well as network
1.3
 P/F
#
#
 




For more information please visit....http://www.sqatester.com/

Test Plan sample

December 03, 2010 1
Test Plan sample
Test Plan Sample



Table of Contents
1. Introduction
  • Description of this Document
  • Related Documents
  • Schedule and Milestones

2. Resource Requirements
  • Hardware
  • Software

           o  Test Tools
Staffing
      Responsibilities
      Training
3. Features To Be Tested / Test Approach
  • New Features Testing
  • Regression Testing

4. Features Not To Be Tested

5. Test Deliverables

6. Dependencies/Risks

7. Entrance/Exit Criteria


1. Introduction


Description of this Document

This document is a Test Plan for the -Project name-, produced by Quality Assurance. It describes the testing strategy and approach to testing QA will use to validate the quality of this product prior to release. It also contains various resources required for the successful completion of this project.

The focus of the -Project name- is to support those new features that will allow easier development, deployment and maintenance of solutions built upon the -Project name-. Those features include:

[List of the features]
This release of the -Project name- will also include legacy bug fixing, and redesigning or including missing functionality from previous release
[List of the features]
The following implementations were made:
[List and description of implementations made]
Related Documents
[List of related documents such as: Functional Specifications, Design Specifications]


Schedule and Milestones
[Schedule information QA testing estimates]

2. Resource Requirements


Hardware
[List of hardware requirements]
Software
[List of software requirements: primary and secondary OS]
Test Tools
Apart from manual tests, the following tools will be used:

-
-
-

Staffing


Responsibilities
[List of QA team members and there responsibilities]
Training
[List of training's required]


3. Features To Be Tested / Test Approach
[List of the features to be tested]
Media Verification
[The process will include installing all possible products from the media and subjecting them to basic sanity testing.]


4. Features Not To Be Tested
[List of the features not to be tested]


5. Test Deliverables
[List of the test cases/matrices or there location]
[List of the features to be automated ]
6. Dependencies/Risks
Dependencies
Risks

7. Milestone Criteria




For more information please go through below link



How to Create a Requirements Traceability Matrix

December 03, 2010 14
How to Create a Requirements Traceability Matrix
A successful project cannot be achieved without the project manager having an excellent organizational skill set. Information must be readily available upon demand. A good project manager will be able to identify what works and what is broken in an instant. Having a requirements traceability matrix is an invaluable tool to accomplish this
.


Instructions

Things You'll Need:

  • Project deliverables
  • Business requirements catalog
  • Use cases
  1. Create a template. There are many on  the web from which to choose. The project manager, sponsor and decision makers will thank you when they are receiving information in a consistent and logical format.

  2. Transfer data from your Business Requirements Catalog. You will need, at bare minimum, the exact requirement identified from the Business Requirements Catalog that you need to have already created.

  3. Identify the requirement with a unique ID. The business requirements document should have already assigned an identifier that you will use in this matrix. If not, you will create one now and insert it next to the applicable requirement.

  4. Copy the Use Case ID into the traceability matrix. You may or may not have used use cases to develop your requirements. If you did, you will have an identifier on your use case. You must transfer the ID to this matrix in order to see out of what data or scenario this requirement was born.

  5. Insert the System Requirements Specification (SRS) ID into the traceability matrix. You might not be the actual author of the SRS, but there must be a line on the matrix to trace the business requirement to the corresponding system requirement needed.

  6. Insert the testing data into the traceability matrix. There are many different testing methods and procedures that can be used in any project. The traceability matrix must account for the types of tests used in this project. This should clearly indicate the specific test type, the date tested and the outcome of pass/fail.

  7. Review your data. Your matrix should now clearly show the specific deliverable requirements from conception clearly through testing. This will ensure that nothing gets moved into production haphazardly and when asked, the Project Manager now has this information at the ready.



Software Testing Life Cycle

December 03, 2010 4
Manual Testing
Manual testing plays a vital role in finding defects. Testers play the role of an end user, and use most of all features of the application to ensure correct behavior. For the completeness of testing, the tester follows a written test plan that leads through a set of test cases. Defect tracking tool are- Bugzilla, JIRA and Test Track Pro.  Etc…

STLC (Software Test Life Cycle)





Software Testing Life Cycle or STLC is a comprehensive group of testing related steps followed to deliver quality product. Testing has become an important phenomenon during and after development of any software project. The various steps in testing process are:
STLC
  • Test planning
This is the initial and key step in software testing. This step determines the overall flow of testing process starting from:
  • Requirement gathering, its analysis and specifications
  • Framing the test plan and test scenario
  • Preparing test cases and its approval
  • Tools selection and confirmation
We carry out our test planning on the basis of IEEE Standard for Software Test Documentation and other industry specifications.
  • Testing environment and harness preparation
This stage is defined by test automation framework design and development and test scripts creation. SCMS has state-of-the-art testing equipment, system software, and web middleware. This ensures creation of proper testing environment. It also helps in essentially decreasing the time for testing configurations deployment.
  • Test execution
The manual and automated software testing, as specified in the test plan, is applied in a dynamic state of code. The approaches and methods are utilized to validate the executable code developed meeting the specifications stated at start of software project.

For each of these types of testing we have established approaches, proven testing tools, and adjusted reporting documents templates. Testing techniques applied:
  • Black Box / White Box testing
  • Ad Hoc / Exploratory testing
  • Scripted testing
  • Test Reporting
We use the industry-recognized bug tracking tools like Jira, BugZilla. The test reports are well-documented and the spotted bugs are reported to the developer after the testing is completed.
  • Final reporting and analysis
This is final step of test cycle. It involves the final report preparation and project metrics generation. The defects spotted are analyzed and recommendations are made for improvements.







Below is another way of defining STLC

Test Requirements 

? Requirement Specification documents
? Functional Specification documents 
? Design Specification documents (use cases, etc) 
? Use case Documents 
? Test Trace-ability Matrix for identifying Test Coverage

Test Planning

? Test Scope, Test Environment
? Different Test phase and Test Methodologies
? Manual and Automation Testing
? Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc
? Evaluation & identification ? Test, Defect tracking tools

Test Environment Setup

? Test Bed installation and configuration
? Network connectivity?s
? All the Software/ tools Installation and configuration
? Coordination with Vendors and others

Test Design
? Test Traceability Matrix and Test coverage
? Test Scenarios Identification & Test Case preparation
? Test data and Test scripts preparation
? Test case reviews and Approval
? Base lining under Configuration Management

Test Automation

? Automation requirement identification
? Tool Evaluation and Identification.
? Designing or identifying Framework and scripting
? Script Integration, Review and Approval
? Base lining under Configuration Management

Test Execution and 
Defect Tracking

? Executing Test cases
? Testing Test Scripts
? Capture, review and analyze Test Results
? Raised the defects and tracking for its closure

Test Reports 
and Acceptance

? Test summary reports
? Test Metrics and process Improvements made
? Build release
? Receiving acceptance
Hope this will help for all