Test Automation Basics

I have just finished jotting down all the  Anti-Patterns  that I have come across during my assignments and  Best Practices  that I have adopted to make my tests run on cloud and with distinguishing quality. And if I talk about all of them,  I honestly don't know how long this article is going to be.   Therefore just like the title, I will, in this article, discuss habits that keep you away from keeping code hygiene and make your automation starve for love and respect.  So lets' start without any further ado. Borrowing Existing Frameworks Well, it's not hidden from anyone. We have heard this before from someone that they have got a fantastic Test Automation framework  for our new project  from another team. With such suggestions, it's easy to convince the team because we crave for being efficient, and it points to the definite time-saving scheme. Let me assure you, its a trap. It not only takes time for the team to understand the complete architectur

It does not matter if we have an experienced Testing team, or exceptional automation technology for testing the product, writing a little code to exercise a system is not a big deal. Although it's essential to consider writing Test Automation with robust test design, in the absence of which, organisations can encounter a plethora of complications that compound to create inefficient, sketchy, and hard-to-maintain tests.  To ensure quality, cost efficiency, and speed, it becomes crucial to identify the symptoms that your tests aren't offering optimally. Below are few "anti-patterns," or unreliable exercises I have withdrawn in my projects for the best testing experience. No Framework Design We make strategies to win and counter failures. But in the case of test automation, often, the design takes a backseat in the event of automating. And all the glittery things catches eyeballs for showcasing something not going to be worth after a while. Lack of thinking