Test Your Software Testing Knowledge: Take this Mock Test

If you are preparing for the CSTE testing certification exam or thinking to give the exam in coming days then this question series will help you for preparation. Here I have included some questions from CSTE objective type question papers.

The Software Testing/Quality Assurance professionals can also take this exam to test their testing knowledge.

You can either take the printout and mark the answers or note your answers somewhere on the paper serially for all 25 questions. Verify your answers at the answer page provided at the bottom of this test page.

Test Your Software Testing Knowledge

Q #1) Verification is:
a. Checking that we are building the right system
b. Checking that we are building the system right
c. Performed by an independent test team
d. Making sure that it is what the user really wants

Q #2) A regression test:
a. Will always be automated
b. Will help ensure unchanged areas of the software have not been affected
c. Will help ensure changed areas of the software have not been affected
d. Can only be run during user acceptance testing

Q #3) If an expected result is not specified then:
a. We cannot run the test
b. It may be difficult to repeat the test
c. It may be difficult to determine if the test has passed or failed
d. We cannot automate the user inputs

Q #4) Which of the following could be a reason for failure:
1) Testing fault
2) Software fault
3) Design fault
4) Environment Fault
5) Documentation Fault
a. 2 is a valid reason; 1,3,4 & 5 are not
b. 1,2,3,4 are valid reasons; 5 is not
c. 1,2,3 are valid reasons; 4 & 5 are not
d. All of them are valid reasons for failure

Q #5) Test are prioritized so that:
a. You shorten the time required for testing
b. You do the best testing in the time available
c. You do more effective testing
d. You find more faults

Q #6) Which of the following is not a static testing technique:
a. Error guessing
b. Walkthrough
c. Data flow analysis
d. Inspections

Q #7) Which of the following statements about component testing is not true?
a. Component testing should be performed by development
b. Component testing is also known as isolation or module testing
c. Component testing should have completion criteria planned
d. Component testing does not involve regression testing

Q #8) During which test activity could fault be found most cost-effectively?
a. Execution
b. Design
c. Planning
d. Check Exit criteria completion

Q #9) Which, in general, is the least required skill of a good tester?
a. Being diplomatic
b. Able to write software
c. Having good attention to detail
d. Able to be relied on

Q #10)The purpose of the requirement phase is :
a. To freeze requirements
b. To understand user needs
c. To define the scope of testing
d. All of the above

Q #11) The process starting with the terminal modules is called –
a. Top-down integration
b. Bottom-up integration
c. None of the above
d. Module integration

Q #12) The inputs for developing a test plan are taken from :
a. Project plan
b. Business plan
c. Support plan
d. None of the above

Q #13) Function/Test matrix is a type of :
a. Interim Test report
b. Final test report
c. Project status report
d. Management report

Q #14) Defect Management process does not include:
a. Defect prevention
b. Deliverable base-lining
c. Management reporting
d. None of the above

Q #15) What is the difference between testing software developed by contractor outside your country, versus testing software developed by a contractor within your country?
a. Does not meet people needs
b. Cultural difference
c. Loss of control over reallocation of resources
d. Relinquishments of control

Q #16) Software Testing accounts for what percent of software development costs?
a. 10-20
b. 40-50
c. 70-80
d. 5-10

Q #17) A reliable system will be one that:
a. Is unlikely to be completed on schedule
b. Is unlikely to cause a failure
c. Is likely to be fault-free
d. Is likely to be liked by the users

Q #18) How much testing is enough: 
a. This question is impossible to answer
b. The answer depends on the risks for your industry, contract and special requirements
c. The answer depends on the maturity of your developers
d. The answer should be standardized for the software development industry

Q #19) Which of the following is not a characteristic for Testability?
a. Operability
b. Observability
c. Simplicity
d. Robustness

Q #20) Cyclomatic Complexity method comes under which Testing method:
a. White box
b. Black box
c. Green box
d. Yellow box

Q #21) Which of these can be successfully tested using Loop Testing methodology?
a. Simple Loops
b. Nested Loops
c. Concatenated Loops
d. All of the above

Q #22) To test a function, the programmer has to write a ______, which calls the function and passes it test data.
a. Stub
b. Driver
c. Proxy
d. None of the above

