There is no such statement as ‘I am now prepared for the interview‘. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read Continuing on our Interview questions series, let’s see some more interesting FAQs related to Domain, Software requirements, Agile Kanban, Career in Testing, SMAC Testing, Automation and Selenium Webdriver.
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?
Most of the QA professionals are among the smartest people on this earth who often boast advanced degrees in engineering, mathematics or computer science. In some ways, we are like Superheroes – capable of breaking down a whole application and defeating an army of programmers with our defects, testing complex functions, juggling numerous technologies, ensuring customer ideas morphed into working software, all the while not breaking a sweat. So how is it that despite such technical savvy, programming prowess and quality driven attitude, we are defeated at test estimation front?
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.
The goal of every IT organization is to deliver a quality software to their clientele, and to complement their goal they give the highest priority to Software Testing. Automation testing acts as an accelerator to their time to market by saving time and effort, and manual testing will remain as the core for quality software delivery. In today’s changing technology landscape, Manual testers are being pushed to learn automation skills. But how? How to empower Manual Testers to do Automation Testing?
Though the aspiration for being a successful IT professional is strong, we assume that the word ‘IT professional’ is synonymous with ‘Developer’. When a testing opportunity presents itself, there are many doubts in our minds and we often wonder if it’s the right career move or not. While being a developer is great and has immense potential, it should not be concluded that being a tester means the exact opposite. Let’s explore the reasons behind the perception – Software Testing is inferior to Development,
In an agile business, automation is becoming an essential process. Companies are now taking advantage of automation testing tools to increase their efficiency and productivity. Automation is frequently evangelized as the cure-all of software quality woes. Some of the benefits that accrue from automated tests include test reusability, repeatability and coverage besides the savings on effort, time and cost it takes for execution (compared to manual testing). However it’s NOT the answer for everything. Test automation, while being able to improve numerous aspects of software development, has limitations that developers and quality assurance teams should be aware of from the start. Understanding these limitations of automation testing will help us devise an efficient & effective automation strategy.
Quality – Why is this word so important for your software? Software teams today involve a number of people: developers, testers, support engineers, designers, product managers, and executive stake holders. A low quality software impacts all of these or in other words everyone in the team is responsible for the quality of software delivered. When we look into the overall effectiveness or cost manual testing still have a pivotal role to play. Unfortunately, very little discussion is only happening on how to improve efficiency of manual testing instead most of discussions are happening on how to increase the level of automation. Many of us would advocate the fact that Manual Testing is no longer needed, and I know it well why they think so. It is mostly because of the drawbacks and challenges associated with Manual Testing.
While scripting you might encounter a scenario which requires the automation script to download a file with Selenium Webdriver (say MS Excel, MS Word, Zip file, PDF, CSV, Text file) from web application. What happens when you click on ‘Download’? Yeah! A pop-up window is displayed asking user to either open, save or ‘save as’ the file. If you have noticed, this is NOT a browser HTML pop-up but Windows OS pop-up. And Selenium Webdriver is a ‘Web Browser’ automation tool, i.e. it works only in the browser. We cannot access operating system’s native windows with Selenium Webdriver. Ooops! A blocker! Does this mean we cannot automate the File download scenario? Nah! It simply means we need to find a workaround 😉 In this article let’s explore how to download a file with Selenium Webdriver using Firefox Profile.
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.
There is no such statement as ‘I am now prepared for the interview‘. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read 🙂 Continuing on our Testing Interview questions series, let’s see some more interesting FAQs…
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?
Static, as in Stationary or Stagnant. What do you think is stationary in software terms? Yeah! The code. Either it can be stationary – or running, i.e. when you run the code. As the name suggests Static Code Testing is one of the software testing technique where the code is stationary, i.e. NOT running. How? Simple, you don’t execute any functionality (or code). Then how does it ‘test’ the system, you may ask 🙂 In Static Code Testing we don’t execute the code, instead it is checked manually or via tools for any design defects. As you might have guessed – Static Testing is not just limited to the code, we can even analyse the associated documentation like requirement & design documents to identify any potential errors or standard violations. Static testing is also known as Dry run testing.
There is no such statement as ‘I am now prepared for the interview‘. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read 🙂 Continuing on our Interview questions series, let’s see some more interesting FAQs…
Software Testing Levels, Test Data, Waterfall methodology, Agile Scrum, HTML Elements, Selenium Automation, WebDriver, Test Data Management, Scrum methodology