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…
Knowledge about fundamental Testing concepts is necessary to crack an interview. But now-a-days only knowledge is not enough. Interviews are not just about the theory anymore. Every interviewer is looking for candidates who have practical exposure to different kind of situations and is able to handle them effectively. Most of the companies will have it as one of their selection criteria. And yes, it doesn’t depend on the technology. For every technology there will be situations that an experienced professional knows how to tackle. In this article, we will look at some of the situational FAQ commonly asked in a testing interview. But we will need your help here. It is just a beginning, please comment any situational question that you might have faced in a recent or any past interview. This would help us to collate an informative list for the Testing community.
Today most of the organizations are moving or have already moved to agile development and testing. Or at least they think so. Sprints and daily stand-ups are common. Everybody is talking about Scrum & minimum viable product. We are tracking the team velocity & burndown. We have cut down on the documentation & invested in working software. Everyone is focused on customer satisfaction by accepting change. But wait a minute! This is too-happy a picture to be true.
How did you study when young? Ever prepared a time-table? Planned to study during early morning hours or late in the night? Researched about and collected the required books? Decided your approach to understand it or just mug it up? Focused on the main chapters which would yield maximum marks? What if you didn’t plan anything? Yeah! Chaos. You wouldn’t be here reading this in that case…That’s the importance of planning, in every sphere of life & software delivery too.
Automation testing is a concept that is heavily marketed today. There has been a real convergence of tools and approaches in automation in recent years. It’s increasingly considered as integral to project delivery, rather than something that exists to cover business-as-usual regression testing after project completion. Faster releases, increased test coverage, frequent test execution, faster feedback to development team, just to name a few are being counted as some of the Test automation benefits. Automation is being portrayed as the silver-bullet in testing technology. But everything is not so ideal. Not every organization (or client) is reaping the actual benefits of Test automation. Certain Automation testing myths must be addressed in order to correctly apply it in the most effective & efficient manner. In this article we shall examine some of the most common automation testing myths and how these prevent organizations from succeeding in Test automation.
What’s your strategy & approach to career development? Already planned it? Or still planning? You can surely utilize some industry-proven techniques, right? Similarly ‘Software Testing’ is also a process which involves strategy, approach, proper planning & using the best techniques. But before jumping on to these terminologies, first & foremost – Test Strategy & Test Plan are actual documents whereas Test Approach & Test Technique are conceptual. Test Strategy document will include your project’s particular Test Approach, apart from other details.
‘To make it Right, first identify what’s Wrong’ – but how? How do you identify what’s wrong? Intuition says – Just give me the application and I can find what’s wrong (defects), right? Nah! We are not workers, we are professionals. How do you build customer confidence with your ad-hoc tests? After all, Client is paying you to get the job done. And he/she wants ‘Quantitative’ reports & a ‘Quality’ product at the end. So how do you make sure that your Client is happy? Forget about Software Testing Life Cycle – in any Technical background, how do you make sure that your Client is super-happy @ the end?