Selenium & Manual Interview Questions
Components of Selenium?
Selenium IDE: Installs as an add-on in Mozilla. It only runs in Mozilla. Its got a strong feature of record and run. You can also extend IDE functionality with the help of user extensions. It supports regular extensions, loops if statements, and many other features. You can also parameterize your test cases using IDE. Selenium RC: This is the older version of selenium. It works on multiple browsers. RC can be implemented in any one of the programming languages mentioned above.
Webdriver: Webdriver is the new version of selenium. It also works on multiple browsers. Its removed many drawbacks and issues in Selenium RC. It also supports Android and iPhone Testing.
Grid: Grid is used to test cases parallel on multiple machines and browsers.
What is the test plan?
Ans: The Test Plan document derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents. The Test Lead or Test Manager usually prepare the Test Plan document, and the focus of the document is to describe what to test, how to test when to test and who will do what test. It is common to have one Master Test Plan, which is a common document for the test phases and each test phase have their Test Plan documents. Typically Test Plan will have the following.
- Test Plan id
- Test items
- Features to be tested
- Features not to be tested
- Test techniques
- Testing tasks
- Suspension criteria
- Features pass or fail criteria
- Test environment (Entry criteria, Exit criteria)
- Test deliverable
- Staff and training needs
This is a standard approach to prepare test plan, but things can vary company-to-company.
What is the difference between agile methodology and other SDLC models?
Ans: Scrum is an innovative approach to getting work done efficiently. It is an iterative & incremental agile software development method. These iterations are time-boxed with various iterations & each iteration is called Sprint. The Sprint is a 2-4 week long & each sprint requires sprint planning estimation. According to the latest surveys, Scrum is the most popular agile project management methodology in software development. The term Scrum formed from Rugby. Scrum ideally used where highly emergent or rapidly changing requirements. Scrum worked on a self-organizing, cross-functional team. In the overall scrum team, no team leader assigns the task to the team. Rather whole scrum members work as a team & they decide the task on which they will work on. Also, the problem will be resolved by the team. Each Agile Development Scrum team having three core scrum roles: Product Owner, Scrum Master & The Team.
- Product Owner: The Product Owner is the person who represents the stakeholders and is the voice of the customer. The product owner writes the User Stories, ordered priorities, and add in the Product Backlog. It recommended that the Agile Scrum Master should not mix with the Product Owner; both members should be different as each member has its responsibilities.
- Scrum Master: The Scrum Master is a facilitation team leader who ensures that the team adheres to its chosen process and removes blocking issues to deliver the sprint deliverable/goal. Scrum Master is not a team leader but acts as a shield for the team from external interferences & also removes barriers. Scrum Master facilitates the daily scrums.
- The Team: The scrum development team is generally the size of 5-9 peoples with self-organizing and cross-functional skills who do actual work like Analysis, Design, Development, Testing, Documentation, etc. At the start of every Scrum Sprint, the team members are committed to delivering a few tasks from the Scrum Product Backlog. Over the sprint time-boxed the teamwork on developing, testing, integrating feature & end of the Sprint in the Sprint Review Meeting this functionality demoed to Product Owner & interested Stakeholders. In this meeting, they can give feedback, if any, on the developed product, which could influence the next sprint. The main artifact in the Agile Scrum project is the product itself. The team is working efficiently on the product to deliver the shippable product after the end of every sprint. The Product Backlog is a place where all requirements are ordered and written in the user story format. These user stories are ordered & prioritized by the Product Owner based on risk, business value, date needed, dependencies, etc. so that most valuable features picked in Sprint first.
- Product Backlog: The Product Backlog is an ordered & prioritized list of items that all need to include in the product. It is dynamic & during the project, items may add or delete from this list. All items ordered prioritized in this list. The highest priority items completed first.
- Sprint Backlog: In the sprint planning meeting, the team picks a list of User stories from Product Backlog. These selected items moved from the Product Backlog to Sprint Backlog. All sprint backlog user stories are discussed items from the product backlog and team member committed to complete the assigned task within Sprint Time boxed. Each user story divided into smaller, detailed tasks. Sprint team works together collaboratively to complete Sprint tasks.
- Daily SCRUM: The Daily SCRUM is not used as a problem-solving or issue resolution meeting. In the Daily SCRUM, each of the team members should answer three questions:
What did you do yesterday?
What will you do today?
Are there any obstacles in your way? In the Daily, SCRUM team share the conflicts, obstacle or impediment faced in their tasks & any possible solutions on that. Daily, this meeting holds at the same time, same location hold by the Agile SCRUM team. Ideally, “The Daily SCRUM” is conducted in the morning, which helps to plan a task for the whole day. As an Agile process & Sprint is time-boxed, similarly Daily SCRUM meeting should be time-boxed to 15 minutes max. In this meeting, the discussion should be quick and relevant. The Scrum Master always helps to maintain the focus of the team on its Sprint goal.
- A Sprint Burndown: Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint. It is a very effective visual indicator to get the correlation between work remaining at any point of time & the actual progress of the team. Before the Daily SCRUM meeting, Sprint Burndown chart should be updated so it will help to understand the progress of Sprint daily & makes any adjustments if needed.
- Shippable Product: The end of the Sprint can turn into an increment of potentially shippable functionality hand over to the customer. This shippable functionality should be well-structured, well-written code, thoroughly tested, and user operation of the functionality documented. At the end of the Sprint, features committed in Sprint are demonstrated to all stakeholders & they provide valuable feedback to moving products in the correct direction.
- Sprint Retrospective: At the end of each Sprint Review and Retrospective meeting should be conducted to know what went good & bad in Sprint. Participants for this meeting are Team, SCRUM Master & Product Owner(Listener). This meeting also timeboxed to 2-3 hours. Using this approach, each team member is asked to identify specific things that the team should:
Iterations are a key feature of the SCRUM process. In the next Sprint again, the team choose the chunk of User stories from the Product Backlog & Sprint cycle started with new Sprint goals again. These cycles are continued doing unless and until Product backlog finished or Deadline reaches or budget is used up. Agile SCRUM ensured that all high priority task ordered top in the Product backlog so those can get completed first before the project ends.
Explain the Bug Lifecycle?
Ans: Defect: A fault in a program, which causes the program to perform in an unintended or unanticipated manner. Defect Life Cycle (Bug Lifecycle) is the journey of a defect from its identification to its closure. The Life Cycle varies from organization to organization and governed by the software testing process, the organization or project follows and/or the Defect tracking tool being used.
- New: When QA files a new bug.
- Assigned: ‘Assigned to’ field is set by the lead or manager and assigns the bug to the developer.
- Could not reproduce: If the developer is not able to reproduce the bug by the steps given in the bug report by QA, then the developer can mark the bug as ‘CNR.’ QA needs action to check if the bug is reproduced and can assign to a developer with detailed reproducing steps.
- Need more information: If the 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 the bug back to dev for the fix.
- Deferred: If the bug is not related to current build or cannot be fixed in this release or bug is not important to fix immediately, then the project manager can set the bug status as deferred.
- Rejected/Invalid: Sometimes, the 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.
- Resolved/Fixed: When a developer makes necessary code changes and verifies the changes, then he/she can make bug status as ‘Fixed,’ and the bug passed to the testing team.
- Reopen: If QA is not satisfied with the fix and if the bug is still reproducible even after fix, then QA can mark it as ‘Reopen’ so that the developer can take appropriate action.
- Closed: If the QA team verifies the bug and if the fix is ok and the problem is solved, then QA can mark the bug as ‘Closed.’
Can you tell me about yourself? (For Experienced Candidates)
Ans: In my QA Or Testing career, I have been working on various system platforms and operating systems like Windows 95, Windows 2000, Windows XP, and UNIX. I have tested applications developed in Java, C++, Visual Basic, and so on. I have tested Web-based applications as well as client-server applications. As a QA person, I have written Test Plans, Test Cases, attended walkthrough meetings with the Business Analysts, Project Managers, Business Managers, and QA Leads. I have attended requirement review meetings and provided feedback to the Business Analysts. I have worked in different databases like Oracle and DB2, wrote SQL queries to retrieve data from the database. As far as different types of testing are concerned, I have performed Smoke Testing, Functional Testing, Backend Testing, Black Box Testing, Integration Testing, Regression Testing and UAT (User Acceptance Testing) Testing. I have participated in Load Testing and Stress Testing. I have written defects as they are found using Clear Quest and Test Director. Once the defects were fixed, retested them, and if the passed, closed them. If the defects not fixed, then I reopened them. I have also attended the defect assessment meetings as necessary. In the meantime, continuous interaction with developers was necessary. This is pretty much what I have been doing as a QA person.
How many Test cases can you execute at the time of doing Regression Testing?
Ans: It depends on how many test cases we have identified for doing regression testing, also depends on the timeframe within which we need to execute. If we are performing Unit Regression Testing on the application, then we are testing a particular feature in a form where that particular feature is not dependent upon the other features of the application. For example, If a help document has a defect and PDF file was not opening, then the tester will test only that defect why PDF file was not opening because it was not dependent upon the other part of the application again, if a developer did a mistake and type “Username” instead of typing “UserName” than the tester will test only the UserName function because it was not dependent upon the other parts of the application. In this case, I have to execute fewer test cases, i.e., 4-5 test cases per day are enough. Again, If we are performing Regional Regression Testing on the application, i.e., we are testing a particular feature in an application regionally where the features are dependent upon only some regions of that particular application, but not dependent upon the other regions of that particular application. For example, if the Compose feature has a defect and it was not working properly in Gmail Application, then it will cause an effect on the Inbox feature, Sent Item feature, Draft feature, Spam feature, and Trash feature only. As Username feature, Forgot Password feature, Help feature, and Settings feature are not dependent on the Compose feature. So, we can’t perform Regional Regression Testing on Username feature, Forgot Password feature, Help feature, and Settings feature. We will perform Regional Regression Testing only on Inbox feature, Sent Item feature, Draft feature, Spam feature, and Trash feature.
In this case, I have to execute a little bit number of test cases, i.e., 10-12 test cases per day are enough because at first, we have to identify the impacted regions. Then we perform Regional Regression Testing only on those regions. Again, If we are performing Full Regression Testing on the application, i.e., we go and test the whole application whenever the application changes or new features added. Here, we are re-executing the same test cases on different build and releases to ensure new features added or modification done has not introduced a defect in the older part of the application. For example, we have to perform Full Regression Testing on ICICI bank software because their entire business is dependent on that software. Again, if “wscript.exe” has any defect, then we have to perform Full Regression Testing on that because entire VB Scripting is dependent on “wscript.exe.” In this case, I have to execute the number of test cases, i.e., 15-20 test cases per day are enough.
How will you test the web application and client-server applications?
What type of testing will you follow when you are testing web application and client-server application?
Ans: To test the web application, for example, to test Internet Explorer, Google Chrome, Mozilla Firefox, Opera, we are testing these websites’ functionality on different browsers. So, we have to perform Compatibility Testing here. To test the client-server application, for example, to test Yahoo Messanger, Tata Photon 3G Dongle, we require a dedicated client to access the server-side. So, we are testing the data flow between two features or modules. So, we have to perform Integration Testing here.
What is Project Testing and Product Testing?
What is the difference between Project Testing and Product Testing?
Ans: Project testing defines that we are testing the developed software or application according to a specific client requirement or a customer requirement. In Project testing, we only test a part of the requirement document, which used in that particular project only. Product testing defines that we are testing the developed software or application according to the market demand or analysis(requirement) of multiple customers. Product testing, we test all the required documents used in the whole product.
How many types of defects have you found while testing the project in your current organization?
Ans: There are various ways in which we can classify. Below are some of the classifications:
(1) Severity Wise:
Major: A defect, which will cause observable product failure or departure from requirements.
Minor: A defect that will not cause a failure in the execution of the product.
Fatal: A defect that will cause the system to crash or close abruptly or affect other applications.
(2) Work product-wise:
SSD: A defect from System Study Document.
FSD: A defect from the Functional Specification Document.
ADS: A defect from Architectural Design Document.
DDS: A defect from the Detailed Design Document.
Source code: A defect from Source code.
Test Plan/Test Cases: A defect from Test Plan/Test Cases.
User Documentation: A defect from User manuals, Operating manuals.
(3) Error Wise:
Comments: Inadequate/incorrect/misleading or missing comments in the source code.
Computational Error: Improper computation of the formulae/improper business validations in code.
Data error: Incorrect data population/update in database.
Database Error: Error in the database schema/Design.
Missing Design: Design features/approach missed/not documented in the design document and hence, does not correspond to requirements.
Inadequate or sub-optimal Design: Design features/approach needs additional inputs for it to be complete Design features described does not provide the best approach (optimal approach) towards the solution required.
Incorrect Design: Wrong or inaccurate Design.
Ambiguous Design: The design feature/approach is not clear to the reviewer. It also includes the ambiguous use of words or unclear design features.
Boundary Conditions Neglected: Boundary conditions not addressed/incorrect.
Interface Error: Internal or external to application interfacing error, Incorrect handling of passing parameters, Incorrect alignment, incorrect/misplaced fields/objects, unfriendly window/screen positions.
Logic Error: Missing or Inadequate or irrelevant or ambiguous functionality in the source code.
Message Error: Inadequate/ incorrect/ misleading or missing error messages in the source code.
Navigation Error: Navigation not coded correctly in the source code.
Performance Error: An error related to the performance/optimality of the code.
Missing Requirements: Implicit/Explicit requirements are missed/not documented during requirement phase.
Inadequate Requirements: Requirement needs additional inputs for to be complete.
Incorrect Requirements: Wrong or inaccurate requirements.
Ambiguous Requirements: Requirement is not clear to the reviewer. It also includes the ambiguous use of words – e.g., Like, such as, maybe, could be, might, etc.
Sequencing/Timing Error: Error due to incorrect/missing consideration to timeouts and improper/missing sequencing in the source code.
Standards: Standards not followed like improper exception handling, use of E & D Formats, and project-related design/requirements/coding standards.
System Error: Hardware and Operating System-related error, Memory leak.
Test Plan/Cases Error: Inadequate/incorrect/ambiguous or duplicate or missing – Test Plan/ Test Cases & Test Scripts, Incorrect/Incomplete test setup.
Typographical Error: Spelling/Grammar mistakes in documents/source code.
Variable Declaration Error: Improper declaration/usage of variables, Type mismatch error in source code.
(4) Status Wise:
These are the major ways in which defects can be classified.
What is Test Release Document and Test Report Document?
Ans: Test Release Document is a document that covers all the testing related information like what are the features/module are tested and types of testing done on the product also what types of testing not done on the product, also what is the environment on which product is tested and all the release information related to that product.
Test Report Document is a document that covers no. of the pass, no. of fails, the percentage of pass and percentage of fail, etc.
What is the difference between Project and Product?
- If the developed software or application developed according to the client requirement or a specific customer, then it is called a “Project,” otherwise, if the software or application is developed according to the market demand or analysis(requirement) for multiple customers, then it is called a “Product.”
- The project contains requirements about the Product and the different phases which is required to develop the Product, while the Product will be the results of the Project.
- Multiple processes form Project & Projects produces various Products, i.e, Process ->Project ->Product.
Why should you use Bi-Directional Traceability in your current Project?
What is the difference between forwarding Traceability & Backward Traceability?
Ans: Bi-Directional Traceability contains both Forward & Backward Traceability.
(1) Forward Traceability, we can check that required documents are covered in which test cases? Or whether the required documents covered in the test cases or not?
Backward Traceability, we can see that test cases are mapped with which requirement document. This will help us in identifying if there are test cases that do not trace to any coverage item in which the test case is not required and should be removed (or maybe a specification like a requirement or two should add). This Backward Traceability is also very helpful if you want to identify that a particular test case is covering how many requirement documents.
(2) Forward Traceability Matrix ensures that we are Building the Right Product and Backward Traceability Matrix ensures that We the Building the Product Right.
What is the difference between Software Quality Assurance and Software Quality Control?
- Software Quality Assurance is used to identify the Standards and Guidelines; whereas, and Software Quality Control is used to implement the Standards and Guidelines.
- Software Quality Assurance is Process-Oriented; whereas, Software Quality Control is Product Oriented.
- Software Quality Assurance is used to Prevent Problems, whereas Software Quality Control is used to Delete Problems.
- Software Quality Assurance needs Continuous Improvement for Audits, i.e., it Checks for Conformance; whereas, Software Quality Control is the Final Checkpoint before delivery.
Challenges faced using selenium Automation Testing
Ans: Dealing with pop-up windows
- Testing dynamic text or content
- How to go about testing Flash
- Capturing screenshots, either to file or in some form of the report
- Iteration of the test case, running it repeatedly with some minor change
- Data-Driven Testing, using suites of pre-cooked data or generating it on the fly
- Generating useful test status reports
- Setting up Remote Control
- Setting up Grid
- handling Alerts Popups
- Switching between windows
- Working with frames.
- Field validation
- How to identify dynamic objects.
- Xpath and CSS locators for identifying elements.
- File Upload/Download Using : Java-AutoIT-Selenium
- Handling Multiple Popup Windows.
- Switching with multiple Windows
Suppose I have 5 @Tests and 3 Tests are independent, but the 4th test is dependent on the 3rd Test, and the 5th test is dependent on 3rd, but it should execute only after the 4th test. How to plan my execution for the above scenario in Testng.
Ans: Normal priority will work. Suppose TC 3, TC 4, and TC 5 will have priorities as 3,4,5, respectively. TC 4 and 5 both are dependent on TC 3. By priority, TC 3 will execute before TC 4 and 5. Since TC 4 has priority higher den TC 5 so TC 4 will be executed, they are followed by TC 5.
Searching Keywords: manual testing tutorial, automation testing interview questions, AUT in testing, manual testing, TCS software testing interview questions, what is software testing and its types, UI testing interview questions, automation testing interview questions, manual testing interview questions for freshers, manual testing interview questions and answers pdf, testing interview questions for experienced professionals with answers, manual testing interview questions and answers for experienced in Capgemini, scenario-based software testing interview questions and answers for experienced, manual testing interview questions and answers for freshers doc, practical testing interview questions