Posted in Selenium

What is the difference between Implicit wait and Explicit wait in Selenium WebDriver?

Implicit wait()  is used to inform WebDriver that there could be cases When a page is loaded by the browser, the elements which we want to interact with may not load instantaneously. In those cases WebDriver has to continuously listen to DOM for a given amount of time until either the time expires or the element is found.

In implicit wait, we will actually define a wait time globally, so it is applied to all the elements in the script. Below Implicit Wait() says driver that hey wait for N number of seconds before you throw an error or exception.

 driver.manage().timeouts().implicitlyWait(N, TimeUnit.SECONDS); 

Explicit Wait(): Explicit Wait will make your code to wait for certain condition to occur before moving forward.

Explicit Wait() is 2 types

  1. WebDriverWait :It is used to tell the Web Driver to wait for certain conditions (Expected Conditions) or the maximum timeout. 
 WebDriverWait wait = new WebDriverWait(driver, TimeOut);  
wait.until(ExpectedConditions.visiblityOfElementLocated(locator)); 

The following are the suggestions if you type ExpectedConditions.

  1. alertIsPresent()
  2. elementSelectionStateToBe()
  3. elementToBeClickable()
  4. elementToBeSelected()
  5. frameToBeAvaliableAndSwitchToIt()
  6. invisibilityOfTheElementLocated()
  7. invisibilityOfElementWithText()
  8. presenceOfAllElementsLocatedBy()
  9. presenceOfElementLocated()
  10. textToBePresentInElement()
  11. textToBePresentInElementLocated()
  12. textToBePresentInElementValue()
  13. titleIs()
  14. titleContains()
  15. visibilityOf()
  16. visibilityOfAllElements()
  17. visibilityOfAllElementsLocatedBy()
  18. visibilityOfElementLocated

2. Fluent Wait : fluent wait is used to tell the web driver to wait for a condition, as well as the frequency or poll with which your WebDriver monitors or listens to DOM.

Frequency or poll : Setting up a repeat cycle with the time frame to verify/check the condition at the regular interval of time

Wait wait = new FluentWait(driver)    
    .withTimeout(30, SECONDS)    
    .pollingEvery(5, SECONDS)   
    .ignoring(NoSuchElementException.class);

Ex: fluentwait 10 sec, polling 2 sec means every 2 sec it checks DOM for the element

Conclusion: Explicit Waits are smarter than Implicit Waits because they don’t wait for the max time out.  Instead it waits for the time till the condition becomes true.

Posted in Selenium

What is Serverless Architecture ? it’s Advantages?

 Serverless Architectures are internet-based systems where the application development does not use the usual server process. Instead, they rely solely on a combination of third-party services, client-side logic. Applications are broken up into individual functions that can be invoked and scaled individually.

Advantage of Serveless Architecture:

  1. Pricing: for years the cost of provisioning servers and maintaining that 24×7 server team which blew a hole in your pocket is gone. 
  2. It is beneficial for simple applications with few dependencies
  3.  Environments: Setting up different environments for Serverless is as easy as setting up a single environment
Posted in Manual Testing

What is defect triaging?

Defect Triaging is a formal meeting where all the defects of the current Sprint are discussed and triaged i.e. Prioritized based on its severity, frequency, risk, etc.

The defect triage meeting discuss about if defect is valid or user error. If the defect is considered as valid defect then the next question will be is this defect reproducible? If it is inconsistent then that will be assigned for thorough analysis.  If bug is reproducible then comes next question is this defect worth of a fix? i.e., how much it impacts the business of the client. If the impact is low then it will be deferred to next releases or bug can be closed. If the impact is high then that will planned for the immediate releases and assigns to the developer to provide fix with defect status as “Assigned”

Posted in Manual Testing

How do you analyze the root cause of a defect?

Root cause analysis is used in software testing to identify defects. That means you can find the cause of software defects before your customers find bugs. 

You’ll usually find three basic types of causes Physical, Human, Organizational. The Root Cause Analysis Process has 5 steps

1.       Define the Problem

  • What do you see happening?
    • What are the specific symptoms?

2.       Collect Data

  •  What proof do you have that the problem exists?
    • How long has the problem existed?
    • What is the impact of the problem?

3.       Identify Possible Causal Factors

  • What sequence of events leads to the problem?
  • What conditions allow the problem to occur?
  • What other problems surround the occurrence of the central problem?

4.       Identify the Root Cause(s) – During this stage, identify as many causal factors as possible

  • Why does the causal factor exist?
    • What is the real reason the problem occurred?

5.       Recommend and Implement Solutions

  • What can you do to prevent the problem from happening again?
    • How will the solution be implemented?
    • Who will be responsible for it?
    • What are the risks of implementing the solution?
Posted in Manual Testing

What is a change request and how does a change request get handled?

If your company is using Trello for project management

  1. Try creating Change Request Flow(plan, protocol). Agree with the client on the steps which are going to happen each time they request a new change. E.g. if they request a new feature, the feature will be included into the next iteration/sprint.
  2. Try to systematise their requests. If they want to add a new button to the existing page, create it as a separate card, not as a comment. If they ask for numerous copy updates, put down these requests to a separate “Copy updates” card.
Posted in Manual Testing

When does a defect gets rejected by the developer?

The mains reasons for bug rejection are

Non-reproducible bugsdefect has not reproduced on developer pc, i.e a defect coming on your pc does not happen in developer pc’s

Test environment – mismatch of browsers, devices, or configuration of your application with developer.

Duplicate bug – Someone else has already reported the same bug 

Misunderstanding the requirements – For any reason, if you did not understand the requirement properly, you would definitely look out for the misinterpreted requirement in actual implementation and when you would not find it, it would be a bug according to you, which will finally get rejected

Change in requirement – When testers are not communicated about requirement changes, more bugs will be reported and ultimately rejected.

Test data used – Test data used for testing was mismatching with a requirement

Improper bug description – If developer does not find proper description and required details in bug report, no matter how critical the bug is, it is expected to be marked as Rejected.