My Testing Thoughts

You can’t automate testing; you automate only the checks (tests)... Still baffled? Checks can be automated for sure but testing can NOT. When we interact with any application, we use our human brilliance to know the functionality of that application and then based on our intelligence we judge whether the behavior (use case) of that application is right or wrong — Can that judgment be automated? So far- Nope. Can we automate whether the behavior of that application is right or wrong on performing certain action/test? Yes.

Create generic methods like: public void  zoomIn() { zoomValue += z oomIncrement ; zoom(z oomValue ); } public void  zoomOut() { zoomValue -= z oomIncrement ; zoom(z oomValue ); } private static void  zoom( int level ) { JavascriptExecutor js = (JavascriptExecutor) driver ; js .executeScript( "document.body.style.zoom='" + level + "%'" ); } And then call ZoomIn() and ZoomOut() wherever you want. Complete sample code: import org.openqa.selenium.JavascriptExecutor; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; import org.testng.annotations.Test; import io.github.bonigarcia.wdm.WebDriverManager; public class zoomTest { public static WebDriver driver ; private int  z oomValue = 100; private int  z oomIncrement = 20; public void  zoomIn() { zoomValue += z oomIncrement ; zoom(z oomValue ); } pu...

Knowing or unknowingly we all introduce code smell in our test automation code and thus I feel that after every 3-4 sprints, there should be a dedicated sprint for Refactoring for our test automation code. It's a very important part of any software development and thus we should constantly review our code for bad design and try to chuck out any kind of code smell. Code Smells : Code smells and anti-patterns are usually not bugs and they do not currently prevent the program from functioning. In-fact, they indicate poor design and implementation in software that may be increasing the risk of failures in the future. And thus these are technical debt. Refactoring : Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure — Martin Fowler Here are the common causes of Code smells: 1) Comments If you feel like writing comments for all the classes and methods, first try...

False-Negative is a case where your test result comes out to be positive, but in actuality, an issue is present in the system and the functionality is not working as it should. And Vice-versa is False Positive, which is a case where the test execution results show an error, even though everything is working as intended. Fundamentally, both these have always posed a challenge for web automated testing but I guess it’s ok to say that a False-negative is more hurting than a False-Positive, as the former creates a false sense of security (a lie) and would definitely end up costing much more to us. I agree that a False-Positive too consume a lot of our's time and worth. On average 70% of automated test case failures are False-Positives due to which testers spend an average of 1/3rd of their time analyzing, correcting and reporting results that actually should NOT need any attention at all. In fact, with CI/CD implementation, running automated tests every night or after every commit ...

Read our article here: https://www.swtestacademy.com/design-sprint-in-agile/

The web browsers we should be supporting should be the ones that our client and customers are using. We can easily get that information: To start with, get the analytics for the most used browser on your application and use that browser as the first candidate for your manual as well as automation efforts. If there are no analytics available for the current application, look for the analytics of similar application and if you are still clueless, use the worldwide statistics*: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers Chrome: 48.7% Safari: 22.0% Firefox: 4.9% Samsung Internet: 2.7% UC: 0.3% Opera: 1.1% Edge: 1.9% IE: 3.9% *As of November 2019. We should select a subset of our tests that perform the functions that may break on different browsers and only run those many tests on all suggested browsers. It saves the total execution time of tests so that we can get your results faster and act quickly. For eCommerce sites, we need to be extra cautious. Look a...

What is Javadoc? Javadoc comment explains: - what the class does, its author, and version. - what the method does, its parameter, return value, and thrown exception. Many times, instead of our source code, we share our JAR with the other team members and once they import our JAR into their project and start using it, they either: - Don't see any Javadoc comments for the provided methods and they see this message on hover over- "Note: The Javadoc for this element could neither be found in the attached source nor the attached Javadoc." - OR, they see partial comments as they do see the method params numbers but not the type, etc. How to Fix this error? 1) Make sure that you have JavaDoc in place. To generate Java Doc in Eclipse: – Select the “Generate JavaDoc” option from the Project menu Specify the location for the JavaDoc file on your system Select the project and then the packages/class for which you want to create the JavaDoc file. Then click Next and th...