Agile testing is a major theme here at Neotys. That’s why we love it when someone takes a step back to look objectively at the agile methodology.
In this interview, e-commerce expert Calvin Baldwin tackles the fundamental differences between the agile and waterfall methodologies, why agile is not a software panacea, and whether waterfall will ever see a resurgence or if a new method will evolve to dominate software management.
Hear his interview and read the transcript here.
Are you a test leader or inspire to become a test leader of a team of testers? It is not always easy to have management responsibilities in software development when you come from a technical position. This is also true in software testing.
In this article, Mark Garzone shares some tips on how to be a better test leader or test manager. For example:
- Move testers around different testing projects
- Limit the tester’s team overtime work
- Don’t ask testers for daily email status reports
- Delegate testing work
Read these tips and more of Mark’s advice here.
Here’s a good post from Scrum Inc. about something that we all have to deal with: getting interrupted while in the middle of our plans. It’s a fact of life. So how do you deal with it in the Agile development process?
Interrupts happen. In computing, an operating system has to be able to handle interrupts or the machine will crash. It’s the same with Sprints. The key to handling interruptions is to expect them.
One of the core ideas in Scrum is that the Team is not interrupted during a Sprint. All the work that needs to be done in a Sprint should be laid out and prioritized in the Sprint Backlog during Sprint Planning.
That’s the ideal. However, there are often times when interruptions are unavoidable. This post explains some strategies for handling interruptions gracefully.
Here’s a discussion that’s generated a fair bit of feedback:
“I have a big code library that I need to refactor in order for it to fit more nicely together (one big problem is there aren’t clear enough boundaries between each component). Since there will be some regression testing necessary to validate any refactoring, would it make sense to:
- Create a unit test for a particular piece of code
- Run the unit test and make sure it passes
- Refactor the code and check that the unit test still passes
This seems like a good idea to start using a TDD approach to this refactoring process, although my biggest concern is that I’m writing unit tests after the existing code (instead of writing the code after the unit tests).
Since I’m writing unit tests AFTER the code, should I first refactor, do my own regression tests, then continue using the TDD steps (write failing test, write passing code, refactor, repeat)?
What do you think? Jump to the discussion and share your voice.