Probably most of us seen or came to a project where there was no tests or there was very few of them. On the other hand there is another big fraction of software (quality) engineers struggling with test suites that last for hours. In both situations the main question we should ask is “how many tests should we really have?”.
This is not that easy question to answer. First of all we need to realize why exactly do we need automated tests… Basically there are three main reason to automate testing effort:
Continue reading “How many tests should I have”
Every developer and tester knows that it’s fundamental for every automation test to be fast and stable. But how to achieve the first of these two characteristics?
Here you can find 10 advices:
Continue reading “Best practices #3: Speeding up test suite”
The role of a quality engineer in many companies is not only testing features or implementing automation tests but introducing best coding practices and mentoring team how to test software. They (we actually) are telling developers how good coverage is important and almost force them to implement unit tests wherever it’s possible. And we all know that it’s a good approach. We all know that every production or reused code should be tested. But wait… Are testers who say so much about unit testing and coverage follow principles they enforce? Continue reading “Best practices #2: Why QA’s are hypocrites”
Many companies have a lot of regression tests but quite often are struggle with bunch of them failing every build or from time to time (flaky tests). Sometimes it is 25% or more of all of automation tests. What should you do as „quality” engineer in this situation? Should you stop deployment for months until you and your team to fix all of unstable and failing tests or should you manually check every single failure before every release to production? Or maybe you should just ignore it and wait till the situation will improve somehow itself? Continue reading “Best practices #1: Test quarantine”