Friday, April 11, 2008

Just to clear few points - Test Methods

1.    What approach should be used for testing?  

There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation.
Common quality attributes include reliability, stability, portability, maintainability and usability.
Regardless of the methods used or level of formality involved the desired result of testing is a level of confidence in the software so that the developers are confident that the software has an acceptable defect rate.
When changes are made to software, a regression test ensures that the changes made in the current software do not affect the functionality of the existing software.
The role of highly skilled professionals in software development has never been more difficult - or more crucial - as organizations try to complete application development faster and more cost-effectively.
Test teams that use manual testing exclusively are struggling to keep up.
Because they cannot test all the code, they risk missing significant defects. At the same time, they cannot stop testing long enough to learn new skills.

2.    What are the Test Derivation Techniques? 
• Equivalence partitioning
• Boundary value analysis
• State transition testing
• Cause-effect graphing
• Syntax testing
• Statement testing
• Branch / decision testing
• Data flow testing
• Branch condition testing
• Branch condition combination testing
• Modified condition decision testing
• Business process
• Requirements coverage
• Use case derivation


3.    How many different Test Types are there? 
• Archive tests
• Clinical safety tests
• Compatibility and conversion tests
• Conformance tests
• Cutover tests
• Flood and volume tests
• Functional tests
• Installation and initialisation tests
• Interoperability tests
• Load and stress tests
• Performance tests
• Portability tests
• End-to-end thread testing
• Recovery and restart
• Documentation tests / manual procedure tests
• Reliability / Robustness tests
• Security tests
• Temporal tests
• Black box / White box tests
• User interface tests / W3C WAI Accessibility testing


4.    Why use Generic Test Objectives? 
• Demonstrate component meets requirements
• Demonstrate component is ready to reuse in larger subsystems
• Demonstrate integrated components are correctly assembled or combined and collaborate
• Demonstrate system meets functional requirements
• Demonstrate system meets non-functional requirements
• Demonstrate system meets industry regulation requirements
• Demonstrate supplier meets contractual obligations
• Validate that system meets business or user requirements
• Demonstrate system, processes, and people meet business requirements


5.    What are Quality Gates?
• The Quality Gate process is a formal way of specifying and recording the transition between stages in the project lifecycle
• Each Quality Gate details the deliverables required and actions to be completed and metrics associated with the Quality Gate
• All testing stages specify formal entry and exit criteria
• The Quality Gate review process verifies the specified acceptance criteria have been achieved


6.    What Acceptance Criteria should be used? 
In the context of the system to be released, good enough is achieved when all of the following apply:
• The release has sufficient benefits
• The release has no critical problems
• The benefits sufficiently outweigh the non-critical problems
• In the present situation, with all things considered, delaying the release to potentially further improve the system, would cause more harm than good


7.    Testing Metrics - Do you have examples? 
• Number of test cases
• Number of tests executed
• Number of tests passed
• Number of tests failed
• Number of re-tests
• Number of Requirements tested
• Number of Defects per lines of software code or per function
• Number of Defects found in computer file types (e.g. jav, aspx, xml, xslt, html, com, doc)


8.    Why use Test Scripts? 
• Test scripts are necessary to execute repeatable tests
• Can be manually executed
• Can be automatically executed
• Can be based on re-usable building blocks
• Are a constructive component in the testing process
• Provide traceability and documentation


9.    What tools are available for Test Support? 
• Test Asset Management Tool
• Functional test tool
• Non Functional test tool
• Monitoring tools (for soak testing and live monitoring)
• Consistent, company-wide, Defect Management Process
• Repeatable Test Execution Processes
• Timely Reporting
• Use Cases Documentation
• Test Harnesses
• Common Nomenclature in use by all
• How-to Guides


10.    How-to Guides - What are they? 

These are some of the possible How-to guides…
• How-to read Use Cases
• How-to scope each test
• How-to determine which test types are necessary
• How-to derive test conditions
• How-to prepare a test planner
• How-to write test cases
• How-to plan for Security testing
• How-to conduct WAI Accessibility testing
• How-to test Service Level Agreements
• How-to assess risks
• How-to raise, track and manage defects
• How-to create and maintain a regression test pack
• How-to setup and manage User Acceptance Testing


