Thursday, April 11, 2013

'Manual Testing Interview Questions Asked @ MindTree'

Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'
Apply Here
'Manual Testing Interview Questions Asked @ MindTree'





'Manual Testing Interview Questions Asked @ MindTree'




































































Company Name: MindTree

Sent By: Pradhan (QA Engineer)

Interview Questions:
  1. Tell me about yourself ?
  2. Explain about your Current Project and Roles & Responsibilities ?
  3. Which Model Following in Your Current Company and Explain About V-Model ?
    Answer :
    V- model means Verification and Validation model. Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins.  Testing of the product is planned in parallel with a corresponding phase of development. 

    The various phases of the V-model are as follows:

    Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in this model before development is started, a system test plan is created.  The test plan focuses on meeting the functionality specified in the requirements gathering.

    The high-level design (HLD) phase focuses on system architecture and design. It provide overview of solution, platform, system, product and service/process. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

    The low-level design (LLD) phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. Class diagram with all the methods and relation between classes comes under LLD. Component tests are created in this phase as well.

    The implementation and Coding phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use Execution.

    4.What is the Difference between Verification and Validation ?
       Read Answer:
    Verification: Are we building the product right?
    Validation:   Are we building the right product?

    Verification is to check whether software conforms to the specifications and is done by development team at various development phases.During development phase the SRS document ,Design Document and the code are reviewed to ensure that product is being developed using the process oriented approach.It is an in-house activity of the development organization. It is an Quality assurance activity which prevents the defects of the product.

    Validation is to check whether the software meets the customer’s expectation.This is done by testing the software for its functionality and other requirements as mentioned in Requirements Specification Documents.Validation is carried out with customer involvement.It is Quality control acitvity which detects the defect during testing of the product
    5. What Should be done After a Bug is Found?

         Read Answer:
    When a bug is found, it needs to be communicated and assigned to developers to  fix it. After the problem is resolved, fixes should be re-tested. 
    Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn’t create other problems elsewhere.
       For Datailed Bug Lifecycle :

    Defect: A fault in a program, which causes the program to perform in an unintended or unanticipated manner.

    Defect Life Cycle (Bug Life cycle) is the journey of a defect from its identification to its closure. The Life Cycle varies from organization to organization and is governed by the software testing process the organization or project follows and/or the Defect tracking tool being used.

    1) New: When QA files new bug.

    2) Assigned: 'Assigned to' field is set by lead or manager and assigns bug to developer.

    3) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as 'CNR'. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

    4) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as "Need more information'. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

    5) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.

    6) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

    7) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as 'Fixed' and the bug is passed to testing team.

    8) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as 'Reopen' so that developer can take appropriate action.

    9) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as 'Closed'.
    6. What if the Software is so buggy and it can’t be Tested at all? 

    Read Answer
    : In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs.
    Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.

    7. What if there isn’t enough time for thorough Testing? 
    Read Answer:

    Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions: 
    • Which functionality is most important to the project’s intended purpose? 
    • Which functionality is most visible to the user? 
    • Which functionality has the largest safety impact? 
    • Which functionality has the largest financial impact on users? 
    • Which aspects of the application are most important to the customer? 
    • Which aspects of the application can be tested early in the development cycle? 
    • Which parts of the code are most complex and thus most subject to errors? 
    • Which parts of the application were developed in rush or panic mode? 
    • Which aspects of similar/related previous projects caused problems? 
    • Which aspects of similar/related previous projects had large maintenance expenses? 
    • Which parts of the requirements and design are unclear or poorly thought out? 
    •  What do the developers think are the highest-risk aspects of the application? 
    • What kinds of problems would cause the worst publicity? 
    • What kinds of problems would cause the most customer service complaints? 
    • What kinds of tests could easily cover multiple functionalities? 
    • Which tests will have the best high-risk-coverage to time-required ratio?
     
    8. Who will be the Good Tester?Read Answer :
    • Good tester take the customer's point of view. he should be tactful and diplomatic. 
    • He should have a "test to break" attitude, a strong desire for quality, an attention to detail, and good communication skills, both oral and written. 
    • Previous s/w development experience is also helpful, as it provides a deeper understanding of the s/w development process.

    9. Explain About Software Testing Life Cycle ?
    Read Answer :

    Software Testing Life Cycle (STLC) defines the steps/stages/phases in testing of software. 

    The different stages in Software Testing Life Cycle:
    • Requirement Analysis
    • Test Planning
    • Test Case Design / Development
    • Environment setup
    • Test Execution / Reporting / Defect Tracking
    • Test Cycle Closure / Retrospective study

    1) Requirement Analysis
    During this phase, test team studies the requirements from a testing point of view to identify the testable requirements. The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail. Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ) .Automation feasibility for the given testing project is also done in this stage.

    Activities

    • Identify types of tests to be performed. 
    • Gather details about testing priorities and focus.
    • Prepare Requirement Traceability Matrix (RTM).
    • Identify test environment details where testing is supposed to be carried out. 
    • Automation feasibility analysis (if required).

    Deliverables 

    • RTM
    • Automation feasibility report. (if applicable)
    2) Test Planning
    This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager will determine effort and cost estimates for the project and would prepare and finalize the Test Plan.

    Activities
    • Preparation of test plan/strategy document for various types of testing
    • Test tool selection 
    • Test effort estimation 
    • Resource planning and determining roles and responsibilities.
    • Training requirement
    Deliverables 
    • Test plan /strategy document.
    • Effort estimation document.
    3) Test Case Design / Development
    This phase involves creation, verification and rework of test cases & test scripts. Test data , is identified/created and is reviewed and then reworked as well.
    Activities
    • Create test cases, automation scripts (if applicable)
    • Review and baseline test cases and scripts 
    • Create test data (If Test Environment is available)
    Deliverables 
    • Test cases/scripts 
    • Test data
    4) Test Environment Setup
    Test environment decides the software and hardware conditions under which a work product is tested. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment.
    Activities 
    • Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment. 
    • Setup test Environment and test data 
    • Perform smoke test on the build
    Deliverables 
    • Environment ready with test data set up 
    • Smoke Test Results.
    5) Test Execution / Reporting / Defect Tracking
     During this phase test team will carry out the testing based on the test plans and the test cases prepared. Bugs will be reported back to the development team for correction and retesting will be performed.
    Activities 
    • Execute tests as per plan
    • Document test results, and log defects for failed cases 
    • Map defects to test cases in RTM 
    • Retest the defect fixes 
    • Track the defects to closure
    Deliverables 
    • Completed RTM with execution status 
    • Test cases updated with results 
    • Defect reports
    6) Test Cycle Closure / Retrospective study
    Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future.
    Activities
    • Evaluate cycle completion criteria based on Time,Test coverage,Cost,Software,Critical Business Objectives , Quality
    • Prepare test metrics based on the above parameters. 
    • Document the learning out of the project 
    • Prepare Test closure report 
    • Qualitative and quantitative reporting of quality of the work product to the customer. 
    • Test result analysis to find out the defect distribution by type and severity.
    Deliverables 
    • Test Closure report 
    • Test metrics


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.

 
Vida de bombeiro Mister Colibri Recipes Informatica Humor Jokes Technology Curiosidades Science Mensagens News Tecnology Curiosity Fluz√£o Technology Curiosidades Science Car News Diario das Piadas Net Technology Messages Family Of God BLog Jokes Carros Diario das Mensagens Famosos News Noticias da TV Artesanato Science Music Travel Sports Computer Health Arts Fitness News Recipes Car Top Digital Humor Zodiac Health News Car Education Estate technology Art Science Livros Politics Music Business Women Law Downloads bunterepublikk Downs Computer Downs World Tele News Wireless