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