11.    What are the 10 best steps for software testing? 
1. Establish the Test Methodology you wish to follow ... E.g. ISEB
2. Establish the Test Principle ... E.g. Fail fast
3. Define the Requirements ... If there are no requirements then there is nothing to test
4. Document the Requirements Traceability matrix ... This should work in both directions
5. Define the specific tests which apply in your situation
6. Document the test plan
7. Document the test cases
8. Define the start of testing
9. Conduct testing
10. Define the point at which testing can stop ... When the benefit of continuing testing is outweighed by the effort of continuing testing

Note: ref: http://www.ruleworks.co.uk

Just to clear few points - Test Management

1.    Why test - what is Testing? 
Testing is a process used to help identify the correctness, completeness and quality of developed computer software.


2.    System Testing myths and legends - What are they? 

Myth1: There is no need to test
Myth2: If testing must be done; two weeks at the end of the project is sufficient for testing
Myth3: Re-testing is not necessary
Myth4: Any fool can test
Myth5: The last thing you want is users involved in test
Myth6: The V-model is too complicated

3.    What are the Concepts for Application Test Management?   

• Testing should be pro-active following the V-model
• Test execution can be a manual process
• Test execution can be an automated process
• It is possible to plan the start date for testing
• It is not possible to accurately plan the end date of testing
• Ending testing is through risk assessment
• A fool with a tool is still a fool
• Testing is not a diagnosis process
• Testing is a triage process
• Testing is expensive
• Not testing, can be more expensive


4.    What Test Principles do you Recommend?
• Test involvement early in the lifecycle
     -  Test Architect Signs off Requirements
     - Test Architect Signs off Use Cases
• Fail Fast
     - Identify failures early via core test scripts
• All Test Phases have equal value
     - Each Test Phase has its own value add
• RACI chart everything
• Testing is a pro-active activity
    - Plan the Test
    - Test the Plan
• Finding defects is good
    - Ignorance of faults in a non-conformant system is no excuse


5.    Test Analysts - What is their Value Add?
• Understand the system under test
• Document Assumptions
• Create and execute repeatable tests
• Value add through negative testing
• Contribute to Impact Analysis when assessing Changes
• Contribute to the risk assessment when considering to end testing


6.    What do Test Analysts Need? 
• Education
• Test Environment
• Test Tools
• Access


7.    Requirements Tractability - What is this about? 

• Tracing requirements to test cases
• Tracing test cases to requirements
• Should be a feature of the Test Asset Management tool
• Automatic on-demand process
• Pie chart reporting


8.    What is involved in the Application Test Lifecycle? 
• Unit testing
• Module testing
• Component testing
• Component integration testing
• Subsystem testing
• System testing
• Functional testing
• Technical integration testing
• System integration testing
• Non-functional testing
• Integration testing
• Regression testing
• Model Office testing
• User Acceptance testing


9.    How to manage Risk Mitigation? 
• Identify risks before the adversity affects the project
• Analyze risk data for interpretation by the project team
• Plan actions for probability, magnitude & consequences
• Track risks and actions, maintaining a risk register
• Control risk action plan, correct plan deviations


10.    What should the Test Team do? 
• Program Management
• Strong Change Management
• Strict Configuration Control
• Pro Active Scope Creep Management
• Inclusion in the decision making process


11.    What are the Test Team Deliverables 
• Test Plans
• Test Script Planner
• Test Scripts
• Test Execution Results
• Defect Reports
• Corrective Action Log
• Weekly reports

Note: The abstracts on this page is taken from different websites

Wednesday, March 26, 2008

Software Testing Life Cycle

The Software testing life cycle contains the following components:

  • Requirements Analysis - Mainly done by Project Manager and System Analyst
  • Use Case Documentation - Again this is done by System Analyst
  • Developing Test Plan - Done by Test Lead
  • Developing Test Case - Test Lead and Test Engineer
  • Test Case Execution - Test Engineer
  • Test Report Generation - Test Engineer
  • Defect Reporting - Test Engineer
  • Defect Retest - Test Engineer

Recommended Resources
Testing Interview Questions - http://www.coolinterview.com/type.asp
Testing Tools Interview Questions - http://www.coolinterview.com/type.asp
What is Software Testing?- http://en.wikipedia.org/wiki/Software_testing
Software QA & Testing Resource Center- http://www.softwareqatest.com/
Testing Faqs- http://www.testingfaqs.org/

A Sample Test Plan

The Test Plan identifies multiple test levels, which are going to be performed for the project. Activities which are going to be performed at each level must be planned in advance and has to be formally documented.

