Writing automated tests is more than just a luxury for any agile software development team. It is a need, and is an essential tool to find bugs quickly during early phases of software development cycles. Although writing automated tests may seem like an easy task for engineers, there is still the possibility of ending up with poorly implemented tests, and the high cost of code maintenance in any agile process. ROI, Maintenance & Reusability is on the high priority in every Feasibility study of Automation. In this article, we will take a look at one such maintenance problem and how to overcome it using the much-famous Page Object Model. Nowadays, the page object model is a new Test automation buzz word being asked during Testing Job interviews as well.
Selenium Drag and Drop is one of the common scenarios in Automation testing. Let’s say we have a web application where we need to drag an item from one location to another location. These kinds of complex actions are not available in basic element properties. Thankfully Selenium WebDriver has Advanced User Interactions API (Actions class) to perform this kind of advanced user interactions for rich applications.
Agile software testing is the requirement of a modern software development team. Choosing agile testing tools is not an option anymore, it’s a necessity. If you want the end product to be effective, speedy and sustainable simultaneously, you must go with a tool which provides agile testing solutions under a feasible budget.
Tables are one of the primary design tools for HTML documents. Tables allow for greater control over page layout, allowing creation of more visually interesting pages. Table has rows and columns to store the data. I guess 50% IT industry will come to a halt if Microsoft Excel stops working 😉 that’s the importance of tables in organizing data. Search results on many websites are often displayed in the form of table. E.g. try searching for a flight between X and Y on a travel website, what you get is a table of results. There are times when we need to access elements (usually texts) that are within HTML tables. In this article let’s see how to read data from a Web Table using Selenium.
“How comfortable are you designing an Automation Framework from scratch?” – The very first interview question for a QA/Testing job opportunity now-a-days. What should I say? I am really good at Functional Testing? Nah! There is no space for manual testers. You HAVE TO start learning Automation. And it’s not just about Automation scripting, interviews are more driven towards programming & building an automation framework. So here I am penning down my answers to all those automation interviews in a series of Automation Framework focused blogs. It’s high time, really!
A peculiar but prominent distinction – Technical vs Domain Tester. Yeah! We know both are necessary for a successful QA career, but after certain years of experience your resume tend to incline towards one or the other. We are not Rajinikanth after all Who wins the Technical vs Domain Tester battle? Nah! It’s not a comparison between Deepanshu and Kanchan (we are together after all ;-)) but comparison between two different kinds of resume!
Recently a lot has been written & talked about the future of Manual Testing. Manual Testing is indispensable part of ensuring a high quality software. On the other hand, Automation Tests help you cut down the release cycle time. But usability & human behavior cannot be automated. With reduced time-to-market there is an added pressure on enterprises to seek automation alternatives. With the rise & growth of new technologies, people are more interested in scripting. But Manual Testing is the input to Automation scripts. Unless AI technology matches a human brain, Manual tests are best kept ‘manual’. You cannot automate everything. Cut the crap! Whatever be the debate but still Manual testers are finding it hard to stay relevant in today’s job market. Why?
I have a strong functional test experience but no automation. I ‘know’ automation testing but don’t have the project experience. I am a Test lead but didn’t write any automation scripts. Analytical & logical but never did project coding. Found in-numerous bugs but didn’t prepare automation reports. Managed a big team but didn’t learn performance testing. Documented every report but didn’t produce framework guides. Enjoyed exploratory tests but didn’t script pre-defined test cases. Helped BAs and even developers (in debugging) but never developed automation framework. Understood domain & application flows but didn’t write code. Open to learning but no opportunity. Self-learned programming & tools, but didn’t get practical project experience. Passionate about Software testing but now it’s Software Developer in Test.
Automation testing is a concept that is heavily marketed today. There has been a real convergence of tools and approaches in automation in recent years. It’s increasingly considered as integral to project delivery, rather than something that exists to cover business-as-usual regression testing after project completion. Faster releases, increased test coverage, frequent test execution, faster feedback to development team, just to name a few are being counted as some of the Test automation benefits. Automation is being portrayed as the silver-bullet in testing technology. But everything is not so ideal. Not every organization (or client) is reaping the actual benefits of Test automation. Certain Automation testing myths must be addressed in order to correctly apply it in the most effective & efficient manner. In this article we shall examine some of the most common automation testing myths and how these prevent organizations from succeeding in Test automation.
Different browsers render applications differently, so web applications need to be able to detect on which browser they are running and adjust their app code accordingly. Successfully testing all browsers and all versions are no small feat which is exactly why Sauce Labs built their solution on Selenium. To enable QA teams to execute Selenium based automation suites on multiple permutations, operating systems, and versions, for multiple browsers and browser versions.
At first glance, this seems like we’re done and this is the perfect solution to achieve complete application matrix coverage. Unfortunately, nothing is that simple, and upon digging deeper, it is apparent that not all environments are available for certification. You will have some critical use case gaps, there’s no way around it. So what are they and how do you get around them?
If you are somewhat familiar with Selenium automation, you would know the importance of XPath. For those who are just starting with Selenium – XPath is one of the most popular element locator technique in Selenium along with CSS selector, i.e. mastering XPath or CSS is essential for the Selenium test automation. Yeah! You can extract the XPaths from Firepath-like tools but these cannot be used directly for dynamic web elements. And we think getting the basics is a must >> Tools can be used afterwards. This article is an introduction to XPath along with some XPath examples.
Web page uses HTML Document Object Model. XPath is used to navigate & locate elements in an XML. So how are XPath examples relevant for a web page?