Thema: Being a Tester
- AI for Testing
- API Testing
- BDD: Behaviour Driven Development
- Being a Tester
- Continuous Transparency
- Crowd Testing
- Ensemble Testing
- Exploratory Testing
- Scaled Agile Testing
- Team Work
- Test Automation
- Test Management
- Test Suite Optimization
- Testing Roles and Permissions
- Testing Skills
Test automation, continuous integration, pipelines... the need for speed increased exponentially over the last decade.
Applying Darwin's theory, it is quite simple: only the fittest -in this case the fastest- will survive. Traditional, manual testers are like a rhinoceros... in danger of extinction.
But even those fast rages have their shortcomings, like the automation fake news or automation paradox. In this presentation, Wim explains why 'slow' testing is still there and which survival techniques (like Transform to a no-sheep tester, Think glocally) you need as a manual tester to secure your position for the future.
Target Audience: Testers, test managers, technical testers (test automators), stakeholders involved in testing
The world of testing has evolved a lot over the last decade. Manual testing is under pressure by a lot of fast rages like test automation, CI/CD, pipelines, ... And so one can wonder if traditional manual testers still have their place and will remain relevant within the future.
But those fast rages are not always 'hallelujah'. And that is for me one of the main arguments why manual testing will always remain relevant.
Especially when we look to test automation, it is a fact that this is not always successful. To my opinion, this is due to 3 main reasons: automation fake news, automation blindness and automation paradox. Automation fake news is about the promises -made by tool vendors, test automators to customers, management- but aren't always fully realised in practice. Some examples : unattended testing, one-click automation. Automation blindness is about the tunnel vision test automators have by ignoring questions like 'Which data combinations are relevant to automate? Do we really need to execute all data combinations?'. Furthermore, test reports are not always analysed in depth. Why do we get a fail? Is this an application failure or a failure introduced due to our own automation code?
Another argument for the relevancy of manual testing is the increased complexity of things. This makes it in some cases even not possible or not efficient to automate things (e.g. how do test an airplane?).
But... manual testing has evolved and needs to be adapted to this changing world. For manual testers, this require other or adapted skills.
I see 4 main skills we should have:
- Transform to no-sheep tester
= stop with complaining like bleating sheeps that we don't have proper, complete requirements or builds are not stable. Instead use those situations by showing your added value as manual tester by applying techniques like exploratory testing, sanity & smoke testing.
- Get a fika
= It is a Swedish tradition to build in fixed moments in the morning and afternoon to drop your work and socialize with colleagues to talk about everything else than work. Manual testers should participate in such fika's because you get indirectly a lot of crucial information that can help you further.
- CRUD the crap
= Just like the English slang expression 'Cut the crap', testers should provide info to the business in a no-nonsense way. No bullshitting and especially no overwhelming the stakeholders by figures. At the end, stakeholders are mainly interested in the fact if the application/software meet the requirements of a C(reate), R(ead), U(pdate), D(elete) test.
- Think glocally (and no, this is not a typo :-)
Manual testers have to oversee the complete picture in complex architecture. Especially with regards to preparation of test data for E2E tests, time travels. In this area they can show off their added value.
Conclusion: survival of the fittest is not about the fastest, but about the smartest both for test automation and manual testing.