DevOps is currently a trendy approach in software development. The DevOps world mixes the Development and the Operation concepts, but where does software testing find its place in this new approach? This is the topic of the book “Practical Guide to Testing in DevOps” by Katrina Clokie.
This journey towards establishing a strategy for software testing in a DevOps context starts primarily at page 10 with a test strategy retrospective. After an assessment of the current situation, a new strategy for software testing in DevOps will be developed during the rest of the book with a lot of pragmatic explanations and practical examples on how to test in development and production environments. A final section provides some examples of the implementation of DevOps testing in some organizations. Besides that it is easy to read, the book provides a lot of references to external sources for the readers that want to explore further a specific topic.
I recommend this book to every software tester and software development manager that wants to have a better understanding on how to integrate the software testing activity in a DevOps context.
Reference: A Practical Guide to Testing in DevOps, Katrina Clokie, http://leanpub.com/testingindevops
Quotes
DevOps pushes the development team to actively engage more widely within their organisation, beyond the roles that are involved in development to those that support it: operations infrastructure and monitoring, customer support, and analytics. This change broadens the network of people who collaborate, which will further extend the boundaries and nature of testing.
DevOps has a broad scope and can look different in different organisations. The first step in developing an effective test approach is to understand the context in which you’re working. You need to understand what DevOps means in your situation and become confident articulating your goals. Start by identifying the people who are involved in delivering your product, both in and beyond your development team. Include developers, business analysts, designers, product owners, operations engineers, agile coaches, delivery managers, and any other relevant roles in your organisation. DevOps affects all these roles. Once you’ve thought about who these people are, try to find out what DevOps means to them.
Testing that happens during development is best spent exploring: searching for the unknowns of the system, adopting different personas to offer varied subjective feedback, attempting to subvert security measures through malicious activity, or exploring the performance boundaries of the application. Focus on areas where the human brain is required to think: generate ideas, process results, and form opinions.
A bug in development can be a good opportunity to test log files. Any problems should create appropriate log messages. If you cannot determine the bug from log files alone, this may indicate that your logging is either insufficient or so verbose that it is impossible to locate the problem! If you can determine the bug, it may be worth checking that someone from your support team is able to reach the same conclusion from the log file.
Automation can be faster than repetitive manual checking, but it is also costly to develop and maintain. When speed to market is important, you may not want to invest as much time in writing pre-release test automation as you have in the past. A DevOps automation strategy can be more pragmatic. You need enough automation to help you make a release decision, but not so much that you are hampered by it.