ERROR: Content Element with uid "13441" and type "dce_dceuid16" has no rendering definition!
We all know that a modern tester should have both analytical skills and basic knowledge of programming as well as soft skills. If we add experience in agile software development, we get an almost perfect candidate in the eyes of employers.
However, what if one day your employer says:
- Our sensor has been recently working too short. Please, do the battery life tests.
- Current functionalities of our product will be enhanced soon. Please, write some tests for the embedded platform.
- Clients are complaining about our system working too slowly. Please, prepare the testing environment for performance tests of microprocessor memory.
Apart from the word „please”, above sentences have one more thing in common – for a long time neither of them was of any interest to the software tester.
Nowadays, the world is changing and very soon testers can face such challenges but it is still not so common to make them aware of it during QA’s conferences. The content of this presentation consists of 3 major parts:
1) Risks, challenges and safety aspect the modern tester should be aware of
2) The real-life examples of safety vulnerabilities and its impact on customers (and the scale of it!)
3) What makes testing so exciting despite so much responsibility and so many challenges
Risks, challenges and safety aspect:
1) Be aware of flaky tests and its reasons
Now we live in the era of continuously delivered things. That causes even more and more test automation that we rely on. However, can we still treat every environment as safe enough? We should be still aware of false negatives (the test is marked as Passed when the functionality is not working) and false positives (the test is marked as Failed when the functionality is working). There is also something even worse - flaky tests (tests failing intermittently). And there are a lot of reasons behind that... (both, human and environmental ones)
2) Updates (OTA) as the most risky area
One of the most used “functionalities” by (aware or not) customers. When you think about SW update, usually that’s not something to be considered and safety critical. For web applications, every blocker can be fixed by fast deployment or bugfix. For mobile apps, it’s a matter of releasing a new version to store. Even for a desktop, you can force your user to reinstall it once again. But what if something goes wrong for IoT/HW devices? Is there any safety “belt” or procedure to prevent your firmware from turning into a brick?
3) Scale matters
New smart devices are very often responsible for public and private safety. To cover dedicated area (or just get your customers involved) there are a lot of them needed - sometimes thousands of them! Do you think that scale can be skipped during testing? How to ensure safe infrastructure when your network is growing up? Which parameters should be considered as important (e.g connectivity issues, configuration, geolocation, external influences, wireless signals multiplication)?
4) Testing real user behavior
Is your customer always following feature workflow intended by you? In most cases, your predictions are not fully consistent with the user’s real behavior. In that case, to achieve the high level of safety, you must rethink and redesign your test strategy (and implementation) approach. Let’s look at the example...
5) Focus on CXA/CEA (customer experience assurance)
Keep your customer safe! That’s the main principle for modern, smart devices world. Sometimes functionality working perfectly according to business requirements, but not exactly covering users’ expectations, can be much more harmful than functionality not working at all! What if light or laser strength suits all regulations but is not appropriate for young children? What if pets’ cookies are flying too fast and can frighten your cat? What if your house locks automatically and doesn’t want to let you in?
6) Limited trust in open source
We all know that statement. It relates not only to safety aspects but it also relates to security issues even more! Using open source for testing in the worst case can destroy your infrastructure or make it unmaintainable… Is there any chance to avoid such destructive impact?
7) Keeping safety during working with IoT & HW
Last but not least! Working with HW and equipment means embracing all physics rules. Rules that are sometimes ruthless… It is more than recommended to get familiar with some major principles while working with current, volts, and temperature - to minimize the number of explosions in your test lab :)
Who am I?
1/3 QA, 1/3 DevOps, 1/3 Lead. Last 10 years spent in Kraków. Tech freak following all the newest technologies (and implementing them on his own). Fan of Agile approach to project management and products. Proudly and patriotically awarded as "People of Testing 2018".
What do I do?
Leading and supporting the best and the happiest QA team! Actively speaking (and traveling) around the world (combining both passions). Organizer and originator of the first regular Ukrainian QA meetup "UkrainQA". Currently actively supporting Krakow testing community KraQA.
Where can you find me?
Linkedin, Twitter, Facebook, e-mail or beer table : )
What do I like?
#coffeeWithPeople, #newTechnologies, #DiscworldWorld, #sharingKnowlege, #boardGames, #craftBeers, #classicVinyls, #usuallyMyWife