• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Testing concepts ppt
 

Testing concepts ppt

on

  • 1,339 views

 

Statistics

Views

Total Views
1,339
Views on SlideShare
1,339
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Testing concepts ppt Testing concepts ppt Presentation Transcript

    • Testing
      • At 1 st Stage --- Testing is the process of executing a program with the intent of finding errors
      • At last Stage ---Testing is the process of demonstrating that errors are not present (after the completion of all bugs)
      • When you test a program, you want to add some value to it. Adding value through testing means raising the quality or reliability of the program. Raising the reliability of the program means finding and removing errors.
      • Therefore, don’t test a program to show that it works; rather, you should start with the assumption that the program contains errors (a valid assumption for almost any program) and then test the program to find as many of the errors as possible
      Introduction
    • Why Testing?
      • To find and correct defects.
      • To check whether the Client/User needs are satisfied
      • To avoid user detecting problems
      • Also to provide Quality Product
    • Why does S/W have bugs?
      • Miscommunication or No Communication (That we are not clear about what an application should do or shouldn’t do)
      • Time Pressure (Time scheduling)
      • Changing Requirements
      • Software Complexity (Without experience its bit tough to do the tough application)
      • Programming Mistakes
    • Testing Technique
      • White Box Testing (Which was done by Developers)
      • Black Box Testing (Which was done by Testers)
    • Levels of Testing:
      • Unit Testing(Done by Developers)
      • Integration Testing(Combining two or more modules )
      • System Testing (Testing full application based on the requirements)
      • User Acceptance Testing (Based on the user needs and testing will be done in client place)
    • Points for Unit Testing:
      • Functional
      • Does the piece of code functionally perform the task it is designed to do?
      • Boundaries
      • What are the minimum, maximum values for the function, will the function accept strange characters? What happens if they are not within these boundaries?
      • Termination
      • What happens in the normal termination of the function? What about an abnormal termination of the function? Will the application continue or will an error occur. Is the error trapped?
    • Points for Unit Testing:
      • Outputs
      • What are the expected outputs of the function? Where do they go, what happens if the output is nothing? What happens if the output cannot be passed to the next function? i.e. The database was unavailable when attempting to write to it.
      • Inputs
      • What are the expected inputs to the function? What happens if they do not get passed in? What happens if they are the wrong type? i.e. an alpha instead of a numeric
      • Interaction
      • What other modules/functions does this interact with? Will those be effected by the change?
    • Tester vs Developers
      • Developer always wants to see his code working properly. So he will test it to check if it’s working correctly. But you know how tester will test the application? To make it fail in any way, and tester surely will test how application is not working correctly. This is the main difference in developer testing and tester testing.
      • For success of any project there should be independent testing team validating your applications. After all it’s our (testers) responsibility to make the ’application’ smarter!!
    • Ways To Be Good Developer From Tester Point of View
      • Do Your own acceptance tests In unit testing, developer have to do their own acceptance testing for all the part
      • Do not repeat bugs One bad thing that you may experience being a tester, is developer which  repeats the same errors. Comes up to the fact that the tester is able to predict how the error occurs in a functional change. This illustrates the carelessness of the programmer and a his lack of progress in learning this difficult skill.
    • Ways To Be Good Developer From Tester Point of View
      • They do not want to hurt you Developers usually think that the main tester task is to demonstrate that the code writer is feeble by detecting as many bugs as it is possible. Developers often are afraid to give the code for testing but should rather seek the assistance in order to ensure doing good job. If the tester comes and says “You are poor because I detected 29 errors in Your code” – ask “And how many left?” :) Someone said, “The more errors we find the more is still there” – do not forget about it.
      •   Write comments and human readable code In times of auto comments available in Visual Studio but also in other development tools, developers forget to include something from inside. Something which usually proves to be very helpful in a crisis, and necessary for code review. In parallel, write code that explains a lot without reading the comments, function and variable names are no longer restrictions on the number of characters !
    • Ways To Be Good Developer From Tester Point of View
      • Provide descriptive error alerts. I think that one of the most arduous and time-consuming activities performed by the tester is looking for a path access to the bug. Submit error to bug tracker and get the response “Can not reproduce”, it usually ends with a call to developer for demo or send him screen cast. Through the provision of good error messages tester can provides ready information with a bug.
      •   Do not Test the Tester ! Even if you have very bad relations with the tester or the entire quality department, never code artificial bugs to demonstrate the poor quality of the tester! Fraud sooner or later comes to light. Testers also have a great ways to show your low skills, a fight between the persons/departments always ends with the customer’s critical exceptions.
      • Relation Ship Between PM/D/T
      • .
      • Project Manager (PM)
          • Helps you understand the target of the project
          • Give you schedules
          • Needs you to update him/her on the quality status of the project
      • Developers
      • Help you understand how the components work on the inside
      • Help you know about “joint” points of the product
      • Help you know about changes in the code
      • Let you know the schedule of coding
      • Let you know the status of bugs
      • Need from you information about problems
      • Need you to inform them on what will be tested and when
      • Testers
      • Help you understand product functionality
      • Tell you about known bugs
      • Tell you about tools that can help you
    • FINALLY
          • Have a good interaction,
          • understand the tasks,
          • close the bugs,
          • and at last give the quality product,
          • it makes us to reach what we have aimed and also it will reach our company to the top level
    •