39 What is IWebDriver and IWebElement? IWebElement is a selenium class that represents an HTML element (body, table, tr, etc.) on a page in your selenium automation code. With the IWebElement instance, you can interact with an element and retrieve its attributes and properties. Some of the methods of this interface are: Click: Clicks this element. GetAttribute: Gets the value of the specified attribute for this element. FindElement: Finds the first IWebElement using the given method. (Inherited from IsearchContext.) SendKeys: Simulates typing text into the element. Clear: Clears the content of this element. Submit: Submits this element to the webserver. The IWebDriver interface is the main interface for testing, representing an idealized web browser. The methods in this class fall into three categories: Control of the browser itself Selection of IWebElements Debugging aids Some of the methods of this interface are: FindElement: Finds the first IWebElement using the given method. Close
Posts
38 How do you choose which test case to automate? A test case should be automated if: The task is going to be repeated. It’s going to save time. The requirements, the test, or the task are low risk, stable, and unlikely to change often. The test is subject to human error. The test is time-consuming. The test has significant downtime between steps. The test is repetitive.
37 When do you automate a test case? Automatic testing is required when you want to run the same test cases across multiple machines at the same time. Automation testing is also a good way to avoid human error in your testing. With automation, you can be sure that all tests are exactly the same, with humans you are allowing your simple error.”
34 What are the different ceremonies in an agile team? The agile ceremonies list includes: Sprint Planning Daily Stand-Up Sprint Review Sprint Retrospective 1. Sprint Planning The Sprint Planning ceremony sets teams up for success by ensuring everyone understands the sprint goals and how to achieve them. Structure Attendees Timing Duration Agile Framework The Product Owner brings the product backlog to discuss with the Development Team. The Scrum Master facilitates. Together, the Scrum Team does effort or storey point estimations. The product backlog must contain all the details necessary for estimation. The Product Owner should be able to clarify any doubts regarding the product backlog. 2. Daily Stand-Up The daily stand-up brings the team together and sets everyone up for the day. The team uses this time to identify blockers and share plans for the day. Structure Attendees Timing Duration Agile framework This is an informal, standing meeting. All members of the Development Team i
33 What are the different roles in an agile team? The common agile roles are: Team lead. This role, called "Scrum Master" in Scrum or team coach or project lead in other methods, is responsible for facilitating the team, obtaining resources for it, and protecting it from problems. ... Team member. ... Product owner. ... Stakeholder.
31 What are the drawbacks of the waterfall software development model? Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought-out in the concept stage. No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects. Not suitable for projects where requirements are at a moderate to high risk of changing.
29 What are the benefits for a team in following DevOps practices? Some benefits of DevOps include: Faster, better product delivery Faster issue resolution and reduced complexity Greater scalability and availability More stable operating environments Better resource utilization Greater automation Greater visibility into system outcomes Greater innovation
28 What are CI, CD, and CT? CI ( continuous integration) allows developers to write, update, or fix a feature, then commit a code to the central code repository reliably, multiple times a day. CD ( Continuous delivery) is the implementation of automating the entire software release process. Once code has passed all of the tests, deployment becomes the last step in the process. In a DevOps pipeline, CD often is referred to as continuous delivery but can also mean continuous deployment. CT ( Continuous testing) is a software development process in which applications are tested continuously throughout the entire software development life cycle (SDLC). The goal of CT is to evaluate software quality across the SDLC, providing critical feedback earlier and enabling higher-quality and faster deliveries.
25 What is compatibility testing and how they are performed? Compatibility Testing is a type of Software testing to check whether your software is capable of running on different hardware, operating systems, applications, network environments or Mobile devices. Compatibility Testing is a type of Non-functional testing. How To Perform Compatibility Testing Compatibility Testing can be long and tedious as it involves several platforms and devices. We can divide the whole process into four steps for making it quick and efficient. Steps: Design and Configure Test Cases. Environment Set-up Execution. Validation and Retesting. Industry connect
24 What is User Acceptance Testing and who does UAT? User Acceptance Testing (UAT) , also known as beta or end-user testing, is defined as testing the software by the user or client to determine whether it can be accepted or not. This is the final testing performed once the functional, system and regression testing are completed. Users or Clients – This could be either someone who is buying a product (in the case of commercial software) or someone who has had a software custom-built through a software service provider or the end-user if the software is made available to them ahead of the time and when their feedback is sought out. The team can be comprised of beta testers or the customer should select UAT members internally from every group of the organization so that each and every user role can be tested accordingly. Industry connect
23 What are the different types of non-functional testing Performance Testing Load Testing Failover Testing Compatibility Testing Usability Testing Stress Testing Maintainability Testing Scalability Testing Volume Testing Security Testing Disaster Recovery Testing Compliance Testing Portability Testing Efficiency Testing Reliability Testing Baseline Testing Endurance Testing Documentation Testing Recovery Testing Internationalization Testing Localization Testing Industry connect
22 Explain API testing with an example API testing is a type of software testing that analyzes an application program interface (API) to verify it fulfils its expected functionality, security, performance and reliability. The tests are performed either directly on the API or as part of integration testing . An API is middleware code that enables two software programs to communicate with each other. The code also specifies the way an application requests services from the operating system (OS) or other applications. Example: Travel booking systems: For instance, take Kayak the biggest online site for booking tickets. You enter your destination, once you select dates and click on search, what you get back are the results from different airlines. How is Kayak communicating with all these airlines? There must be some ways that these airlines are actually exposing some level of information to Kayak. That’s all the talking, it’s through API’s.
21 Difference between the Black box and White box testing Black box testing: Black box testing is the software testing method that is used to test the software without knowing the internal structure of the code or program. This type of testing is carried out by testers. Implementation Knowledge is not required to carry out Black Box Testing. Programming Knowledge is not required to carry out Black Box Testing. Testing is applicable on higher levels of testing like System Testing, Acceptance testing. Black box testing means functional test or external testing. concentrated. In Black Box testing is primarily concentrated on the functionality of the system under test. The main aim of this testing is concentrated to check on what functionality is performing by the system under test. Black Box testing can be started based on Requirement Specifications documents. Functional testing, Behavior testing, and Close box testing is carried out under Black Box testing, so there is no requirement
20 Difference between Alpha and Beta test Alpha testing: Alpha testing involves both the white box and black box testing. Alpha testing is performed by testers who are usually internal employees of the organization. Alpha testing is performed at the developer’s site. Reliability and security testing are not checked in alpha testing Alpha testing ensures the quality of the product before forwarding it to beta testing. Alpha testing requires a testing environment or a lab. Alpha testing may require a long execution cycle. Developers can immediately address the critical issues or fixes in alpha testing. Beta testing: Beta testing commonly uses black-box testing Beta testing is performed by clients who are not part of the organization. Beta testing is performed on the end-user of the product. Reliability, security and robustness are checked during beta testing. Beta testing also concentrates on the quality of the product but collects users' input on the product and ensures that the pr
19 Difference between regression, sanity and smoke tests Smoke Testing Sanity Testing Regression Testing Performed on initial builds Performed on stable builds Performed on stable builds To test the stability of new build To test the stability of new functionality or code changes in the existing build To test the functionality of all affected areas after new functionality/code changes in the existing build Covers end to end basic functionalities Covers certain modules, in which code changes have been made Covers detailed testing targeting all the affected areas after new functionalities are added Executed by testers & sometimes also by developers Executed by testers Executed by testers, mostly via automation A part of basic testing A part of regression testing Regression Testing is a super set of Smoke and Sanity Testing Done usually every time there is a new build Planned when there is not enough time for in-depth testing Usually performed, when testers have enough time Industry
18 Difference between system, integration and E2E tests System testing is performed to check the following points: To check whether the software system is made according to the customer needs to be written in Software Requirements Specifications, it meets both functional and non-functional design requirements of the system. When all the modules are combined as a whole, many errors and facts may arise which may not give the expected results? So system testing is performed to find the defects or bugs in all the interfaces as well the whole system. To execute the real-life scenarios on the software. It is done on the staging server which is very much similar to the production server where the software would actually be deployed. The system test cases are made according to the end–to–end-use perspective. Integration testing is performed to check the following points: To check whether the modules developed by individual developers when combined are according to standards and give the exp
17 What is the difference between a test scenario and a test case? A test case is a set of conditions for evaluating a particular feature of a software product. Basically, test cases help in determining the compliance of an application with its business requirements. A test scenario is generally a one-line statement describing a feature of the application to be tested. It is used for end-to-end testing of a feature. Usually, it is derived from the use cases. Test Case vs Test Scenario Test Case Test Scenario A test case contains clearly defined test steps for testing a feature of an application. A test scenario contains high-level documentation, describing an end to end functionality to be tested. Test cases focus on “what to test” and “how to test”. Test scenarios just focus on “what to test”. These have clearly defined steps, pre-requisites, expected results etc. Hence, there is no ambiguity. Test scenarios are generally one-liners. Hence, there is always the possibility of a