Saturday, December 28, 2013

Software Testing: Is it a Bug or not ?

Many a times we see something that we think is unexpected as per our understanding of the product, usually in large projects where you are working only on a specific component however for testing purpose you have to exercise other component workflow, you may land up in a situation of " I see something new .. weird...may be or may not be a bug".

What can we do in such situations

If you think that its not your component and not your responsibility to test , you are losing an opportunity to help, explore, make yourself accountable across teams and importantly  understand the complete flow of your own test product. According to me there are two approaches that will help in this situation.

1) Debug and root cause yourself: Ask yourself few questions like
  • Why do you think its a bug
  • What negative versus positive impact does this behavior makes to the application
  • Can you design a scenario that will break things and obviously make this behavior a bug and get proper attention to be resolved later.
  • Investigate the change history in source code for the component that has the new behavior you observed.
  • Can this behavior be reproduced consistently. If yes note down the steps.
  • Is the behavior same across all the test environments
  • If possible, can you provide the comparison between the old and new behavior.
  • If the behavior tends to be functionality (not a bug) what other changes needs to be made to make sure other do not think of this as a bug.
2) Report and follow-up: Find the owner of the component (Dev/Test/PM) report them the behavior you observed and give all the necessary details they want to see this behavior. Follow-up with them to understand the behavior and investigate with them if this is a bug or not.
In this way you are making sure that you understand system (product) as a whole and not only your component. Also this helps you to have experience of across team collaboration.
If it resulted to be a bug you win the trust of your testing ability from other teams as well. Make sure you learn why this was bug and make sure next time if such same thing occur in regression you report it as bug.
If it resulted as not a bug make sure you understand the answer you get from other team for this behavior. You should note it down as you got to know a new thing in the product workflow and make sure you list all the improvements if any required by the cross team to get done as to make this behavior not look like a bug.

Happy Bug finding Friends

+Vijay Rathod  +Nilesh Zade  +Kushal Punjabi +Ashish Jethani +nitin shelar +amit tripathi +Shatrughan Ambwani  +reegan samy  +Mukesh Chaudhari  +vishal gaikwad  +Sagar Dhadge +Nikhil Deval  +Ravi Varpe  +Pratik Godhani  +Hrishikesh Tiwary  +Rakhee Makhijani +Kavita Chandwani  +Gaurav Jain  +Vikram Keswani  +kedar gorwadkar  +Leena Talreja +Mukesh Deshmukh  +Padmarag Lokhande  +Sharique Quadri  +Raushan Verma +Tanya Sukheja  +Peeyush Mittal 

Thursday, December 26, 2013

Software Testing: Fundamentals


  

What is Software Testing?

Executing a program or application with the intent of finding bugs in it is called software testing. It a process of validating and verifying that a software program or application or product meets the business and technical requirements.



Methods and Types
 
Many a times we get confused as what is Testing Methods and what is Testing Types.
  • Testing Method is a particular form of procedure for accomplishing or approaching testing goals.
  • Testing Type is a category of testing having specific goals or characteristics.



Testing methods

Static Testing :It is a form of software testing where the software is tested without executing the code.
Examples: Code reviews, inspections and Software walkthroughs
 
Dynamic Testing: Testing the software by executing i.e. giving input values and checking if the output is as expected, which can be done manually or with the use of an automated tool.
Examples: Integration tests, System tests and Acceptance tests
 
White Box testing: It is a method of testing software that tests internal structures or workings of an application.
Example: Control flow testing, Data flow testing, Branch testing, Path testing
 
Black Box testing: It is the method of testing software that examines the functionality without knowing the internal structure of the application.
Examples: Equivalence partitioning, Boundary value analysis, Cause effect Graph, Error Guessing


Testing Types

  • Functional testing :  Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
  • Regression testing: The intent of regression testing is to ensure that a change such as enhancements/patches/configuration changes has not introduced new faults.
  • Performance testing: Testing the performance of a software such as response time, resource usage and stability
  • Security testing: Testing the software to verify it protects data and maintains functionality as intended
  • Compatibility testing: It tests whether the application or the software product built is compatible with the hardware, operating system, database or other system software
  • Smoke and sanity testing: Tests made to a systems to determine if it is ready for more robust testing
  • Accessibility testing: Test with reference to users with disabilities that affect how they use the software.
  • Acceptance testing:  Test conducted to determine if the requirements of a software are met as per the specifications provided.


Testing levels

  • Unit testing : Test the individual unit of source code.
  • Integration testing :  individual software modules are combined and tested as a group
  • System testing: Testing the software as whole system (Complete integrated system)
  • Acceptance testing: Tests conducted to determine if the requirements of a software are met
  
Communication:
 As a test member we think from all perspective and design test cases, the tests are executed with the intend to find bugs, if we find a bug (which is a good test) we report it to the developer and Manager. But at the same time we need to be very careful as how we react or report the defects and failures to the developers. We are pleased because we found a good bug but how will the requirement analyst, the designer, developer, project manager and customer react. Hence communication and effective polite communication is very necessary.

With Regards Vishal and friends +Vijay Rathod  +Nilesh Zade +nitin shelar  +Hrishikesh Tiwary  +Sagar Dhadge  +reegan samy  +Ashish Jethani