Tests should save our money and time. How is it that they often become the stumbling block and slow down the work? They fail every time you try to do some refactoring and are difficult to maintain ultimately increasing the cost of software maintenance.
Agile development is a big thing nowadays. Almost every project wants to deliver value as quick as possible, but not all of them succeed because of the share amount of work most projects require. But what if you could actually deliver 2 times more value, but 3 times less features? Behat is an open source Behavior Driven Development (BDD) framework for PHP inspired by the Ruby Cucumber BDD framework.
One of the current theory about testing is that programmers take care of the unit tests and QA people manage the higher levels of the testing pyramid. In his blog post, Kenny Cruden discusses the fact that this theoretical approach can work in practice.
A paradev is defined as “anyone on a software team that doesn’t just do programming.” In his book “Pride and Paradev”, Alister Scott discusses a lot of the trade-off and issues met by software testers in an Agile software development project. As the world is not black or white, he decided to write a collection of contradictory claims about software testing; knowing that the practical implications lie somewhere in between.
Selenium tests can quickly grow in size and could become difficult to maintain, unless adhered to DRY principles to the extreme. Geb is an open source browser automation solution that brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language.
The user interface (UI) is an important part of the functionality of Android mobile apps, so you should be able to perform extensive UI tests. Google’s Mona El Mahdy has published has published on the Google Software Testing blog a post that presents four strategies to test Android UI, aiming to create UI tests that are both fast, reliable and easy to debug.
So your team has made the transition to agile and your work is broken down into user stories. It makes perfect sense to break work down into smaller chunks, but now you’re running into problems with estimation and communication. Your team is delivering value but it’s been discovered that user stories are thrashing through the analysis, development and QA processes. What is going on here? Come a software development process with a deceiving name: Behavior Driven Development.
Copyright © 2009-2026 Software Testing Magazine by Martinig & Associates