• Testing concepts
  • Sunday 15 December 2013

    Test Harness

    What is Test Harness?

    Anybody have come across Test Harness. Well It is kind of code written in the form of WhiteBox Testing. In SDLC Model i.e V Model there is one Level for Testing called as Integration Testing where each modules are been broken into sub modules for testing and integrating components.
    One Level in Integration Testing is System Integration Testing. Further in it there are different Strategies in it i.e Top Down approach and Bottom Up analysis.
    Here in Top Down approach, Stubs are used and in Bottom Up analysis Drivers are used.
    Stubs and Drivers are nothing but set of codes written unless the entire Code is not yet developed.
    So if Developer has not yet completed his part of work these Stubs and Drivers are written in functions and procedures.
    Hence this set of codes are called as Test Harness.

    Sunday 1 December 2013

    Tracebility Matrix in Software Testing

    What exactly is Traceability Matrix?

    First of all by name itself Trace gives the meaning that something has to be traced. Similarly for Software Testing everything has to be traced. In large projects each and every data has to be maintained for future reference. So there is a concept called Traceability Matrix.

    So while preparing Traceability Matrix it can be done using Excel sheet or any other Test Management Tool  like Quality Center also. While preparing  Traceability Matrix in Excel these are the main things which need to be concentrated i.e,
    Sample Template
    Requirements ID  Req ID1.1  Req ID1.2  Req ID1.3  Req ID1.4  Req ID1.5 

    Test Cases id
    TC1.1
    TC1.2
    TC1.3
    TC1.4
    TC1.5

    If a Tester leaves the organization and if he doesnot fill the report of   Traceability Matrix, how will the New Tester come to know what and all Test Cases have been written to which Requirement IDs.

    So  Traceability Matrix  gives the entire coverage of How many Test Cases have been written, how many Test Cases executed, which defect has been raised on which Test Cases etc.

    In Quality Center Test Coverage analysis prepares automatically all the reports and generates it after linkage is done by Testers of Test Cases to Requirements.   

    Monday 18 November 2013

    Test Management Tool Quality Center

    Quality Center is basically Test Management tool where you can manage your entire Test Data, Test Requirements, Test Cases in short all known as Test Deliverables.

    Quality Center contains basically 4 Important Modules in it.

    1. Requirements: Here all the Parent and Child requirements are written in Sequential order where every Parent and Child will be having their Unique Id no, which easily in future can be recognized if any changes of requirements will be done.

    2. Test Plan: Here is the Module where entire Test Cases are managed in this Module along with Test Data also, apart from this these Test Cases are written in standard Template form. And entire Test Set are managed in this Module where even Export and Import of Excel or other files can be done in this Module. The Test Cases are linked to the Requirements module with their respective Ids.
    The Template is i.e
    Sl.No  Description   Expected Result  Actual Result  Status

    3. Test Lab: Here is the Module where entire Test cases are executed after writing Test Cases it has to be executed so in this module we execute along with Test Data given in excel form. And further for executing the Test Cases it has to be linked to the Test Plan Module with their respective Ids.
    Test suite is nothing but collection of Test Cases which can be executed.

    4. Defects: Here is the module where entire Defects/Bugs are raised where each and every Bugs has Unique Id assigned to it. Defects can also be raised from test Lab if any execution fails at that time. 

    Sunday 10 November 2013

    Difference between Smoke Testing, Sanity Testing, Monkey Testing, Ad Hoc Testing

    Few Difference between Smoke Testing, Sanity Testing, Monkey Testing, Ad Hoc Testing Concepts

    Smoke Testing: This type of Testing is mainly done as the Checking of Basic Functionality when a Build is released and tried to test if Bugs are found in this test immediately Testing is stopped and does not go further for any different types of Testing. Mainly Positive Scenarios are tested

    Sanity Testing: This type of Testing is also similar to Smoke Testing But here its type of Width wise Testing and for Checking of Basic Functionality when a Build is released and tried to test with Both Positive and Negative Scenarios if Bugs are found in this test immediately Testing is stopped and does not go further for any different types of Testing.   

    Ad Hoc Testing: This type of Testing is done with No proper documentation or writing any Test Cases , here its just testing the application with no standard format.

    Monkey Testing:  This type of Testing is done like for example if a Monkey uses some product or application how will he use it, similarly entering some Junk or Random Data in the fields and trying to test it.

    Monday 4 November 2013

    Test Cases for Lift

    Few Test Cases for Electronic Lift operation:

    1. Test from Outside after pressing the button whether Lift Opens if it is in same floor.

    2. Test from Outside whether Light is glowing or not, to know Lift is going up or down.

    3. Test from Inside by pressing buttons at each floor.

    4. Test all the buttons whether it is going to proper floor or not.

    5. Test with Maximum Number of people inside the Lift i.e overloading of Lift.

    6. Test the Lift when the Power suddenly goes Off and people are inside the Lift, an emergency button should be there for alarm.

    7. Test for any wobbling inside the Lift.

    8. Test for Lift within time limit it goes to each floor and does not cause delay.

    9. Test for speed of Lift from Top floor to Bottom floor.

    10. Test for Lift if suddenly in the Top something falls drastically and alarm should be ringed immediately.

    11. Test for Lift properly whether it closes the door properly when button is pressed.

    12. Test for Lift if number of people exceeds with Maximum weight in lift, Message or alarm should ring that Lift is overloaded.

    13. Test for Lift from each floor the Lift opens at that floor and does not go to some other floor.

    14. Test for Lift all the electronic buttons are working or not.

    15. Test for Lift if suddenly some wire gets cut from Top some safety measures has to be initiated immediately.

    Sunday 27 October 2013

    Test Cases for Login scenarios

    Few Test Cases for Login scenarios

    1. Test for Valid Username and Password and click on Login, should successfully Login.

    2. Test for entering Username and without Password and click on Login, should pop up message and ask for Password.

    3.   Test for  entering Password and without Username and click on Login,  should pop up message and ask for Username.

    4.   Test for InValid Username and InValid Password and click on Login,  should pop up message and ask for Valid Username first and then ask for Valid Password.  

    5.   Test for Limited characters for  Username and Password and use Equivalence partitioning and boundary value analysis for both and click on Login

    6.   Test for strong, weak password  with all wild characters in it and then click on Login.

    7.   Test for password should be in encryption and should not be visible and click on Login

    8.   Test for more security tags with html tags or sql injection in username and password so that no one hack the account.

    9.   Test for forgot password if user is already registered and click on Login and email should be sent to User.

    10.   Test for Change Password with Old Password should be different with New Password, should be able to change password successfully.

    Sunday 20 October 2013

    Test Cases for ATM Debit Card

    Here are few scenarios for ATM Debit Card

    1. Test the card with Valid ATM Card

    2. Test the card with Invalid ATM Card

    3. Test the card with proper Insertion of Card

    4. Test the card with Direction facing the ATM Machine

    5. Test the card  with insert and remove for certain Debit Card

    6. Test the card which reads the Card from ATM Machine

    7. Test the card when suddenly power is Off no information should be displayed and Card should be removed.

    8. Test the card With No scratches on the Card.

    9.  Test the card with proper valid PIN 

    10. Test the card with Invalid PIN and deny operation if continuously Invalid PIN entered 

    11. Test the card when entered  continuously Invalid PIN entered immediately message should be sent to Mobile. 

    12. Test the Card with sensitivity of PIN entered in machine.

    13. Test the Card with different Transactions displayed in Machine.

    14. Test the Card with few transactions like Fast Cash, withdrawal, Current, Savings, Balance Inquiry etc.

    15. Test the Card for entering Money with limited numbers not exceeding the limit.

    16. Test the Card for entering Invalid numbers.

    17. Test the Card when entered Valid PIN different transactions displayed.

    18. Test the Card again if the middle of the transaction Card is inserted which it should stop transaction.

    19. Test the Card with Valid account and Valid transaction of money and request for receipt.

    20. Test the Card with in middle of transaction Power goes off and transaction should not deduct in account as money not yet received.

    21. Test the Card with Mobile information with debit of money in the account.

    22. Test the Card with Valid Savings or Current account type and request for receipt.

    23. Test the Card with Invalid account type selected and deny the request for debit of money.

    24. Test the Card with some untoward type of hacking/manipulation goes on from Account and immediately message should be sent to Owner and also for that particular machine owner.

    25. Test for other types of devices used in ATM Machine.

    26. Test the Card with No Money in the Account and request for receipt.

    27. Test the Card when one transaction is over immediately it should be logged out of account.

    28. Test the Card with minimum balance in account and entering More the balance so report an error.

    29. Test the Card with an error should be displayed in Machine if No balance in Machine.

    30. Test the Card with one transaction at a time.

    31. Test the Card in Machine with Maximum withdrawal at a limit.

    32. Test the Card with an Expiry Card

    33. Test the Card with an machine where it swallows the Card.

    34. Test the Card after Valid transaction Card should be reverted back to the owner if it is swollen machine.

    35.Test the Card with Invalid transaction card with minimum number of times should be not reverted back and message sent to mobile.

    Thursday 10 October 2013

    Test Cases for Swiping Card for Door normally Interview question

    Here are few Test Cases for swiping card for Door entry of building 

    1. Test the swiping with Valid Card.

    2. Test the swiping with Invalid card.

    3. Test the swiping of Valid card and get entry.

    4. Test the swiping of Card with both entry and exit with Valid Card.

    5. Test the swiping of Card with Invalid Card continuously swiping and after limited attempts try to pop up message that Card is blocked  .

    6. Test for Swiping of Card with proper position in front of machine.

    7. Test for swiping of Card with proper ID and displaying Valid ID for reports extracted.

    8. Test for swiping of Card with proper Time and Date and proper Id display for the reports extracted.  

    9. Test for swiping of Card with One or more Card swiping at same time and should not allow multiple entries of overlapping of reports.

    10.Test without using Card and manually entering manipulating the machine.

    11.Test for swiping of Card and automatically close the door within time.

    12. Test for swiping of Valid Card and message displayed as Access allowed or Thank You.

    13. Test for swiping of Invalid Card and message displayed as Access denied. 

    14. Test for swiping of Invalid Card and  again manually entering manipulating the machine.

    15. Test for swiping of In-Valid Card and have some advanced features if someone tries to enter and pop up message immediately to the concerned department.

    Sunday 6 October 2013

    Test Cases for Calculator

    Few Test Cases for Simple Calculator

    1. Check for Calculator Whether it is Off/ON

    2.  Check for Calculator Whether it has Light for Off/ON


    3. Check for Calculator Whether it has all the set the operations for calculating.

    4.  Check for Calculator Whether it has +, -, * , /, % etc

    5.  Check for Calculator for few scenarios for addition like 2 + 4= 6

    6.  Check for Calculator for few scenarios for subtraction like 2 - 4 = -2

    7.  Check for Calculator for few scenarios for multiplication  like 2 * 4 = 8

    8.  Check for Calculator for few scenarios for Division  like 2 / 4 = .5

    9. Check for Calculator for few scenarios for backspace/delete numbers

    10. Check for Calculator for few scenarios for reminder operations like M+, M-

    11.  Check for Calculator for few scenarios also for sqrt, % like sqrt(2) . 

    12. Check for Calculator for few scenarios for proper display of numbers in Bold format

    13. Check for Calculator for few scenarios for compatibility of pressing buttons on each number

    14. Check for Calculator for few scenarios for entering Max number of digits and its result

    15.  Check for Calculator for few scenarios while entering Invalid numbers.

    Sunday 29 September 2013

    Test Cases for PEN

    Few Test Cases for PEN.

    1. Test what is the colour of PEN.

    2. Test the Black/Blue colour of PEN.

    3. Test whether smooth writing of both the colours of  PEN.

    4. Test whether it is DOT/GEL/INK etc of PEN.

    5. Test in different positions of way of writing like tilted, bent etc. 

    6. Test in both left/right hand holding of PEN.

    7. Test in the wall whether it is writing or not.

    8. Test in different speed of way of writing like fast, medium, slow.

    9. Test the total amount of  pages/length written upto what extent it can be written.

    10. Test in place where water/liquid is put in paper and its efficiency of PEN.

    11. Test its quality of writing to its cost matching or not.

    12.  Test it in hard cardboards whether it is writing properly or not.

    13. Test in the hand whether it is writing or not.

    14. Test in benches whether it is writing or not.

    15. Test in different directions and its weight is not so heavy while writing or not.

    Sunday 22 September 2013

    Test Plan

    Features of Test Plan

    1. Project Overview: 
        The Requirements are gathered and prepared a overview of Test Plan
    2. Scope:
       a. InScope:
          What is inside the Testing what can be tested
       b. Out of Scope:
           What is not inside the Testing and what is unused for Testing
    3. Assumptions and Dependencies:
        Any Tool or requirement depending on one another module for Testing
    4. Risks and Mitigations:
        Any risks involved while Testing like urgent requirement of tasks etc
    5. Entry and Exit Criteria
        What is to be Tested
         What is already Tested
    6.  Hardware and Software Requirements  
         O.S. or hardware requirements
    7. QA Deliverables
        a. Preparation of Test Plan      
        b. Test Cases and execution
        c. Reporting Bugs
    8. Communication Plan 
         Interaction with Development and other team members.
    9. Automation Plan.
         Interaction with Automation team and prepare test scripts.
    10. Schedule
          Time and Date for Testing.
    11. Roles and Responsibilities 
          Team involving in Manual and Automation Testing.
    12. Performance Testing
          Check the performance of the application through different tools Loadrunner, Jmeter etc.
    13. End of Test Plan 
    14. Referrals  

    Sunday 15 September 2013

    Facts of Test Cases

    Test specifications:

    Test Plan: A brief specification on the entire process of Testing is Test Plan. For every Testing Level there is Test Plan prepared. Test Plan contains detail explanation of each step by step process of what Tester and Developer has to do and their work criteria.

    Test Cases: A step by step procedure for checking the functionality is known as Test Cases. For every step functionality has to be checked with both Positive and Negative scenarios. The Defects are found from the Test cases and reported in Bug Tracking tool. For every Description of Test Cases there is actual and Expected result produced with Status of Pass/Fail for Test Cases.

    Test Cases & Test scenarios:
    Test Cases:   A step by step procedure for checking the functionality.
    Test Scenarios: An overview for checking basic  functionality and reporting bugs. Its not in detail process but just to check no further bugs are found in basic functionality itself.

    Test Data: For every Test Cases, Test Data or Input is provided into multiple data and executed with the given Input conditions with both positive and negative data and with no data also.

    Test Suite: A Collection/Group  of Test Cases is known as Test Suite .

    Traceability Matrix: This is mainly done to get to know how many number of Test cases are written, number of Bugs found in an application, execution of Test cases etc. In general the Reports are generated from the Traceability Matrix.

    Test Script: This is used mainly for writing code/script or also known as White Box Testing concept. Mainly used for generating Automation Test Scripts/Automation Testing.

    Monday 9 September 2013

    White Paper on Databse Testing


                                                         DATABASE TESTING:

    DB Testing: 

    Database testing (Backend Testing) involves the testing where we try to check the values which are present in the front end application and compare to the back end database which are present in the web based or desktop application. All values should match for proper storage and as per the records of database.  

    How Database testing is carried out:  

    Here we have to check each and every functionality in the given application and action performed in the application. This is done through insertion, deletion, update etc . By adding the records in front end has to be displayed in Database similarly if we delete any values from front end it has to be deleted in database.
    Tester has to have good amount of knowledge on Database queries like sql etc...
    Database testing is risky sometimes if Tester doesn't have knowledge on any of the queries 



    How Database testing is to be done:

    Database testing is one of the major part of testing where Tester has to good experience on executing the queries inserting the tables, deleting the tables, updating the tables and procedures also if required. There are many databases used like Oracle and MSSQL Server etc. Many projects like BFSI are mostly used and taken care of Database testing.    

    While starting Database testing Tester has to analyse the application and good view on the requirements of it. Check all the tables which is present in the application and try to write all the database queries for the tables to execute since there are many things which are really complex, so you can take the assistance of development team and get an idea of the queries. Test each and every table carefully for the data added. This is the best process for the testers to perform the DB testing, it can be done for any application and it does not matter application is small or big. 
    Database is the Backbone and vital for the application and tester should make sure to test very carefully. It requires skill, proficiency and sound knowledge.


    What we exactly do in Database Testing:


    Database testing involves good  knowledge on the given application and its requirements and requires a proper plan to execute it
    Key issues include :
    1) data Integrity
    2) data validity
    3) data manipulation and updates.

    Data Integrity: the completeness or wholeness or inserting of the data. eg: When you enter a record in your application, you check that the data is entered correctly in the database i.e Insert query

    Data validity: rules like check the constraints (null value, primary key, referential key, unique key etc)

    Data manipulations: update the data, delete the data etc.


    Front End Testing and Back End Testing:

    Mainly in Front End we check each and every functionality and test depending the requirements. Testing Like System Testing, Integration Testing, Acceptance Testing is done.

    Back End Testing includes Inserting, Updating, Deletion of the database and modifying the values and check whether the values added are properly added in Database. Like. MSSQL Server, Oracle 10g etc

    Few useful commands for queries here.      

    Select query:  select * from table name where condition

    Insert query: Insert into table values (coloumn1, coloumn2,...)

    Update query: Update table set coloumn1=value where coloumn2=value; 

    Wednesday 4 September 2013

    Different Types of Testing

    Different Types of Testing done: 
     1. Functional testing: 
        This type of Testing is main core of Testing where each and every functionalities are been Tested. For   every code or activity done on the module contains functionality where it has to produce positive result. So for stable application without Bugs Functional Testing is most important part of Testing.
     
    2. Smoke or Sanity Testing:
      The names are different but the actual concept is almost same, the testing of basic functionalities and checking for Bugs initially helps lot for stable application. In case of bugs found at the initial stage it would Save lot of Time and Money so that the application cannot be forwarded at the future level for coding.
    Some companies say Smoke is depth wise testing and Sanity is Breath wise Testing but the main core is to Test for Basic functionalities. 

    3Regression Testing and Retesting : 
    Regression Testing: This is type of testing where If any modification has been done in the application
    which has already been developed before has instantaneously effected the current application is known as Regression effect.
    Like an simple example:
    If A and B has been developed as two different modules but in later part some other developer comes and
    modifies that requirement which was been already developed so it might direct cause an effect to A module. This is known as Regression effect. So testing has to be done as Regression Testing where to detect bugs where the exact modification has been done and try to fix the issue

    Retesting: This type of testing is different from Regression testing wherein this type of testing is just
    and Retesting of same test case which was prepared by Tester before and after the issue as fixed by the developer the bug or test case has to be tested once again. So this is known as Retesting

    Like an simple example:
    If A test case is been prepared and an issue or bug is posted by Tester, it goes to developer where he has to fix it immediately as per priority and then further after fixing the issue.
    Tester tests or Retests it again known an Retesting

    4. Acceptance Testing:
    Final level of testing is done where all the levels are done and gone for client for approval. In this type of testing there are Alpha and Beta form of Testing done. At one end the application is given to client for checking the application and other for End User for any issues.

    5. Installation Testing:
    This is just the Testing where in the form of End User it has to be tested and checked for whether the application is good enough for Installing in different types of browsers and its security are not compromised.

    6. Browser Compability Testing:
    This is the Testing where we test for different browsers and check their compatibility and Design issues in Each of the browser like, Mozilla, chrome, IE, Safari etc.

    7. Non Functional Testing:
    After entire Functional Testing then atlast the main focus shifts to Non Functional Testing . Here there are few testing like Performance Testing, Load Testing, Stress Testing, Volume Testing, Scalability Testing, Security Testing. Like for example in Performance Testing we get to know the how the application is responding if their are many Users using simultaneously at one Time. Similarly for other testing also used for checking throughput, response time etc.
    Another for of Testing is Security Testing which is very important where the Cookies, Cache issues are found out and maximum efforts are been taken to avoid any hacking of data from other users.   

    Monday 2 September 2013

    Levels of Testing

    Brief Levels of Testing: 

    At each level there are different possible number of Levels done for Testing . Under each number of 
    levels there are individual tests performed and depending the type of SDLC process followed the tests are carries on. Normally there are 4 types of levels i.e 
    1. Unit Testing 
    2. System Testing
    3.  Integration Testing
    4. Acceptance Testing

    1. Overview of Unit Testing: 
    This type of Testing is carried out at the first level or also known as Component Testing or also known as White Box Testing. It mainly refers to verify and test the code functionality at the class level and test the functions part using Constructors and Destructor's.
    This type of testing needs the good amount of knowledge to get the flow of the application and is mainly done by developers where they can test the functionality using Code Coverage analysis etc. Unit Testing does not cover entire testing but to test the basic flow of the application and to know the Code coverage.
    This is also known as White Box Testing technique where if the Tester has the good amount of knowledge of Coding even the QA does the testing but normally it is assigned to Developer as he will be having entire knowledge of the application and basic flow of functions.
    Before Testing starts Developer tries to remove all the errors from the application to get a good stable application.
    In Unit Testing the developer tries to test the Code Coverage, Data flow analysis, Peer Code reviews, Static code analysis etc.  

    2. Integration Testing:
    The next phase of Testing is Integration Testing where the QA starts his testing and verifies the interface between 2 components i.e Component  Integration Testing and System  Integration Testing.
    The testing allows you to test between 2 modules in a particular component or 2 systems sharing integrating between each other. As this is important for of level where the integration is important and dependable on one another module. So Both modules has to be integrated and tested successfully. As large number of Bugs raise in this level  of Testing.

    3. System Testing: 
    This type of Testing is mainly done for checking the Bugs in a particular System. This is also main form of  Testing where all the functionalities are tested and for every Level there are Testing Plan prepared as documentation for each level. Mainly in this type of testing there are few techniques are Boundary Value analysis, Equivalence partitioning, State Transition testing, Use case testing etc.

    4. Acceptance Testing:
    Final level of testing is done where all the levels are done and gone for client for approval. In this type of testing there are Alpha and Beta form of Testing done. At one end the application is given to client for checking the application and other for End User for any issues.

    Sunday 1 September 2013

    Why do Defects Occur in an application

    Defects or Bugs

    Almost all the applications will be having defects and it depends on the Code quality on how much the Defects are rectified. Mainly there are different scenarios on how the Defects occur like for eg. the requirements given which might not be appropriate to the Developer to write the code and makes some mistakes this might cause defects to produce. Any Unknown requirements which is difficult to understand might produce defects.

     A programmer might make a mistake in his code which produce errors in the application where the defects occur forthwith or also called a Bug in Testing Terms. So if this defect is executed there might be huge effect on the application. Hence  causing a system failure or application also to crash. Not all defects will be so critical unless the what type of Bug it is.

    Also there might be scenario of where the application has to be used and in what environment it has to loaded and executed. Even a small failure might cause a huge loss to the application and client.

    Sunday 25 August 2013

    Regression Testing and Retesting

    Regression Testing and Retesting:

    Regression Testing: This is type of testing where If any modification has been done in the application
    which has already been developed before has instantaneously effected the current application is known as Regression effect.
    Like an simple example:
    If A and B has been developed as two different modules but in later part some other developer comes and
    modifies that requirement which was been already developed so it might direct cause an effect to A module. This is known as Regression effect. So testing has to be done as Regression Testing where to detect bugs where the exact modification has been done and try to fix the issue

    Retesting: This type of testing is different from Regression testing wherein this type of testing is just
    and Retesting of same test case which was prepared by Tester before and after the issue as fixed by the developer the bug or test case has to be tested once again. So this is known as Retesting

    Like an simple example:
    If A test case is been prepared and an issue or bug is posted by Tester, it goes to developer where he has to fix it immediately as per priority and then further after fixing the issue.
    Tester tests or Retests it again known an Retesting


    Friday 16 August 2013

    V-Model and Agile Model

    Difference between V-Model and Agile Model

    V-Model is the approach of SDLC where both Verification and Validation goes on parallel


    After every development phase it is been passed and sent it on for Testing

    Verification phase are:
    1. Requirement analysis :  All documents are prepared and gathered.
    2. High level design:     Modules are been broken into sub modules
    3. Low Level design:   Further sub modules are broken to minor modules for coding
    4. Coding:                  Here Coding and scripting is done

    Validation phase are:
    1. Acceptance testing: Prepared Acceptance test plan and done both Alpha and Beta testing
    2. System Testing:  Test Plan and Test cases are written into system
    3. Integration Testing: Both modules are integrated and tested
    4. Unit testing:   Code review or White Box testing


    Agile Model:




    Agile Model includes Scrum methodology 
    Scrum includes team members including moderator, team members, reviewer
    Every week Scrum meeting goes on and prepares a full week Scrum cycle 
    Agile model in more advantageous because of the flow of SDLC as even a small module is prepared and sent for testing so lesser amount of bugs will be reported. It is common now in the companies where they follow Agile process of development 

    Thursday 1 August 2013

    Testing Document preparation

    Test Doc should be prepared as per the requirements of SRS before starting the Testing to understand the flow of application

    Testing documentation mainly helps in preparing all types of how much of testing has to be done, the effort required, how much test coverage has to be covered, whether all the requirements are been covered. here it includes few concepts :

    Mainly Test Plan is prepared from the scratch by given Requirements document which is prepared by some of the senior team members.
    Secondly the Test Scenario is prepared from the given test plan where we can understand the flow of the test plan and cover all the scenarios.
    After preparing some test scenarios or test conditions detail Test Case are prepared and divided into number of test steps.
    Final part of Testing requires to know whether all test cases are been covered and it will be known from the result of Traceability Matrix....

    Detail explanation of Test Plan:
    A Test plan mainly consists of different strategies prepared from the given SRS and will get to know the flow of the application and what and all needs to be covered and resources what needs to be used and how much time is required to complete the schedule activities.

    Here a Test plan mainly will consist of.

    Test Plan document Introduction

    Divide the application into number of test cases

    Features to be tested and not exceptions which are not be tested

    The deliverables required for testing

    Hardware/Software requirements

    Any risks involved while testing on the given schedule

    Test Scenario

    A Statement which is prepared from the given test plan or known as test condition
    deriving into different  scenarios and further making it to test cases.
    Test cases are in detail functionality but test scenarios are just the overview
    which satisfies the functionality.

    Test Case doc

    Test cases involves in the detail step by step procedure of testing each test condition or scenarios where different types of testing is done like functionality testing, smoke testing, system testing etc. To prevent from bugs test cases are prepared and execution. Mainly test cases comprises more of negative test cases than positive test cases which is known as destructive methodology.

    Test case ID. Pre-Conditions. Description . Expected Condition. Actual Condition . Result

    Traceability Matrix is a table which is used mainly to know whether all requirements have been covered and executed in the given application it is either prepared from the excel sheet or tool.


    Friday 26 July 2013

    WhiteBoxTesting V/s BlackBoxTesting

    WhiteBoxTesting:
    Everyone might be confused there might be many types of Testing which are involved and why they are called as Boxes.
    Well mainly Box determines the Visibility or Non Visibility of what an Box can contain
    Here White BoxTesting is where we can see whats there inside the Box and its visible
    Some of the Different types are
    API testing (application programming interface)
    Static testing
    Code coverage 
    Here entire concepts are basically are coding pint of view where normally the person should be having coding knowledge so that he can view each and every point what is happening in the code and he can test by himself.

    BlackBox Testing:
    This is common and most familiar type of Testing which determines the Box is invisible and we cannot see what the Box contains i.e code cannot be viewed .
    Here BlackBox testing where normally testers use have different types of concepts used in it
    depending on what the exact specification is there for functionality.
    Few Techniques are:
    Equivalence partitioning.
    Boundary value analysis
    State Transition

    There are many other types of Testing like grey box testing, glass box testing but these are just the terms used mainly for confusion but hardly it is used except the above two.


       


    Monday 22 July 2013

    Reasons for Test Cases

    Test Cases are mainly step by step procedure for checking the functionality of the application.
    If a each module functionality has to be checked Test cases has to be written from looking into requirements
    From this at the initial stage itself the issues or specially known as Bugs can be found out and it would be easier for the developer to fix the issues rather than at the end point where everything has to meet the deadline of the Project.
    And the Tester also gets to know the Flow of the application where all possible inputs can be tested using Functionality testing
    Test Case structure:
    Test CaseId:
    Description    
    Expected Result:
    Actual Result:
    Pass/Fail
    Difference between Positive Test case and Negative Test Case
    Many of them get confused on what are Positive Test case and Negative Test case

    Well to make it simpler the,
    Positive Test case are Valid Test Cases u enter
    Negative Test case are In Valid Test Cases u enter.
    Most of the Testing has to be done using Negative Test case as the main objective of Testing
    is to Find Bugs and that is by entering Negative scenarios that will try to break the application
    and make it stable.
    Testing is mainly concept of Destructive approach than Constructive approach



    Sunday 21 July 2013

    Dedicated Testing on Web Based Application

    Hello Everybody,
    Today I have got the work of testing the application as dedicated tester where i have to go
    through all functionalities of application. So going through the requirements of it.
    How come today posting many Bugs but what will happen to the developer
    i guess he may not like it i guess :).
    But Testing is Testing not a fight between Developer its all about the Clients not about Developer. 

    Friday 19 July 2013

    Developers swap their position to Testers

    1. Its always a point to discuss who is going to become a good tester
    2. A tester which is testing knowledge or an Developer who has Developing code knowledge.
    3. Today what if Developer swaps his designation to Tester what would happen anybody thought?
    4. The application might not be as stable as the Tester does his own way of testing.
    5. Reasons are many but few of it is like
        a. Developers always focus on their coding knowledge and test based on that
        b. Going by Developers knowledge he might become good tester by ways of Constructor only not
            as  Destructor whereas Tester are known for Destructing than Constructing
        c. Developers are might be good in testing others work but not on their work :)
    6. Hence Few scenarios  of Developer

    Fight between Developer and Tester

    Today I had fight between a developer regarding one issue where he had completely rejected the bug
    But thanks to the video recorder i had sent to him that was the proof where the bug was recorded
    Developer had fixed the bug and sent  a mail the it was never a bug.
    Then I showed the video and called an meeting with Manager to show the Proof what the Develoepr has done .
    Finally this time Tester won the battle. :)

    Thursday 18 July 2013

    DEVELOPERS V/S TESTERS

    1. Developers always believe they are correct and Testers Prove them wrong.
    2. Developers always say the Bugs Posted are Invalid and but Testers make them Valid
    3. Conversation between Developer and Tester should be in Professional manner
    4. Professional important because   If they are friends they might compromise on the application
    5.  Professional important because If they are enemies the application might go hay wire.