• RSS
  • Facebook
  • Twitter

One Center for all the Testing Need. OneTestingCenter is for all, for all QA, for all Automation. Automation is easy, fun and enriching experience. Happy Learning and Happy Testing!

  • Access to All QA

    At OneTestingCenter, you find lots of books,articles,blogs and detailed guides. Everyone has access to QA. Happy Learning, Happy Testing.

  • Global Trainings

    All the QA/Auotmation trainings are available at OneTestingCenter. QA, Automation, QTP/UFT, Selenium, LoadRunner, QC/ALM, Appium...

  • Automation Learning Fun

    Technology is always evolving. Automation is always challenging. To be frank, Automation is fun, enthusiastic and enrching experience.

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    Software Testing Process:
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

    Testing Process:

    Testing process is the systematic approach where the complete test implementation takes place from start (requirements analysis) to end (Application Delivery and Support).

    There are several stages / several layers that take part as part of the testing process.
    Let us discuss the Testing Process.

    There are several types of questions that can be asked in Interviews like:

    o    What’s the testing process in your organization?
    o    Have you got any process to test the application?
    o    How do you test the application?
    o    Can you draw out a flow chart for the testing implementation?
    o    And so on. Similar to the above questions..
                  
    TESTING PROCESS: 

    Testing process begins right from Requirements Analysis where we review, analyze, understand the requirements and if there are any clarifications, we would get it clarified (Using clarification sheet) and when the requirement analysis is done and when all the requirements are clear and understood, we (QA) would continue with Test Plan design, Test Cases designing and Test Setups preparations.
    During this time DEV would have been ready with all the code (with the integrated build) which is checked into the DEV Source Control System and they would indicate QA for Test Start up.

    Now, we (QA) would take the build and set up that build on our (QA) Test machines and we would start testing that build initially with the Smoke Testing.


    If Smoke Testing fails (If we find any critical bug / defects / issues in that build at initial stage) then the issues are logged onto Defect Tracking Tool (such as Quality Center / Test Director / Bugzilla / Team Foundation Server / Team Tracker / Merant Tracker and so on) and we (QA) rejected the BUILD to the DEV and they have to rectify and fix the issues (what QA reported at this stage) and they should revert back with a new BUILD to QA.

    Bug / Defect / Issue:

    o    Defect is the deviation from the requirement.
    o    Defect is the difference between expected and actual results.
    o    Defect is the issue caused in the application (by the code)
    o    Defect is the misbehavior of the application (incorrect functionality)

    If Smoke Testing is passed then we would continue the Application with major testing (Functional / Integration / System Testing / Automation).

    And as part of this testing, if there are any bugs/defects / issues then we (QA) would log them into Defect tracking System and this information is indicated to the DEV and QA (by email triggering / auto mail generation process). The DEV would fix these bugs and would generate next version of the builds and these builds are released to QA. We (QA) would take those secondary builds for Bug Verification and Regression Tests.  These Bug Verification and Regression Tests are carried out for all of builds that are generated by DEV after issues fixes (After the first stable build).

    As part of each testing, we (QA) would use QA Metrics to calculate the Quality and Test Status for all the tests and these metrics are reporting to the team for all the builds / tests wise.

    QA Metrics:
    QA Metrics are those which measure the QUALITY of the Application.

    There are several metrics (Later on, we would learn these metrics separately)

    o    Stability Trend Chart
    o    Defects per Module
    o    Defects per Test             
    o    Defects per KLOC (kilo lines of code)
    o    Test Coverage

    This testing (main testing on Base build and Bug verification and regression testing on next version builds continues on all the builds) continues until we are done with all testing and once all the issues are addressed and fixed (fixed by DEV) and verified (verified by QA).

    After all the errors are fixed and entire testing is done then the Customer would check it for verification with UAT (User Acceptance Testing).

    o    UAT is customer verification testing.
    o    It can be done in two ways
    o   Alpha Testing (α)
    o   Beta Testing (β)
    ·         Alpha Testing is often performed by potential users / customers or an independent test team at the developers' site.
    ·         It is usually done when the development of the software product is nearing completion; minor design changes may still be made as a result of Alpha testing. 
    ·         The second stage coming after alpha testing is known as "Beta Testing".
    ·         Versions of the software, known as beta versions, are released to a limited audience outside of the programming team so that further evaluation by the users can reveal more faults or bugs in the product.
    ·         Sometimes, beta versions are made available to the open public to increase the feedback field to a maximum number of future users.
    ·         Usually it is done at customer places or customer like places (end users)

    Once all goes fine, when the customer is happy to accept the build, then the build is released to live and is called application and we (QA) would continue with application support (maintenance phase)

    Thus the TESTING PROCESS begins and ends up in the organization.



    Reactions:

    Software Testing Process

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    Software Testing Process:
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

    Testing Process:

    Testing process is the systematic approach where the complete test implementation takes place from start (requirements analysis) to end (Application Delivery and Support).

    There are several stages / several layers that take part as part of the testing process.
    Let us discuss the Testing Process.

    There are several types of questions that can be asked in Interviews like:

    o    What’s the testing process in your organization?
    o    Have you got any process to test the application?
    o    How do you test the application?
    o    Can you draw out a flow chart for the testing implementation?
    o    And so on. Similar to the above questions..
                  
    TESTING PROCESS: 

    Testing process begins right from Requirements Analysis where we review, analyze, understand the requirements and if there are any clarifications, we would get it clarified (Using clarification sheet) and when the requirement analysis is done and when all the requirements are clear and understood, we (QA) would continue with Test Plan design, Test Cases designing and Test Setups preparations.
    During this time DEV would have been ready with all the code (with the integrated build) which is checked into the DEV Source Control System and they would indicate QA for Test Start up.

    Now, we (QA) would take the build and set up that build on our (QA) Test machines and we would start testing that build initially with the Smoke Testing.


    If Smoke Testing fails (If we find any critical bug / defects / issues in that build at initial stage) then the issues are logged onto Defect Tracking Tool (such as Quality Center / Test Director / Bugzilla / Team Foundation Server / Team Tracker / Merant Tracker and so on) and we (QA) rejected the BUILD to the DEV and they have to rectify and fix the issues (what QA reported at this stage) and they should revert back with a new BUILD to QA.

    Bug / Defect / Issue:

    o    Defect is the deviation from the requirement.
    o    Defect is the difference between expected and actual results.
    o    Defect is the issue caused in the application (by the code)
    o    Defect is the misbehavior of the application (incorrect functionality)

    If Smoke Testing is passed then we would continue the Application with major testing (Functional / Integration / System Testing / Automation).

    And as part of this testing, if there are any bugs/defects / issues then we (QA) would log them into Defect tracking System and this information is indicated to the DEV and QA (by email triggering / auto mail generation process). The DEV would fix these bugs and would generate next version of the builds and these builds are released to QA. We (QA) would take those secondary builds for Bug Verification and Regression Tests.  These Bug Verification and Regression Tests are carried out for all of builds that are generated by DEV after issues fixes (After the first stable build).

    As part of each testing, we (QA) would use QA Metrics to calculate the Quality and Test Status for all the tests and these metrics are reporting to the team for all the builds / tests wise.

    QA Metrics:
    QA Metrics are those which measure the QUALITY of the Application.

    There are several metrics (Later on, we would learn these metrics separately)

    o    Stability Trend Chart
    o    Defects per Module
    o    Defects per Test             
    o    Defects per KLOC (kilo lines of code)
    o    Test Coverage

    This testing (main testing on Base build and Bug verification and regression testing on next version builds continues on all the builds) continues until we are done with all testing and once all the issues are addressed and fixed (fixed by DEV) and verified (verified by QA).

    After all the errors are fixed and entire testing is done then the Customer would check it for verification with UAT (User Acceptance Testing).

    o    UAT is customer verification testing.
    o    It can be done in two ways
    o   Alpha Testing (α)
    o   Beta Testing (β)
    ·         Alpha Testing is often performed by potential users / customers or an independent test team at the developers' site.
    ·         It is usually done when the development of the software product is nearing completion; minor design changes may still be made as a result of Alpha testing. 
    ·         The second stage coming after alpha testing is known as "Beta Testing".
    ·         Versions of the software, known as beta versions, are released to a limited audience outside of the programming team so that further evaluation by the users can reveal more faults or bugs in the product.
    ·         Sometimes, beta versions are made available to the open public to increase the feedback field to a maximum number of future users.
    ·         Usually it is done at customer places or customer like places (end users)

    Once all goes fine, when the customer is happy to accept the build, then the build is released to live and is called application and we (QA) would continue with application support (maintenance phase)

    Thus the TESTING PROCESS begins and ends up in the organization.