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?
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.
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.
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…
Too much work, every day we stay late in office. Oh it just skipped my mind, sorry. Let’s discuss it tomorrow. His/her mail is always ambiguous, let’s discuss on call directly. They are discussing about the technical design, we (testers) need not attend. Hey developer – have mailed you the bug, please investigate. These are some of the common dialogues in our everyday IT life. Ever thought of changing something? Nah? Yes? Every one of us notices something errant but then forget about it the next moment. But we say – Small changes can make a big difference to your career.
Enterprise mobility solutions can present a number of challenges – Mobile governance, or the Management of people, policy, and process issues. At times it can seem like a minefield, but enterprises can quickly identify these challenges and overcome them in order to deploy an innovative enterprise mobility strategy. Companies need to bring all stakeholders into the fold to create truly productive and effective Enterprise Mobility. Here are the key challenges that organizations face as they define their Mobility strategy.
Purpose, noun, the reason for which something is done. Recently a discussion was started by one of the Testing co-blogger at LinkedIn “What drives Quality Assurance? What is the purpose of Software Testing?” A relevant discussion indeed. They say “If you’re not working with purpose, you’re doing it wrong.” This triggered me to put on the thinking hat and pen down my perspective of ‘Software Testing Goals’.
Defect Leakage is natural. It’s common. If you build a software, bugs will be there. Similarly even if you Test a software, you cannot prove their absence. But we can do our best to eliminate maximum of them. Typically in most of the projects even if you complete functional testing (system testing) without any time & cost constraints, still UAT team (Business) manages to catch some more bugs. Any idea why? There has to be something missing in the system test coverage. What is it?
From the time I am blogging, it makes sense to me to pen down my sudden thoughts. Many a times you come up with an idea, memory, solution, problem, anything and it is lost since we don’t remember it in future. That’s when I started writing my sudden thoughts about Software Testing and guess what, the ‘Sudden Thoughts of a Software Tester’ is getting a lot of traction on my Social profiles. So thought of sharing it with you all. Here we go…
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.
For more than a decade now, Agile Project Management has been used and it wonderfully continues to grow in popularity. It is one effective methodology introducing revolutionary methods for the practice of project management. ‘Agile’ is an umbrella term used for identifying various models used for agile development, such as Scrum. Since agile development model is different from conventional models, agile project management is a specialized area in project management. It is required for one to have a good understanding of the agile development process in order to understand agile project management.
Most of the QA professionals are among the smartest people on this earth who often boast advanced degrees in engineering, mathematics or computer science. In some ways, we are like Superheroes – capable of breaking down a whole application and defeating an army of programmers with our defects, testing complex functions, juggling numerous technologies, ensuring customer ideas morphed into working software, all the while not breaking a sweat. So how is it that despite such technical savvy, programming prowess and quality driven attitude, we are defeated at test estimation front?