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…
Functional Testing
QA Team starts Testing a Software and there are “way too many” Defects!
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?
Interview all Automation | Job all Manual?
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.
Testing Situation | How do you handle Timeline crunch?
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?
Interviewer: What will you do if a Defect is not reproducible?
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?
How will you Start Testing without any Functional Specification?
One of the most common situation, how will you start Testing without any functional requirement specification or any related documents? No wonder there are sometimes these kind of situations, ex. Resource attrition, no-documentation-with-agile-projects, etc. The only hope in these situations is ‘Exploratory Testing’. Since there are no documents to refer, refer the application directly 😉 Explore it, Test it. Gradually the flows make sense and we actually start testing it. Other option is to sit with Business analysts and developers to get application understanding – listening to experts instead of reading a document.
AI + ML + Automation + Script-less Testing Technology! What about the Defects?
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.
What Agile metrics do you capture? Any idea about Velocity?
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.
Why do you love Software Testing?
Recently in an interview I was asked ‘Why do you love Testing?’ This got me thinking…How will you feel if you bought a new smartphone at a high price only to find a fault when used? Frustrated. Disappointed. Cheated. Angry. Sad? Yeah! A tester’s job is to prevent you feeling all those negative aura 🙂 What is your reason to pursue Testing as a career?
Automation is Confirmatory, Manual Testing is more Exploratory?
Automation is mostly employed for regression, i.e. to gauge the impact of changes on ‘already-working’ functionality. The same Manual test cases are automated and executed. Automation is for confirmation. What if you want to find issues/defects? Yeah! Manual testing is the first approach. After all, end-user is not a scripted machine. Simulating end-user behavior, testers explore the application with some alternate flows & on-the-fly data.
How come you find Defects, every time?
How come you are able to find defects in already-tested flows? As an end-user there are numerous possibilities of inputting invalid data and then expecting correct behavior.
No idea about Software Testing Basics? Get an Idea before your next Interview!
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.
Kualitee – A Defect Tracking Tool You Were Looking For
Defect tracking is a testing-critical strategy that QA engineers utilize to understand the loopholes in the product’s quality and what further improvements it requires to reach the desired results. Software testing has to be intuitive and vast, and thus it has to be logical and yields measureable results. That’s the reason why the success of SDLC greatly depends on accurate bug tracking. In this domain, a fine defect tracking tool is crucial in software testing activities to streamline bug reporting, while accelerating delivery silos.
How to handle ‘way too many’ Defects | Poor Build Quality
Recently one of my LinkedIn discussion gained much traction. Although I don’t know the reason – may be it was uncommon OR way too common among testing enthusiasts. The post got reactions from the who-and-who of the QA world – ranging from Testers to Managers up to VP Products. So thought of sharing the insights to a larger audience via a blog post. In this article, we will look at the options available to a QA team if there are ‘way too many’ defects in the application. Here we go…