Some time ago in my do/don't recommendation I encouraged you to take care of your testing environment and learn orchestration tool like Ansible. Somewhere between writing automated tests and implementing Continuous Delivery I came across interesting concept popularised by Seth Eliot - TestOps. Even though Richard Bradshaw didn't like the name I really think there is something smart in this concept. By googling the name I found great paper which says:
TestOps as a concept revolves around ensuring product teams have access to any required test infrastructure, platforms and frameworks they require without needing large amounts of time consuming configuration before commencing tests. Any benefit from use of a CI system will be lost if the QA process takes days to complete due to environmental setup and tear down on the part of the QA person on a team.This post will start new series which will focus on various technical testing topics like:
- Testing in Production
- Testing in Continuous Delivery era
- Testing in the Cloud
- Testing in Agile/Lean
- Monitoring (+ Alerting?)
- Data-Driven Quality
Why bother though? Here are the benefits:
1. Stepping outside comfort zone
In almost every area of life it's worth to try new things. Whether it's journey to unknown country, new dish or studying new language benefits are unquestionable. You get yourself familiar with learning process, which I believe is a skill. There are many people in our society who fear to even take different route to work (usually they're older, that's why companies prefer younger employees accustomed to continuous change). If you don't have continuous improvement mindset you can't excel in IT/testing industry. Train yourself to change it.
If you want to be an effective employee, then take a look at your job description and treat the description a soft boundary.
2. Deepening your Software Engineering understanding
In my post about learning pathways for testers I mentioned already that you should be very critical which sources you choose to follow. The amount of online resources/blogs/books is pretty much unlimited. Before starting something new ask yourself few questions:
a) What business problem am I trying to solve?
b) How much would my solution benefit stakeholders?
c) Why am I doing this?
Usually those questions require you to look at your work from bigger picture. By extending your knowledge in software engineering via valuable books four answers to those questions would be more precise. That's why senior, experienced engineers are so valuable on job market - they not only have broad knowledge from the books, but also hands on experience. You can't beat them by experience,so there is only one way.
In Google era, and with right amount of soft/teamwork skills you can solve almost every precisely defined problem.
3. Possibility to learn new things
Don't get yourself entrapped in small testing world. Expand your all around knowledge in IT.
Selenium Grid doesn't crash because it's unstable. It has custom configuration, limited Java resources and network configuration. Did you try to change them to make it work?
Slow integration tests? Did you try to run them simultaneously? Did you stop trying after encountering first obstacle?
Slow application build? Did you try to change Jenkins/TeamCity/Bamboo server/agent configuration?
There is so many testing related things that can be improved by skilled Operations work that it simply can't be ignored. Viktor Farcic in 'The DevOps 2.0 Toolkit' gives us almost unlimited amount of knowledge. It's not rocket science by any means.
4. Possibility to discover new areas of testing
Experienced exploratory testing. Crème de la crème of testing industry. I wouldn't say that manual tests would be soon replaced by automated checks in 100%. However to make them really effective from business point of view they need to find serious bugs as soon as possible. It can't be misspelling and it can't be wrong error message (unless of course it's a sign of something bigger in application core). It has to be serious performance problem, slow application speed under large traffic, unscalable design or something big.
All those things require deep knowledge. Architecture knowledge. Coding knowledge. Software Engineering knowledge. You won't gain it just by reading ISTQB syllabuses.
5. Making your contribution indispensable
At first I titled this chapter as 'Making yourself indispensable', however it has very bad connotations. Some people naively think that by writing obscure code and by designing silly architecture they are making yourself irreplaceable. That's not true. Real security comes from broad knowledge. Always try to improve your employability (Rob Lambert has written nice book about that).
You should aim at making your day-to-day contribution indispensable. This gives you real job security. By being smart you can sleep well.
If you are among the top 1% in the world at what you do, you will never have to worry about “making it”. It’s the surest path there is.