Unless you’ve had your head under a rock for the past ten years, there’s no doubt that you’ve come across Agile in some way, shape, or form. Love it or hate it, it’s taken the development world by storm since it’s introduction in the early 2000s. In contrast to older methodologies, Agile testing is more holistic. It offers a flexible approach to software development that relies on smaller iterative releases rather than large project rollouts. What that means for testers is that they can expect to work more closely and in collaboration with developers. Agile Testing vs. Waterfall Method Before diving into the process of Agile testing itself, it helps to understand the key differences between Agile and older methodologies, such as the Waterfall method. The Waterfall method, which has been around for decades, is not unlike the processes that many manufacturing companies use to develop physical goods. The process breaks down into several distinctive stages that work fairly independently from one another. Beginning with gathering business requirements, the process eventually trickles down (like a waterfall) to the coding stage. Under Waterfall, software developers strive to deliver code to testers that are as close to the final product as possible. […]
Can you ever say with 100% confidence that a piece of software is functional, reliable, and defect-free? Unless you happen to be testing ‘Hello world’ or something of a similar complexity, you can’t really make any guarantees. It’s widely accepted that complete testing is not something that is feasible in practice, but all projects reach a point where you need to step away and stop testing. Sometimes there are deadlines that force you to pull the plug on testing, or a dwindling budget. Then there are other times when the project team just has to make the call: Are we done testing, or not? Sadly, there are no magic formulas that will give you the answer of when to stop testing. However, you can make an educated and an informed decision by taking into account the following factors. Factors that help determine when to stop testing Test Coverage Having 100% test coverage is ideal, but isn’t always realistic given real lifetime and cost constraints. When it comes to website and mobile apps, in particular, accounting for 100% of devices, browsers, and other conditional factors is nearly impossible. Let’s say, for example, that you’re developing a web application. Testing it on popular […]
The idea that automated testing might one day usurp human testers has been around for years. The truth is that automated testing can be a major time and resource saver, but it must be applied in the right places. There is no substitute for some human testing. At the end of the day, software is designed for use by people, so manual testing is going to offer insights from a perspective that we can’t replicate with automation tools. Taking our jobs Could the design and implementation of great automation tools actually lead to a decrease in manual testing and a reduction in the number of testing jobs for humans? It’s not often admitted, but if we’re honest, the answer to this question is yes. It stands to reason that if human testers used to handle all the testing to ensure new functionality meets requirements and all of the regression testing, you’ll need fewer testers to complete the project if you conduct automated testing. There’s no way to automate everything a tester does, but the time-consuming, repetitive tasks are ripe for automation. Think of it like the mechanization of a farm. In the past, the farmer would have hired people to harvest […]
A great test strategy is only as good as its foundation. That foundation is built upon gathering and identifying the proper test criteria. Establishing test criteria is an absolutely crucial step in the software development lifecycle. To get you up to speed with the process, here’s a quick run-down of how it works. Involve testers early Software testers are key stakeholders in any development project. Their involvement in projects from the inception is crucial. Typically, project ideas stem from the business side. Once a basic idea is conceived, business analysts, developers, and other technology stakeholders (e.g. system administrators, database engineers) then get together to set the groundwork for a new project. Testers and QA analysts are often left out of these initial meetings. Well, they shouldn’t be. The earlier testers have involvement in a project, the more opportunity they have to learn about its purpose, intention, and intended audience — all of which provide essential context when it comes time to establish test criteria.
Automated testing is quickly establishing itself as the backbone of Agile development. Tightly compressed release cycles put pressure on developers and testers to output quality code in a short amount of time, and manual testing alone is too time and labor intensive to keep up the pace. As a result, development teams are rushing to integrate test automation into their development process in order to ease resource burdens, release higher quality code, and unlock the full potential of Agile. First thing’s first – where do automated testers come from? Automated testers generally stem from one of two backgrounds: testing or development. Manual software testers with basic coding abilities are in prime position to hone their skills and, with little training, apply them to automated testing. Likewise, already equipped with the technical know-how, developers with the flexibility to step into the mindset of a tester also make excellent automated testing candidates. Tools of the trade At the core of automation is a tool and/or framework that provides the platform to execute the test scripts. They come in seemingly endless varieties but are generally either GUI or code-based tools. GUI-based tools Though there are exceptions, GUI-based automation tools require less scripting knowledge than their code-based […]