Agile Testing

by RentTesters on July 22, 2011

  • In an agile team Quality is everyone’s responsibility.
  • QA team continuously measures the Quality and provides the feedback.
  • Role of QA changes within the life cycle of the Iteration.
  • Test Automation is heavily used for regression testing while QA Engineers focus on Increase the Test coverage for “Any time Regression.
  • Automation helps to focus on exploratory testing, as one can focus on other important stuffs.
  • Quality is not added later, it evolves gradually.




Manage & control it

(Hard to accommodate)

Change is inevitable


Comprehensive up

front design

Plan as you go


Work alone

Work with Devs and BAs

Hand Offs

Formal entrance and

exit criteria

It’s not a relay race:


Test Automation

System-level, built by tool specialists,

created after the code is done

All levels, built by

everyone, an integral

part of the project

I found this article by Jack Milunsky,
QA is always near and dear to our hearts. We all talk a lot about the fact that Quality is “King” but we certainly don’t show it. In fact, we cut quality without even so much as a thought – “It’s in our bones” (Ken Schwaber). For most of my software career, QA has always been an afterthought. Developers pushed to the limits, dates slipping, so what’s the natural thing to do, cut quality, it’s the easiest and quickest thing do. The problem with cutting quality and what we don’t realize is that technical debt starts to rise exponentially. Eventually, and it’s not even that long, 3 – 5 years for most companies, your codebase will drive you and your company into a corner.

So how can you tell that your company is in this situation? Here are some tell tale signs:

* New features start to take longer and longer to develop
* Fewer people on the team know and understand the codebase
* Making even the slightest changes breaks the code
* Longer QA cycles at the end of a release
* Rising Maintenance and support costs
* More competitors enter the space
* Shrinking customer base

How to get out of the mess ….

So if you find yourself in this same position what do you do. Well in some cases there’s not much you can do and you’ll be forced to start again from scratch. However, if you’re lucky to catch this early enough, these are the things to start doing right away.

Plan on refactoring your codebase as soon as possible to start to pay back some of the technical debt – although in some cases this might be too late. You can do this in stages, by layer, by feature and functionality, or start with the highest risk code first.

* Start implementing test harnesses if you don’t already have them, especially around fragile code segments

* Develop an automated and continuous integration environment where code is compiled automatically on check-in

* Do a quality release (bug fixes, refactoring only) with no new features added

* Ensure you have a senior architect who knows what he is doing

* Start doing peer code and design reviews

* If your team is too junior shaking things up a bit may be a good approach

How to avoid these pitfalls from the getgo …

* Plan on continuously re-factoring the code base. For every 2 week (10 days to be specific) sprint we spend at least 2 days re-factoring code from previous Sprints … the result is a solid emergent architecture that grows as the features warrant and nothing more.
* Plan on fixing bugs first – at least high priority one and ones that matter. We spend a further at least 2 days every Sprint resolving bugs. Yes, do the math that leaves only 6 days out of every sprint to do new development work. Only a decade ago, this may not have been possible to work this way. But with changes in technology, we use Ruby on Rails, it is possible to do rapid software development and get a lot done in the 6 days, and even more so with a nice clean emergent architecture
* Don’t just do pair programming. But also pair developers with QA. QA folks think differently to developers and can add a ton of value front end loaded. This pays big divedents in the long run.
* Retrain your QA teams to learn how to write unit tests/test harnesses and to use tools to monitor unit test code coverage. This not only makes them better at QA but increases their skill level and offers them new career opportunities in the long run
* Strive for 100% unit test code coverage. Don’t do it just for the sake of it but you’ll be surprised how this will save your butt time and time again. Writing unit tests is not easy to do even when the environment supports it. The investment is well worth it. We have 100% unit test coverage using RSpec and as a result we are able to deploy new builds to production every 3 days and do this with confidence.
* Automate as much of the functional testing as possible.
* Ensure that code is integrated and automated tests are run continuously (In our environment, that means multiple times a day) and any issues that surface must be addressed immediately.
* Ensure that you define your test criteria up front, even at the user story level.
* Involve QA continuously rather than throwing the code over the wall to them when you’re “code complete” – what were we thinking when we came up with this terminology – in my day code complete meant another 3 months of fixing bugs. Whereas now, code complete means ready to launch.
* Continuous and on-going peer code and desing reviews
* Pair programming as often and as required

#SQASolutionShare on FacebookShare on Google+Share on LinkedInTweet about this on TwitterEmail this to someone

Previous post:

Next post: