December is a time for reflections on the year gone by. The author of this post learned an important lesson in 2014 related to agile testing: how to embrace change and learn from differences.
Deepika Mamnani was raised in India, which gives a whole new meaning to diversity. The country contains at least fifteen major languages, several religions, and thousands of castes. Yet Deepika observes that there is an essential collaboration of strengths where the intellect of the south and the east has blended with the business sense of the north and the west to create some of the most competent global technology services providers.
Read more about how this applies to agile testing.
Build Quality In is an anthology of first-person narratives from Continuous Delivery and DevOps practitioners. With forewords by Dave Farley and Patrick Debois and contributions from 20 practitioners, Build Quality In is full of great stories on how to improve quality and cadence of software delivery.
We were pleased to see that 70% of author royalties for Build Quality In are being donated to to Code Club – a not-for-profit organisation that runs a UK-wide network of free volunteer-led after-school coding clubs for children aged 9-11.
The book has been published – check it out here.
How familiar are you with TDD, ATDD, and BDD? Are you using these techniques? Do you really understand them? For those new to it, here are some quick definitions:
- Test-driven development (TDD) is a technique of using automated unit tests to drive the design of software and force decoupling of dependencies.
- ATDD stands for Acceptance Test Driven Development, it is also less commonly designated as Storytest Driven Development (STDD). It is a technique used to bring customers into the test design process before coding has begun.
- Behavior-Driven Development (BDD) combines the general techniques and principles of TDD with ideas from domain-driven design. BDD is a design activity where you build pieces of functionality incrementally guided by the expected behavior.
You can learn much more about how these techniques are similar and different in this blog post.
Many options are available for test teams to help them document how a system should work. A test strategy, test plan, test charter, test cases, test scenarios, and automation scripts are examples. This article has a matrix comparing the types of test documents you might choose and can help you pick which is right for you based on project characteristics.
Want to learn how to use this matrix? You can do so here.