You love roller coasters, right? If you are sure it's well maintained. You love climbing? If the ropes are in place.
Psychological safety is the state of mind where you are not afraid to take chances, make mistakes, and get messy. Because while doing so, you feel safe.
Safety at the workplace opens people up to collaboration, innovation and increases employee retention rates. Why? Same as roller coasters, boulders and spaceship codes, danger is fun until it is, well... not actually dangerous. Let's see what can testing do to help cushioning workdays.
Reputation
In my experience as a DevOps engineer, this hits hard with developers on every project, every culture. I have seen companies measuring test coverage of lines of code, characters even and that did exactly the opposite of what the management expected. The number of errors did not go down, test breaks slowed down development and automation pipelines. Until we changed the KPIs. We started to measure code coverage by how many bugs a feature produced.
Except some bugs which can't be bound to a parent, bug numbers went down at an instant. Now, instead of polishing statistics, devs were putting meaning behind testing. Started asking questions to cover more possible testcases. Introduced new testing strategies to spot the bugs as early as possible. Luckily the management allowed time for meaningful discovery. And they never went back on this decision, because cumbersome and expensive manual testing went down drastically.
Taking calculated risks
What if? We all have those great ideas we would try if we would be sure it works out. Wouldn't be nice? When tests are covering the core functionality of the software, it makes it easier to test wild ideas and unusual solutions. When the outcome can be assessed easily, you will move faster and easier. Can we migrate the entire codebase to WebAssembly? No if we have to reverse engineer all details of the logic before even starting. Can we do so by satisfying the existing tests? Of course, we have the requirements in place, a way to measure progress, validating the results, what else do we need?
Make blameless culture happen
When I get a new colleague, and all training settle, I never miss to explain the post mortem, crisis meetings, how to initiate critical patches and other procedures in case of risk. Because I don't want anyone to keep their ideas in the drawer because they don't trust testing. It's interesting how software testing is around since the nineteen-fifties and still sounds like space age for some. This is the least I can do to let them know, we can stay in control when something goes in unexpected directions.
We don't need guided meditation to learn to manage stress. We don't need time management training to find time to write unit tests.
What we need to feel safe
- Chaos days to practice handling stress by unexpected issues
- Open communication between developer, QA engineer, tester and product personnel about the goal and use of the features instead of outlines of function
- Measuring tests by results (nr. of bugs in production) instead of line coverage
- Providing time to developers to write tests, instead of driving the code forward and make manual testers more work
Top comments (0)