If You want to start with agile testing on Your project – firstly You need to forget that You’re only QA/QC. In agile testing You are agile software development engineer which is involved in development processes from test perspective.
It’s very interesting – what are real responsibilities of agile tester?
Let’s think about usual responsibilities of testers on the project. Tester need to write test documentation, tester need to test application and report a bugs, tester need to prepare release documentation about defects, test process, etc.

But maybe it’s possible to avoid unwanted bugs? No – it’s impossible. But possible to reduce amount of the bugs. How to do it?
First of all – tester need start to think not only on the level of acceptance user. Try to think on unit level of application, on component and integration level. Try to think about behaviour of relationship between component.

Yes, I’m talking about TDD and BDD approaches. For this You need to know another agile testing approaches which are very useful and are required.

Test pyramid

idealautomatedtestingpyramid

As a agile tester You need to make test coverage on Your test application like it’s on image above. If You want to avoid long time verification during GUI testing, UAP testing – try to cover Your application by tests on unit and integration levels. This approach will help You to avoid the verification of a lot of cases on GUI level. This is ideal model.

Another approaches – Agile testing Quadrants (image is taken from http://lisacrispin.com/)

Agile-Testing-Quadrants

Important to divide You project for 4 Quadrants. Each of these quadrants covers another side of the project. You need to remember about importance of Automation testing on the project. Automation testing – it’s not only coverage of application on GUI level. It’s coverage by Unit tests, Behaviour tests.
Each of these quadrants also has priority. I will try to explain more about Agile testing quadrants in the next articles.

Let’s go next.

TDD and BDD

What is TDD (Test-driven development) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards (From Wikipedia).

16728

It’s mean that agile tester should really know development process.
What the tools are useful – all the unit-test framework. (JUnit, NUnit, TestNG etc.). It’s depend on platform where You’re working.

But what if You need to join all the created functions? You need to create some real behaviour scenarios and test it too. You need to think from business perspective and from test perspective on development level.
In this case it’s time to bethink about ATDD.
ATDD (Acceptance test-driven development) 
is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as Specification by Example, Behaviour Driven Development (BDD), Example-Driven Development (EDD), and Story Test-Driven Development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language. ATDD is closely related to Test-Driven Development[TDD]. It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding. (from Wikipedia)

The most popular practices is BDD. You can describe Your test story in human-readable text or html file and implement it in the code. This is very useful if You want to collect You test documentation and code in one place. It’s called Living documentation.
The most popular tools are JBehave, Cucumber, Concordion.

So, as You see – agile tester it’s a bit different tester from non-agile, because agile tester need to be able with developers on the same code. Don’t scare to use these approaches and practices on Your project. You will see benefits after some times. It will help to save the time of test execution.

Best regards,

Denys