Arquivo da tag: agile testing


    Wearing the Operations hat is no more a role exclusive of Developers, being the so called DevOps. Nowadays we can evidence the fact that Testers are also starting to wear the Operations hat and getting involved into more technical tasks; going deeper than just the usual writing and executing test cases.

     On October, 2011, Simon Munro wrote in his blog about the ideal Quality Assurance professional for the cloud computing era, calling him a TestOp; then Seth Elliot, from Microsoft, also wrote about the new term in the Software Test Professionals magazine. The term TestOp defines the future of the Quality Assurance professional.

    Being a TestOp is, for example: getting involved with Continuous Integration, with the Deployment process,  being able to use an operating system like Linux or Unix, setting up the environment for test automation. Also setting Continuous Integration server jobs, looking for plugins and tools and configuring it. Those are some sort of activities that a regular Tester is not used to acting on.

    Another important topic is computer programming, the regular Tester is fearful and avoids it. The TestOp is used to automating tasks, writing automated test scripts and dealing with test automation frameworks. Programming should be one of the main activities of the TestOp.

    The term was initially related to the cloud computing revolution but it is way broader and could be applied to all sort of environments.

Acceptance tests – Communicate and make clear the Definition of Done


Defining the DoD

Agile teams tend to have a hard time while defining the Definition of Done – DoD of user stories (user requirements). The user requirements are defined, documented, approved and passed on to the development team for estimation and implementation (coding). But how can the agile team clearly state that they delivered what was defined on user stories? How to set the Definition of Done ?

Acceptance Test Suite

An awesome way to accomplish this is by having a solid suite of user acceptance automated tests. It makes an easy task to prove that the customer usage scenarios are complete and working as expected, in other words, you are delivering value for them (and the right value). Those kind of tests are better expressed/written by using the Gherkin language, thus forming a live and dynamic documentation.

Live documentation

For example, when a requirement is updated, the corresponding test scenarios should also be updated, making sure that the software behaviour is updated, reflecting the new requirement. If a test fails, a requirement fails. If a test pass, it proves that the user story is complete and correctly implemented.

Drive TDD

Acceptance tests can also drive the software development, helping developers on knowing how to start the unit test scenarios (a common developer doubt).

Value is delivered from early phases

The acceptance tests scenarios should be written before development starts, they leverage team communication from start to the end of the development cycle.

Andrew Premdas, one of the first adopters of Cucumber, says it well:

Your cucumber features should drive your implementation, not reflect it.

Delivering a requirement is demonstrating that it is working as expected, guaranteeing that the Definition of Done has been fulfilled and that the customer is getting what he paid for. All of that can be done by using acceptance tests.