terça-feira, 21 de abril de 2015

TestOps

    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.
 

segunda-feira, 6 de abril de 2015

How to set the Definition of Done of User Stories?

Agile teams tend to have a hard time while defining the Definition of Done - DoD of user stories (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?
The best way to accomplish this is by having user acceptance automated tests. Those tests can be written in the Gherkin language, forming a live and dynamic documentation. If a test fails, a requirement fails. If a test pass, it proves that the user story is complete and correctly implemented.
Delivering a requirement is demonstrating that it is working as expected and guaranteeing that the DoD has been fulfilled can be accomplished by having the acceptance tests passing.