Recently I am getting messages with the core problem ‘Getting stuck in my Career’. No Interview calls. Only Automation. Tool-focused interviews. No practical tool experience. Especially from the 5-8+ experience bracket. Yeah! I know, continuous rejection is frustrating. I have been there. But nothing can be done about it. Accept the fact that industry has transitioned faster than your skills. We are awesome Functional testers. Superb Agile professionals. Good Domain knowledge. Effective Team managers. But…
The QA team starts testing a software/product and there are “way too many” defects. Every other scenario is failing, new flows are explored & clarifications sought. What would be the strategy now?
Automation is everywhere. Automation experts are in high demand. Nah! Not in high demand, ONLY Automation Engineers are in demand. All job descriptions mention a set of automation tools and frameworks. Interviews revolve around Java, Python, C#, Selenium, UFT, Appium, Frameworks, Algorithms, and what not. Literally ‘Everybody’ is looking for an Automation engineer.
I assume ‘every’ fellow Tester in my network have experienced this situation at least once in his/her career. One of the most common Testing situation – How do you handle timeline crunch? Since Testing is the last step before client demo, the Test team has to make-up for the delays encountered till the build is deployed in Test environment. Now how do you handle crunch timelines without impacting the quality?
Many a times we face these kind of one-off bugs 🙁 which peep-out and then hide somewhere. “It was a one-off bug and now not reproducible – so what can I do?” Wrong! Though one-off but still it is present somewhere in the software and as a Tester it is our responsibility to investigate it. How?
Adopting technology is important, but blind adoption is different than logical application of Technology. When I see it – looks like everyone wants to fit the tech-term anywhere in the test process and call it tech-driven QA. But how do you measure the ROI from client perspective? Do you compare Super-Tech.QA vs. Functional QA? Or Super-tech-tools are cheaper than the required man power? Nah! Everyone says “All these are long-term benefits, no short-term advantage”, but then eventually forget to measure the ROI in the long run as well 😛 On the other hand, due to all this fuss we have somewhere neglected the original Tester.
Agile Velocity is an extremely simple method for measuring the rate at which scrum teams consistently deliver business value. In other words – How much product backlog effort a team can handle in one sprint? It’s the rate at which a team delivers stories from the product backlog, i.e. sum of estimates of delivered (i.e., accepted) features per iteration. It can be measured in story points, days, ideal days, or hours that the Scrum team delivers – all of which are considered acceptable.
I agree situational interviews are the way-to-go, but some theoretical clarifications won’t do any harm. Every tester needs to know the basics at least. It’s essential to be prepared for a time-boxed interview. Get some basic facts clear before facing the next interview, to avoid embarrassment.
“How do you connect to a Database?” the interviewer asked. That was simple, right. Using a Database connection string I said. But what do you pass in connection string and how does it works at the backend? Oh Oh! They need the details. As a tester, most of the testing is centered on web applications (i.e. browser) and now-a-days mobile apps. But as with API testing, Database testing & SQL is growing in demand. Database knowledge is something every tester is expected to know about. So with this article we try to explain how to connect to a database, in detail.
Exploratory Testing has gained popularity in past few years. There are several studies and has also received much of professional attention from the industry. Exploratory Testing gives power to the tester together with responsibility; it offers great freedom and opportunity to the tester for exploring and identifying areas for improvement. But why do we need exploratory testing if we’re already doing a good level of scripted testing? We’re writing test scenarios in each story, running them on different builds until they all pass, and we’re also running them in regression to make doubly sure that the product is still working. Sound good and thorough – what’s the point in doing more software testing on top of that? Well, there are a few good reasons to do exploratory testing in addition to the regular, scripted testing. It exposes the underlying issues within your product, app or website and allows testers to literally explore the functionality.
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.
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.