Manual Testing Tips II

Why  to  test? 

testing becomes absolutely essential to make sure the software works properly  and  does  the  work  that  it  is  meant  to  perform.

What  to  test?
Any  working  product  which  forms  part  of  the  software  application  has to be tested. Both data and programs must be tested.

How  often  to  test?
When  a  program  (source  code)  is  modified  or newly developed,  it  has  to  be  tested.

Who  tests?
Programmer, Tester and Customer

Requirements

User  Requirements  Specification  (URS)
This document will  describe  in  detail  about  what  is  expected  out  of  the  software  product from  the  user's  perspective. The wordings of this document will be in the same tone that of a user

Software  Requirements  Specification (SRS)
A team of  business  analysts,  who  are  having  a  very  good  domain  or  functional expertise,  will  go  to  the  clients  place  and  get  to  know  the  activities  that  are to  be  automated and prepare a document based on URS and it is called as SRS

Design

High  Level  Design  (HLD)
List  of  modules  and  a  brief  description  of  each  module.
Brief  functionality  of  each  module.
Interface  relationship  among  modules
Dependencies  between  modules  (if  exists,  B  exists  etc.)
Database  tables  identified  along  with  key  element.
Overall  architecture  diagrams  along  with  technology  details.

Low  Level  Design  (LLD)
Details  functional  logic  of  the  module,  in  pseudo  code.
Database  tables,  with  all  elements,  including  their  type  and  size
All  interface  details  with  complete  API  references  (both  requests and  responses)
All  dependency  issues Error  message  Listings
Complete  input  and  outputs  for  a  module.

Testing Levels

Unit Testing
Programs will be tested at unit level
The same developer will do the test

Integration  Testing
When all the individual program units are tested in the  unit testing phase and all units are clear of any known bugs, the interfaces between those modules will  be  tested
Ensure that data flows from one piece to another piece

System  Testing
After  all  the  interfaces  are  tested  between  multiple  modules,  the  whole set of software is tested to establish that all modules work together correctly as an application.
Put all pieces together and test

Acceptance  Testing
The client will test it, in their place, in a near-real-time or simulated environment.

Manual Testing Tips

Testing  Vs  Debugging 

• Testing  is  focused  on  identifying  the  problems  in  the  product 
• Done by Tester
• Need not know the source code

• Debugging is to make sure that the bugs are removed or fixed 
• Done by Developer
• Need to know the source Code

Detailed Test Plan

• What  is  to  be  tested  ? 
• Configuration – check all parts for existence
• Security – how the safety measures work
• Functionality – the requirements 
• Performance – with more users and more data
• Environment – keep product same but other settings different

Detailed  Test  Cases 

The  test  cases  will  have  a  generic  format  as below.

• Test  Case  Id
• Test  Case  Description 
• Test  Prerequisite
• Test  Inputs 
• Test  Steps
• Expected  Results 

Detailed  Test  Case  (DTC) 

• Simple  Functionality – field level
• Communicative  Functionality – data on one screen goes to another
• End-to-End  Test  Cases – full sequence as though the end users carry out

Test  Execution  and  Fault  Reports 

• Test  Case  Assignment – done by test lead 
• Test  Environment  Set-up – install OS, database, applications
• Test  Data  Preparation – what kind of data to be used

Regression Testing

When some errors occur in a program then these are rectified.  For rectification of these errors, changes are made to the program.  Due to these changes some other errors may be incorporated in the program.  Therefore, all the previous test cases are tested again.  This type of testing is called regression testing.
In a broader context, successful tests (of any kind) result in the discovery of errors, and errors must be corrected. Whenever software is corrected, some aspect of the software configuration (the program, its documentation, or the data that supports it) is changed. Regression testing is the activity that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors.
Regression testing may be conducted manually, by re-executing a subset of all test cases or using automated capture/playback tools. Capture/playback tools enable the software engineer to capture test cases and results for subsequent playback and comparison.

• The regression test suite (the subset of tests to be executed) contains three different classes of test cases:
•  A representative sample of tests that will exercise all software functions.
•  Additional tests that focus on software functions that are likely to be affected by the change.
• Tests that focus on the software components that have been changed.
•  As integration testing proceeds, the number of regression tests can grow quite large.

Therefore, the regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program functions. It is impractical and inefficient to re-execute every test for every program function once a change has occurred.

For regression testing, some test cases that have been executed on the old system are maintained, along with the output produced by the old system. These test cases are executed again on the modified system and its output compared with the earlier output to make sure that the system is working as before on these test cases.  This, frequently, is a major task when modifications are to be made to existing systems.

A consequence of this is that the test cases for systems should be properly documented for future use.  Often, when we test our programs, the test cases are treated as “throw way” cases; after testing is complete, test cases and their outcomes are thrown away. With this practice, every time regression testing has to be done, the set of test cases will have to be re-created, resulting in increased cost. In fact, for many systems that are frequently changed, regression testing “scripts” are used to automatically perform the regression testing after some changes.  A regression testing script contains all the inputs given by the test cases and the output produced by the system for these test cases.  These scripts are typically produced during the system testing, as regression testing is generally done only for complete systems or subsystem. When the system is modified, the scripts and comparing the outputs with the outputs given in the scripts.  Given the scripts, though the use of tools, regression testing can be largely automated.

Strategic Issues in Testing

Testing is a very important phase in software development life cycle. But the testing may not be very effective if proper strategy is not used.  For the implementation of successful software testing strategy, the following issues must be taken care of: -

• Before the start of the testing process, all the requirements must be specified in a quantifiable manner.
• Testing objectives must be clarified and stated explicitly.
• A proper testing plan must be developed.
• Build "robust" software that is designed to test itself.
• Use effective formal technical reviews as a filter prior to testing. Formal technical reviews can be as effective as testing in uncovering errors. For this reason, reviews can reduce the amount of testing effort that is required to produce high-quality software.
• Conduct formal technical reviews to assess the test strategy and the cases themselves. Formal technical reviews can uncover inconsistencies, omissions, and outright errors in the testing approach. This saves time and also improves product quality.
•  Develop a continuous improvement approach for the testing process. The test strategy should be measured. The metrics collected during testing should be used as part of a statistical process control approach for software testing.