Testing in an Agile Environment Part 1

Developers and end-users communicate closely while the software is built, and a working piece of software is delivered in a short span (we used every 2 weeks) of time.

The key I found was to deliver working software quickly to the business with minimum features and then add features after you receive feedback from the business.

The delivery timelines (again it was 2 weeks each) are short and new code is added and built on the previous build.

Coming from a waterfall-based methodology before learning the Agile method created a whole set of challenges for me and the testing team.

We found that the testing can be done more effectively in short turn-around times, by people who know the system and its objectives very well so we would pair up QA with developers. We also had our Business Analysts for the business completing some testing because they had intimate knowledge of the requirements for the business.

We found that developers were good at testing the software because they have intimate knowledge of the application being developed BUT we also liked to team them up with a QA team member. Why do you ask?

• Developers sometimes get focused and the development of their part (unit) of the code but when you combine them together (QA/DEV) in a team the testers can gain an insight into constraints that might occur with the code.

• The testers can get help with automated testing using the same development environment that the developers use.

• You can build a reusable unit testing suite for acceptance or regression testing.

• When writing automated testing as a team you create scripts that vary with the complexity of the project and the experience of the team members.

One big issue we did find with creating automated tests in this kind of environment is the team sometimes did not have enough time to design and script all the test cases in the allotted 2-week sprint.

Testing in an Agile Environment Part 1