Q #23) Equivalence partitioning is:
a. A black box testing technique used only by developers
b. A black box testing technique than can only be used during system testing
c. A black box testing technique appropriate to all levels of testing
d. A white box testing technique appropriate for component testing

Q #24) When a new testing tool is purchased, it should be used first by:
a. A small team to establish the best way to use the tool
b. Everyone who may eventually have some use for the tool
c. The independent testing team
d. The vendor contractor to write the initial scripts

Q #25) Inspections can find all the following except:
a. Variables not defined in the code
b. Spelling and grammar faults in the documents
c. Requirements that have been omitted from the design documents
d. How much of the code has been covered


Click here to Verify your answers.

Recommended Reading

453 thoughts on “Test Your Software Testing Knowledge: Take this Mock Test”

  1. 11. The process starting with the terminal modules is called –
    a. Top-down integration
    b. Bottom-up integration
    c. None of the above
    d. Module integration

    Answer for this must be ‘a’ and ‘b’ both.

    Reason: ‘Terminal’ Module is a node from where data starts and terminates too. In a software product, the ‘terminals’ where data terminates are also the same nodes from where the data had started initially. So, the data can either starts from a ‘top node’ or from the ‘bottom node’, both nodes are called as ‘Terminal Nodes’. So the process starting with the terminal modules would be either ‘top-down integration’ or ‘bottom-up integration’. Both answers are correct.

    • Hi Anil,
      Iam also scheduled CSTE Test next month ,part 2 subjective questions are paper pen based or computer based,please answer me?

  2. This is the best site to gain knowledge for testing.
    The test is really very useful and helpful….. Thanks for providing the information .

  3. Answer for the question

    1. Verification is:
    a. Checking that we are building the right system
    b. Checking that we are building the system right
    c. Performed by an independent test team
    d. Making sure that it is what the user really wants

    answer should be ‘a’

  4. Hello all! I like this forum, i inaugurate numberless interesting people on this forum.!!!

    Great Community, good all!

  5. Hi Trupti Gandhi .. diff between QC and QA is
    QC: 1) related to product
    2) don to access defects in product
    3) responsibility of every team member
    1) related to process by which product is made
    2) don to find weakness in the process by which product is made
    3) Responsibility by upper mgmt

  6. if we have 1000 web pages site. what technique is used to test the functionality of unchanged component in the regression testing. if there is no option of Automation Testing?

  7. if we have 1000 web pages site. what technique is used to test the functionality of unchanged component in the regression testing. if there is no option of Automation Testing?
    ANS-U can go for regional regression testing …..
    i this you can select the area which may be impacted by change made in othe modul

  8. Hi Friends

    this is my answers for the above question pls correct me if i am wrong
    1 b
    2 b
    3 d
    4 d
    5 b
    6 a
    7 a
    8 d
    9 a
    10 d
    12 a
    13 c
    14 c
    15 d
    16 b
    17 c
    18 b
    19 d
    20 a
    21 b
    22 a
    23 c
    24 b
    25 a


  9. hi…
    it is very informative to all.. but we need this with the facility of online exams(with radio button). then ly guys going to feel good and easy to write more xams.. peoples are so tired to check the answer…

  10. hi..,
    i m new to testing field n i have finished my course but need to attend exam to complete course but i dono any abt QTP pls anybody help me out….

  11. Please suggest me or send me how to answer generally for a question like what you have done or what type of testing you done on the mentioned project


    1. Introduction
    2. Testing?
    3. Software testing?
    4. SDLC(Software Development Life Cycle)
    5. STLC(Software testing life cycle)
    6. Why Testing?
    7. Who does testing?
    8. When to start testing?
    9. When to stop testing?
    10. Type of testing
    10.1 Manual Testing
    10.2 Automation Testing
    10.2.1 What to automate?
    10.2.2 When to Automate?
    10.2.3 How to Automate?
    11. Testing Methods
    11.1 Black Box Testing
    11.2 White Box Testing
    11.3 Gray Box Testing
    8.1.1 Advantages
    8.1.2 Disadvantages
    12. Levels of Testing
    12.1 Functional Testing
    12.1.1 Unit Testing
    12.1.2 Integration Testing
    12.1.3 System Testing
    12.1.4 Regression Testing
    12.1.5 Acceptance Testing
    12.2 Non- functional Testing
    12.2.1 Performance Testing Load Testing Stress Testing
    12.2.2 Usability Testing
    12.2.3 Security Testing
    12.2.4 Portability Testing
    13. What is web testing?
    14. Type of web testing
    14.1 Functionality Testing
    14.2 Usability testing
    14.3 Interface testing
    14.4 Database Testing
    14.5 Compatibility testing
    14.6 Performance testing
    14.7 Security testing
    14.8 Crowd Testing
    15. Testing Documentation
    15.1 Test Plan
    15.2 Test Strategy
    15.3 Test Scenario
    15.4 Test Case
    15.5 Test Script
    15.6 Testing Environment
    15.7 Test Procedure
    15.8 Test Log
    15.9 Traceability Matrix
    16. What is Bug?
    17. Bug Life Cycle
    17.1 New
    17.2 Open
    17.3 Assign
    17.4 Test
    17.5 Verified
    17.6 Deferred
    17.7 Reopened
    17.8 Duplicate
    17.9 Rejected
    17.10 Closed
    18. Bugzilla, JIRA and Mantis
    19. Bug Reporting

    Is the process of identifying defects, where a defect is any variance between actual and expected results.

    “A process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item”

    DEFECT: Mismatch between the requirements, or unexpected result or wrong calculations.
    BUG: Deviation from the expected result, or If something is already documented to be implemented and implementation is not consistent as per requirement then it’s a BUG.

    ERRORS: When we get the wrong output i.e. syntax error, logical error, or programmatically mistake lead to error.

    Failure: When everything is correct but we are not able to get result. Or When software is released, the customers found some defect or application may be crash by using any wrong functionality that is called software failure.
    Software Testing
    Testing with a Purpose

    Software testing is performed to verify that the completed software package functions according to the expectations defined by the requirements/specifications. The overall objective to not to find every software bug that exists, but to uncover situations that could negatively impact the customer, usability and/or maintainability.

    SDLC and STLC

    Requirement Phase
    System Analysis
    Design phase

    It involves following stages
    • Preparation of the test strategy
    • Preparation of the test plan
    • Creation of the test environment
    • Writing of the test cases
    • Creation of the test scripts
    • Execution of the test scripts
    • Analysis of the test results

    • Reporting of the bugs
    • Performing regression testing
    System study
    Test planning
    Writing test case or script
    Review test case
    Executing test case
    Bug tracking
    Report the detect
    Test Planning (Test Strategy) (done by Test TL/ PM)
    Test Analysis (BRS/SRS) (Test Engineer)
    Test Design (Test Scenario/Test Cases/Test Data) (Test Engineer)
    Test Execution (Executing test case and reporting defect) (Test Engineer)
    Test Closure (Test Summary Report) (Test TL/PM/Test Engineer)

    Why testing is important?
    Testing is about verifying that what was specified; what was delivered. In simple word software is activity to check whether the actual result match the excepted result. It is very important to understand that testing is also continuous process. Testing does not stand alone it is intimately dependent activity but it is separate process activity. Testing is the activity is the reduce the defect

    Who does testing?
    • Software Tester
    • Software Developer
    • Project Lead/Manager
    • End User

    Different companies have difference designations for people who test the software on the basis of their experience and knowledge such as Software Tester, Software Quality Assurance Engineer, and QA Analyst etc.

    It is not possible to test the software at any time during its cycle. The next two sections state when testing should be started and when to end it during the SDLC.
    When to Start Testing

    An early start to testing reduces the cost, time to rework and error free software that is delivered to the client. However in Software Development Life Cycle (SDLC) testing can be started from the Requirements Gathering phase and lasts till the deployment of the software. However it also depends on the development model that is being used. For example in Water fall model formal testing is conducted in the Testing phase, but in incremental model, testing is performed at the end of every increment/iteration and at the end the whole application is tested.
    Testing is done in different forms at every phase of SDLC like during Requirement gathering phase, the analysis and verifications of requirements are also considered testing. Reviewing the design in the design phase with intent to improve the design is also considered as testing. Testing performed by a developer on completion of the code is also categorized as Unit type of testing.

    When to Stop Testing

    Unlike when to start testing it is difficult to determine when to stop testing, as testing is a never ending process and no one can say that any software is 100% tested. Following are the aspects which should be considered to stop the testing:

    • Testing Deadlines.
    • Completion of test case execution.
    • Completion of Functional and code coverage to a certain point.
    • Bug rate falls below a certain level and no high priority bugs are identified.
    • Management decision.

    Testing Types
    This section describes the different types of testing which may be used to test a Software
    during SDLC.
    1. Manual Testing
    2. Automation Testing

    Manual Testing:
    This type includes the testing of the Software manually i.e. without using any automated tool or any script. In this type the tester takes over the role of an end user and test the Software to identify any un-expected behavior or bug. There are different stages for manual testing like unit testing, Integration testing, System testing and User Acceptance testing.

    Testers use test plan, test cases or test scenarios to test the Software to ensure the completeness of testing. Manual testing also includes exploratory testing as testers explore the software to identify errors in it.

    Automation Testing :
    Automation testing which is also known as “Test Automation”, is when the tester writes scripts and uses another software to test the software. This process involves automation of a manual process. Automation Testing is used to re-run the test scenarios that were performed manually, quickly and repeatedly Apart from regression testing, Automation testing is also used to test the application from load, performance and stress point of view. It increases the test coverage; improve accuracy, saves time and money in comparison to manual testing.

    What to automate: It is not possible to automate everything in the Software; however the areas at which user can make transactions such as login form or registration forms etc, any area where large amount of users’ can access the Software simultaneously should be automated.

    When to Automate: Test Automation should be uses by considering the following for the Software:
    • Large and critical projects.
    • Projects that require testing the same areas frequently.
    • Requirements not changing frequently.
    • Accessing the application for load and performance with many virtual users.
    • Stable Software with respect to manual testing.
    • Availability of time.

    How to Automate: Automation is done by using a supportive computer language like VB scripting and an automated software application. There are a lot of tools available which can be used to write automation scripts. Before mentioning the tools lets identify the process which can be used to automate the testing:

    • Identifying areas within a software for automation.
    • Selection of appropriate tool for Test automation.
    • Writing Test scripts.

    • Development of Test suits.
    • Execution of scripts
    • Create result reports.
    • Identify any potential bug or performance issue.

    Following are the tools which can be used for Automation testing:
    • HP Quick Test Professional
    • Selenium
    • IBM Rational Functional Tester
    • Silk Test
    • Test Complete
    • Testing Anywhere
    • Win Runner
    • Logrunner
    • Visual Studio Test Professional
    • WATIR

    Testing Methods

    1) Black Box Testing 2) White Box Testing 3) Gray Box Testing

    Black Box Testing
    The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, when performing a black box test, a tester will interact with the system’s user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.

    • Well suited and efficient for large code segments.
    • Code Access not required.
    • Clearly separates user’s perspective from the developer’s perspective through visibly defined roles.
    • Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language or operating systems.

    • Limited Coverage since only a selected number of test scenarios are actually performed.
    • Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
    • Blind Coverage, since the tester cannot target specific code segments or error prone areas.
    • The test cases are difficult to design.

    White Box Testing
    White box testing is the detailed investigation of internal logic and structure of the code. White box testing is also called glass testing or open box testing. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code. The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving inappropriately.

    As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.

    • It helps in optimizing the code.
    • Extra lines of code can be removed which can bring in hidden defects.
    • Due to the tester’s knowledge about the code, maximum coverage is attained
    during test scenario writing.

    • Due to the fact that a skilled tester is needed to perform white box testing, the costs are increased.
    • Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems as many paths will go untested.
    • It is difficult to maintain white box testing as the use of specialized tools like code analyzers and debugging tools are required.

    Gray Box Testing
    Grey Box testing is a technique to test the application with limited knowledge of the internal workings of an application. In software testing, the term “the more you know the better” carries a lot of weight when testing an application.

    Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike black box testing, where the tester only tests the application’s user interface, in grey box testing, the tester has access to design documents and the database. Having this knowledge, the tester is able to better prepare test data and test scenarios when making the test plan.

    • Offers combined benefits of black box and white box testing wherever possible.
    • Grey box testers don’t rely on the source code; instead they rely on interface definition and functional specifications.
    • Based on the limited information available, a grey box tester can design excellent test scenarios especially around communication protocols and data type handling.
    • The test is done from the point of view of the user and not the designer.

    • Since the access to source code is not available, the ability to go over the code and test coverage is limited.
    • The tests can be redundant if the software designer has already run a test case.
    • Testing every possible input stream is unrealistic because it would take an
    unreasonable amount of time; therefore, many program paths will go untested.

    Levels of Testing
    1) Functional Testing. 2) Non- functional Testing.

    Functional Testing:
    Unit Testing
    Integration Testing
    System Testing
    Regression Testing
    Acceptance Testing

    Non-Functional Testing
    Performance Testing
    Load Testing
    Stress Testing
    Usability Testing
    Security Testing
    Portability Testing

    Testing Documentation
    Testing documentation involves the documentation of Software testing helps in estimating the testing effort required, test artifacts which should be developed before or during the testing of Software. Documentation for coverage, requirement tracking/tracing etc. This section includes the description of some commonly used documented artifacts related to Software testing such as:
    • Test Plan
    • Test Strategy
    • Test Scenario
    • Test Case
    • Test Script
    • Testing Environment
    • Test Procedure
    • Test Log
    • Traceability Matrix

    Test Plan:
    Test plan is a document with information on a scope of the project, Approach, Schedule of testing activities, Resource or manpower

    Test Scenario:

    Test Case:

    Traceability Matrix:
    Traceability Matrix

    The Traceability Matrix is to be able to trace from top level requirements to implementation, and from top level requirements to test. It shows the relationship between Test Requirements and Test Cases.
    Using Traceability Matrix, we can check that which requirements are covered in which
    Test cases and which test case covers which requirements. The same apply for the code too means which codes are covered which requirements and which requirements are covered in which section of the code too.
    They are types of traceability matrix:
    1. Forward traceability
    2. Backward traceability
    3. Bidirectional traceability
    Requirement———————-?Test Case
    Requirement<———————-Test Case
    Requirement>internet option >>General tab>>under Browsing history>>Click on setting>>there you find current location of cookies
    Basically you can change your browser setting according to your need. If you want that before storing the cookies by web site it will shows prompt message or something warning so you can change the setting or Even you can disable the cookies also.

    Cookie Attribute:
    Cookie basically come with name-value pair, apart from that server set expiration time, path, cookie domain ,maximum age.

    Now the next questing is how to test Cookie? How to do Cookie testing?
    Disabling/Deleting the Cookie:
    Delete the all cookie set by site which under test. One thing which is important that deleting Cookie you need to close browser so that no pre-session cookies in memory.
    After that test those feature and function of the site which require the cookie ,you will come to know that those feature doesn’t work because of deleting those cookies which help to run the feature. That doesn’t mean it’s bug, it’s happened because of the disabling the cookies. It’s might possible that not every user keep the cookie enable, In that case those site require cookie need to be enabled to work the site then the site has to be send message to user that cookie need to be enable to work the site.

    Reject Cookie:
    You can do testing of cookie by accepting some cookies and rejecting other and check the functionality howspan style=”mso-spacerun:yes”>
    iit work by rejecting cookie. For that you need to set your browser’s cookie option to prompt you whenever website attempts to set a cookie and then exercise the functionality.
    Corrupt the Cookie:
    For that you need to know whether the cookies are stored. Then change the cookie parameter like cookie name, expiry date, session id and all.
    Check that Cookie generated by different browser:
    Here the site which is under test which need to be check different browser. That different browser site generated the cookie or not .

    Check the how Cookie stored sensitive Data:
    It’s important that sensitive data need to be stored in encrypted format.Sensitiva data like User credit card ID,User Data etc.So even if some one open the cookies file then can not mess with the data. So that need to be check how the cookie stored the sensitive data.

    Test HTML and CSS to ensure that search engines can crawl your site easily. This will include
    • Checking for Syntax Errors
    • Readable Color Schemas
    • Standard Compliance. Ensure standards such W3C, OASIS, IETF, ISO, ECMA, or WS-I are followed.

    Test business workflow- This will include
    • Testing your end – to – end workflow/ business scenarios which takes the user through a series of webpage’s to complete.
    • Test negative scenarios as well, such that when a user executes an unexpected step , appropriate error message or help is shown in your web application.

    2) Usability testing

    Usability testing has now become a vital part of any web based project. It can carried out by testers like you or a small focus group similar to the target audience of the web application.
    Test the site Navigation:
    • Menus , buttons or Links to different pages on your site should be easily visible and consistent on all WebPages

    Test the Content:
    • Content should be legible with no spelling or grammatical errors.
    • Images if present should contain and “alt” text

    3) Interface testing

    Three areas to be tested here are – Application, Web and Database Server
    • Application: Test requests are sent correctly to the Database and output at the client side is displayed correctly. Errors if any must be caught by the application and must be only shown to the administrator and not the end user.
    • Web Server: Test Web server is handling all application requests without any service denial.
    • Database Server: Make sure queries sent to the database give expected results.
    Test system response when connection between the three layers (Application, Web and Database) can not be established and appropriate message is shown to the end user.

    4) Database Testing

    Database is one critical component of your web application and stress must be laid to test it thoroughly. Testing activities will include-
    • Test if any errors are shown while executing queries
    • Data Integrity is maintained while creating, updating or deleting data in database.
    • Check response time of queries and fine tune them if necessary.
    • Test data retrieved from your database is shown accurately in your web application

    5) Compatibility testing

    Compatibility tests ensure that your web application displays correctly across different devices. This would include-

    Browser Compatibility Test:
    Same website in different browsers will display differently. You need to test if your web application is being displayed correctly across browsers , JavaScript , AJAX and authentication is working fine. You may also check for Mobile Browser Compatibility.

    The rendering of web elements like buttons, text fields etc changes with change in Operating System. Make sure your website works fine for various combinations of Operating systems such as Windows, Linux, Mac and Browsers such as Firefox, Internet Explorer, Safari etc.

    6) Performance testing

    This will ensure your site works under all loads. Testing activities will include but not limited to –
    • Website application response times at different connection speeds
    • Load test your web application to determine its behavior under normal and peak loads
    • Stress tests your web site to determine its break point when pushed to beyond normal loads at peak time.
    • Test if a crash occurs due to peak load , how does the site recover from such an event
    • Make sure optimization techniques like zip compression , browser and server side cache enabled to reduce load times

    7) Security testing

    Security testing is vital for e-commerce website that store sensitive customer information like credit cards. Testing Activities will include-
    • Test unauthorized access to secure pages should not be permitted
    • Restricted files should not be downloadable without appropriate access
    • Check sessions are automatically killed after prolonged user inactivity
    • On use of SSL certificates , website should re-direct to encrypted SSL pages.

    8) Crowd Testing

    You will select a large number of people (crowd) to execute tests which otherwise would have been executed a select group of people in the company. Crowd sourced testing is an interesting and upcoming concept and helps unravel many a unnoticed defects.

    Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT)

    Bug Life Cycle:

    In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:

    The different states of a bug can be summarized as follows:

    1. New
    2. Open
    3. Assign
    4. Test
    5. Verified
    6. Deferred
    7. Reopened
    8. Duplicate
    9. Rejected and
    10. Closed

    Description of Various Stages:

    1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.

    2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.

    3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.

    4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.

    5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

    6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.

    7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.

    8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.

    9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.

    10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.

  13. It is the process of executive software in a controlled manner In order to answer the question does the software behaved specified,
    Are we doing the right job?
    are we doing the job right ?
    IV &V

  14. Hi frenz, I am preeya, BE CSE fresher. I have interest in software testing. I’m learning it on my own. I have few doubts.. plzz help me.. Is it necessary to take up any software course??? or Can i do ISTQB certification?? Give me some ideas. pls. My mail ID:preeyakrish91@gmail.com


Leave a Comment