I participated 25th of May on a panel discussion at Ohjelmistotestaus 2016 Conference in Helsinki, Finland. Our theme was testing trends and related to that, the future of testing. Besides me, there was also Erkki Pöyhönen (Lead Test Manager from Tieto) and Virpi Mehtälä (Test Manager from Prove Expertise).
I dropped some topics from my blog post (e.g. one related to open source development and couple questions from audience) as I wanted to keep the content more compact. But otherwise this summarizes quite well the conversations we had.
This is where we started from and from my point of view it was logical to start from. Mainly because software development approaches affect to testing approaches. We were all given our opportunity to express our thoughts and this pattern repeated on following topics also.
Virpi mentioned that risks are being focused on more these days (compared to what it was before) and that agile approaches are slowly affecting also contexts that she is working at currently.
I personally tried to emphasize that contexts vary. In some domains (like medical devices) current trends (e.g. Continuous Deployment) can be challenging to apply. Also there’s much differences how sophisticated the software development approaches in companies are. In some teams, the approaches were more modern in 1950’s than they are today in some organisations. It can also take decades for many companies to achieve what has been achieved now in companies like Netflix or Amazon. Considering that it’s an approach that companies should strive for in their context.
Nevertheless, out of frustration for not getting users needs met and taking too long, many different solutions have come to speeding up the time from idea to need being met. And to be able to keep that reliability (of producing high quality working software) on long term. Some of these examples are Scrum, Agile, BDD, TDD, Microservices architecture (in longer term perhaps systems that resemble biological organisms - see e.g. Wunderlist & Chad Fowler and Conscientious Software by Richard P. Gabriel), DevOps and Automation in Testing.
Erkki talked how we’ve grown as industry out of silver bullet approaches and have these days several approaches for software development. Also these days it gets harder and harder to focus on doing something really technically specific thing. Or as a consequence you might find your company being bought and your skills not matching the new context anymore. He also emphasized how testing is a service and needs to follow what is happening around us.
Virpi continued with saying that these days companies are focusing more on testing and the company she is working at, gets more and more clients because of this. This though requires constant development of personal skills.
Erkki mentioned first containers and Docker. He emphasized how it is enabling DevOps actually being reality in daily life of development team.
I personally raised Mob Programming and generally all the effort on improving the collaboration between members of the team. Related to this I mentioned cross-functional teams and a wish for breaking the silo between IT & business. Which would mean considering if organisation and physical locations could be more of a mixture instead of being separated to different locations. In other words, taking Conway’s Law into consideration more, as Maaret Pyhäjärvi (who hosted the session) brought up.
Virpi was herself excited that testers are part of the team these days, instead of being separated to different place. She felt that she is being listened more these days and able to show her value.
Virpi highlighted how these days (and in future) software is being released more quickly and there’s less time for testing it. Related to this she mentioned that more focus has to be put into thinking what’s the most wisest way to do your own work.
I mentioned that these days there is not much testing related jobs that don’t require technical (usually programming) skills. Hard to say though how far this trend will go as it’s getting close to hiring just another programmer. And when you focus on programming, that’s mostly away from specializing in testing.
Besides technical skills being demanded from testers, I also raised how I would personally hope to see that BDD kind of approaches get more common, where there’s more questioning happening before anything is actually implemented. I didn’t mention but it’s basically decreasing essential complexity (see Fred Brooks & No Silver Bullet).
Erkki mentioned from his own context how there’s hypotheses being measured in production (related to Lean Startup) and this way own assumptions being verified, instead of just releasing features to production and moving on. He also emphasized that testers need to be these days able to question even the priorities of features that will be done. Besides these crowdsourcing (uTest) was also mentioned, which is one the trends that is good to know about.
Not so seriously we collectively threw some ideas on what kind of skills should Full Stack Tester have. Some of these were
- Mobile testing (including automation)
- Automation generally (UI, API, Unit)
- CI, CD (including relevant tools: e.g. Jenkins, TeamCity, Docker)
- Cloud services (e.g. Azure, AWS)
- DBA, SysAdmin
- Performance, Security and Usability testing
I interpreted this as joining a new company and understanding basics of testing. Then what should you focus on. Which is why I explained how one should try to understand how the team works and what kind of workflows there exists. After this one can start to consider what to focus on as tester (e.g. adding API checks, improving requirements, having heuristics to support exploratory testing).
Virpi disagreed with me and told that basics of testing needs to be understood first, which is fair point as it wasn’t known how well this person knew about testing. She suggested BBST Foundations course which is a brilliant course for someone who hasn’t been in industry for a long time, or even if has been in industry for a long time.
Erkki added to conversation by commenting that it’s good that people face different contexts and situations as it gives person perspective which can be valuable.
I tried to highlight on my answer that companies should first focus on recognizing what problems they are trying to solve. If you recognize that you really need to speed up the lead time - from idea to need being met - then you might pay attention to adding checks, DevOps, TDD, flow of work (e.g. WIP) and so on. But you need to understand which problems you are trying to solve with those.
Virpi mentioned herself curiosity. And maintaining that in long term.
After Virpi I raised self-awareness. Know where you are at the moment, before moving forward. As it’s often more valuable to understand what you are doing now than implement something new. We might have all kinds of diagrams for explaining our processes, but is that truly what is happening?
Erkki tackled this topic by talking about focusing on answering what am I as individual able to provide for others. What is good enough? That you are not ending up spending too long hours at office while trying to keep up with changes in your work environment.