Below I am describing a sample Test plan:

1. Purpose

<The purpose of this document is to describe the various test cases, testing methodologies, environments and the Software/Hardware tools that would be used followed during <unit/integration/system> testing in the ABC project.>
2. Approvals and Authorizations


Designation Name Date
Author


Approved By



3. Distribution

Holder’s Designation Holder’s Name Issue Date
Project Manager

Test Lead


4. Amendment Record

No Date Section(s) Issue No. Description











5. Test Plan
5.1 Objective of Test
<The objective of the integration/system test is to test the interfaces between the modules comprising the ABC product and to meet the performance criteria and benchmarks requirements criteria, if any, which may include volume and stress testing>
5.2 Test Method
<Details of the Test Strategy>

5.3 Entry and Exit Criteria

5.3.1 Entry Criteria
• Unit / Integration / System test plan approved.
• Coding phase / Unit testing / Integration testing complete
5.3.2 Exit Criteria
• Unit / Integration / System testing complete.
• Test records produced.
• Defect reports/Defect Tracking/produced and resolved.
5.4 Test Schedule
<As defined in the Project Management Plan.>
5.5 Defect Reporting and Monitoring Progress
• Defect reports/Defect Tracking will be maintained in line with the Testing Procedure.
• The Test Lead will issue a test report to the team members, Project Lead and Project Manager on a fortnightly basis.
5.6 Build Plan and Build Refresh Criteria
A new build of the software will be made whenever
• A Defect is found which prevents further testing
• All test cases have been executed and some Defects have been corrected
5.7 Resource Requirements
5.7.1 Hardware Requirements

Resource Description Qty






5.7.2 Software Requirements

Software Description Qty






6. Test Architecture
6.1 Test Architecture/Topology

<Draw the various test architecture/topology required for the testing>

I will try to post a new blog on Test Architecture/Topology very soon. Keep updating and keep visiting... :)

7 Test Environment Set up
< Describe the Testing Environment >

8. Test Cases
<Test cases definition for this testing is documented in the separate Test Case Form.>

For more details on Test Case, please visit the Test Case Form blog :) .

Software Testing in SDLC

The orthodox software process model typically suggest Software testing after development of code. This process is advocated by several process models like:

  • Waterfall Model - Linear model
  • Prototype Model - Though we have scope to test at early phase.

Several studies has shows that this linear approach amplifies the defects several times.

Accommodating software testing early in the Software Development Life Cycle (SDLC) will reduce errors and in turn save cost and effort. Here I am trying to illustrate a process model which has been derived from popular waterfall model:

image

If you carefully analyses the above shown process model, you will come to the conclusion that, this is not different from any linear model. The only change is the placement of the testing phase; which has been at the beginning, just after High level design phase. The diagram is quite self defining, so I am not putting any more detail about this.

Note: Ref - CMM in Practice: Processes for Executing Software Projects at Infosys (The SEI Series in Software Engineering) by Pankaj Jalote

Tuesday, March 25, 2008

Welcome

Welcome Everybody,
You are most likely to fit into one of the following categories:
-- A student with no or little experience in Software Testing or Quality Assurance,
-- A seasoned practitioner of Software Testing or Quality Assurance.
-- You may have written books or papers.
-- You may be young.
-- You may be ripened.
-- You may have been or are a developer.
-- You may have been a support desk person.

Regardless, you are most welcome in the blog. When and if you ever leave this blog, you will have conversed with the best and the brightest in Software Testing or Quality Assurance, and – should you stay and study long enough, you will have been educated by the best and the brightest in this industry.

How much do you need to pay for this volunteer-based service and higher education? The cost of this education is as follows:


Your Payment Plan consists of Respect, Resourcefulness, and Self-sufficiency:
=*= Respect: You demonstrate extreme respect for the volunteer educators here, by taking into account all that is in this entire post. And when you have some useful feedback or guidance, do take time to follow-up with gratitude or other words pertinent to closing the loop on your post.

=*= Resourcefulness: Demonstrate that you have command of your question/topic when you post as follows.

=*= Self-sufficiency: You will also find a broad range of topics covering IT and the tools necessary to facilitate certain aspects of IT as related to software testing, et al.

Give respect and gain respect! Consider this place your most prized possession and it will reward you with all that you ever need for your professional advancement and professional well-being!

Thank you!