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.
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.
Programming is integral to IT, and automation is no different. What interviewers are looking for is if you can think of the correct logic or algorithm. It gives them an idea about your logical thinking prowess.
Most of the times people are not afraid of too much work or learning something new or stretched working hours. What’s frustrating is the messed up work, not too-much work.
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…
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. Continuing on our “JD Talks” series – we mine hundreds of QA Job descriptions to come up with latest tools, technology, languages and concepts. Let’s see what the fourth set of JDs talk about…
As mobile applications and software development have become a larger player in modern business, it has become increasingly important for those who don’t have a traditional background in coding to learn basic coding techniques. Simultaneously, because of modern tech advances, it’s possible to begin to learn certain coding practices without having a deep background in the subject.
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.