The complexity of Software systems and the demand of customers and users are increasing every day. It has become evident that testing must be treated as a disciplined and controlled process. Test professionals must learn precise techniques and methods by which they can deliver software with a much higher degree of confidence. Individuals who are charged with the responsibility of testing computer systems must receive formal education, i.e. Testing Certifications. Testing certifications are in great demand! It is assumed that you already have one of them or at least you are planning/preparing to have one of them soon. Being a Software Tester, is it mandatory to have an ISTQB Certification?
Testing terminologies can sometimes confuse even the most experienced of IT professionals. If you were asked to write a test case, you would know what to do. What about a Test scenario? Or a Test condition? The first step is learning what different Testing terminologies actually mean. To a layman Test conditions, Test Scenarios, Test cases and Test suite might seem similar but there is a subtle difference between these terms which make a world of difference for a Software tester. Each of these implies a different level of detail and is used for a different purpose. Once a tester knows what each of these terms mean, they can figure out how to use them to describe the testing work that is done on a daily basis.
Industry is sure moving to Automated Test execution. But as I say – Automation is confirmatory, Manual tests are more exploratory. Only Automation testing is not enough, so testers need to be good at finding bugs. “Finding Bugs” is one characteristic that differentiates a good tester from a mediocre tester. The basic principle is to combine things that programmers didn’t expect with common failure modes of your platform. Always remember, Testers don’t break the software. It is already broken. You just need to find those broken pieces and help make the software better.
Any technology or tool is worthless unless it is being used by ‘some’ organization somewhere. It all starts from organizations adopting the new technology or a tool and then it gets popular slowly. In that sense QA Job Descriptions are a great source of current technology, i.e. practical tech. being used by IT organizations. Be it Selenium, Protractor, Appium, API tools, Big Data Testing, etc. Everything is embedded in the QA Job descriptions, you just need to mine some data 😉 But don’t worry. Software Testing Studio has started a new series for you – “JD Talks” where we mine hundreds of Job descriptions to come up with latest tools, technology, languages and concepts. Let’s see what the first set of JDs talk about…
In continuation to our previous article introducing ‘Maven Build Tool’, this article describes some of the most common terms encountered while using Maven. These terms, that have an explicit meaning for Maven, can sometimes be confusing for newcomers. As an Automation QA, you should at least be aware of the below 20+ Maven terminologies – commonly asked in a technical interview 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.
Exploratory testing, is all about discovery, investigation and learning. It’s like Machine learning, in concept. It empathizes on learning and adaptability. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run. It emphasizes on personal freedom and responsibility of the individual tester. Exploratory testing is done without any specific plans and schedules. Test cases are not created in advance but testers check system on the fly. They may note down ideas about what to test before test execution. The focus of exploratory testing is more on testing as a “thinking” activity.
Interview is the most important part of the employment process. It can make or break an opportunity. When it comes to Software Testing, almost all organizations are now looking for Automation engineers, SDETs, Selenium experts, Automation architects and what not. Since Manual testers are finding it tough to land a high-paying job switch, many have started learning the basics of Selenium automation (Yeah! Selenium is one of the most popular automation tool now-a-days). But interviewers demand practical experience. And interview questions reflect that view – starting from basic theoretical knowledge, slowly the interview will move towards – Explain Test Automation framework for your current project.
This is one of the most common questions discussed among the Agile Community – What happens with the undone User Story of Current Sprint? Why does this happen? How should you deal with the undone user story? What should become of such stories? What should be done with the product backlog item itself? Should be it split or should it be carried into the next sprint? Should the team receive any velocity “credit” for completing a portion of the story? And how do you prevent it from happening again? This article addresses all of these questions.
There are lot of people who have Manual testing experience. When there is a walk-in interview you could see thousands of people with more experience than you have. So you have to differentiate yourself from others by adding extra skills to your resume. In a world where the consumer expects fast-paced delivery, and solutions must support a myriad of devices and platforms, manual testing simply doesn’t enable the delivery pace that the market expects. The rise of automated testing in response to this has been rapid. Are you attempting a switch from Manual Testing to Test Automation? This transition won’t come overnight. It takes months/years to lay the groundwork.
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.
While writing this article, I am worried & concerned. Not about this article, nah! But about the future of Software Testing and Software Testers in particular. Recently during an interview drive, I came across a bunch of (yes, maximum of them) so-called Software testers who don’t even know the basics of Software Testing. Leave alone the required practical experience. It felt sad that testers don’t even know the basic QA terminologies, didn’t understand its importance, take it too lightly as a career, are not willing to learn, etc. At one end industry is moving towards Automated QA and on the other hand here we are with a bunch of novice testers for whom even the foundations are shaky.
Knowledge about fundamental Testing concepts is necessary to crack an interview. But now-a-days only knowledge is not enough. Interviews are not just about the theory anymore. Every interviewer is looking for candidates who have practical exposure to different kind of situations and is able to handle them effectively. Most of the companies will have it as one of their selection criteria. And yes, it doesn’t depend on the technology. For every technology there will be situations that an experienced professional knows how to tackle. In this article, we will look at some of the situational FAQ commonly asked in a testing interview. But we will need your help here. It is just a beginning, please comment any situational question that you might have faced in a recent or any past interview. This would help us to collate an informative list for the Testing community.
Definition of done is one of the Agile fundamental things. Yet many teams do not see its importance or are unsure what Definition of Done actually is. The term is also often confused with the acceptance criteria, leading to mis-communications and false expectations. So, let’s have a look at this important agile concept – the definition of done.