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.
Start-ups give you an opportunity to learn a lot. You need to wear multiple hats. Work in & out. But it pays in the long run. Established MNCs give you a stable job with matured policies. Which one do you prefer if given a chance?
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?
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?
Yeah! Today I am resigning from my current organization. Often asked about ‘Why are you leaving your current Organization?’ – I feel there is no single reason. Leaving a company which has been your half-home for years is a professional as well as emotional decision. It’s an important decision which can be (& mostly is) a result of multiple factors,
Recently I saw a Job description with title ‘Lead QA Developer’. In my view this is the perfect depiction of today’s changing QA landscape where a Tester is expected to – Lead, i.e. planning, strategy, team management and reporting – Quality Assurance, i.e. Test methodology, process, defects management, agile, requirements analysis, test techniques, etc. and – Developer, i.e. hands-on knowledge of programming languages like Java, Python, C#, etc. to build automation frameworks and tools for validation.
Current competencies are important, but we need to have a long-term vision. It’s important to be aware of the IT industry trends. The industry will change. Choice is yours – up-skill now (relatively easy) OR up-skill when you get stuck (it’s hard, believe me).
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.
Most of the times it’s urgent in IT world. Please complete this ASAP. This is priority. It’s Urgent. Especially with Offshore team’s take-it-all hard-working attitude. We should understand that everybody is a human-being. On the other hand, we should learn to say no. There is no harm in saying ‘No’ to unrealistic expectations.
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.
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.