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?
Ideally every team should maintain a bell curve. That being said, this was a recent discussion I had with one of the seniors. ‘Freshers are lenient, reckless & lack professionalism/experience’ he said. But that is the whole point. Everyone was a fresher once. Freshers are enthusiastic to embark on their professional journey, are not bounded by professional processes, can think out-of-the-box. Just that they need proper guidance, relevant training & due diligence.
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?
A strong manager backing the team is the foundation to a successful team. A team succeeds when you entrust them to deliver & have full confidence in their caliber. It’s like a family, no one should point at your team for weakness 😉 at the same time internally you might need to introspect & keep improving. What say?
Some say serving notice is just like your ‘honeymoon period’. Is it because you are leaving the firm and no more accountable? Or why put efforts for something you know is soon going to end? Coming late – Going early becomes normal? Why?
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.
Why are some developers not aware of the functional flows? It’s like I am coding this module, why should I know the complete flow. My module is working fine. But you have to have a complete understanding of the system. Isn’t it? It works like that in every sphere – look at the bigger picture. Where do you fit, or where does your code/module fit in the overall flow. System architecture and System’s User perspective go hand-in-hand. Everyone in a project should have a clear understanding of these two aspects.
Cut the crap! Whatever be the debate but still Manual testers are finding it hard to stay relevant in today’s job market. Why? A simple argument – ‘Manual Testing’ & ‘Manual Testers’ are two separate entities. Agree that ‘Manual Testing is NOT dead’, and it never will. But what about Manual Testers?
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.
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.
FinTech, a buzzword today. Though it has been around from the start of 21st century, recently it has gained unprecedented momentum. Why? Due to the emerging disruptive technologies. But what exactly is FinTech? And how it should be perceived as a Tester? What’s the role of a FinTech Tester? What’s the scope of FinTech Testing? These are some of the doubts testers working in the Finance domain come across daily. This article tries to answer these questions in simple terms. The Finance. The Technology. What’s FinTech? The role of a FinTech QA. And its scope. Let’s deep dive…