For most testers, designing, executing, and maintaining test cases are regular activities, this is especially true for new testers and those in the early stages of their career. This post is inspired by some documentation I worked on, in an effort to standardize the testing process in one of my previous jobs. Bear in mind that in each company the approach to handling test cases can differ significantly, old-school (Waterfall-like) enterprises might favor very long and detailed test cases, where each step required to execute the test cases is described in great detail, to more Agile environment where testing is moving at a faster pace, so test cases in Agile are shorter and more concise. There is a great course at the MoT on this topic called Optimising Manual Test Scripts For An Agile Environment , by Match Archer, the course is not too long and it's full of useful info, I'd highly recommend it. There is also a third alternative - no test cases at all! This has been a trend in
Full honest disclaimer: I haven’t used many no-code automation tools, and the ones I’ve used have always been just out of curiosity, and I never went deep into any of those tools until now. I’m a QA who’s mainly focused on working with coded test automation frameworks and never had much time to look into such tools. So when the folks from testRigor approached me with a question if I would like to try out their tool, I was curious although a bit skeptical. While in the past I disregarded any no-code automation tools, as I didn’t have a need for them, in more recent years I’ve become more open to the idea of giving such tools a try. There is a time and place for everything, and coding a complete automation framework can be a waste of resources - unless you produce it exceptionally specific in terms of testing. Hence, you need to utilize all the customization that is available to you. One of the reasons I changed my mind about tools like this one, was the fact that a couple of people in
Very often, when applying to jobs you may get a task to test an app you're not familiar with, or you might not know who to start testing the product on your new job. In these situations, you can try to use heuristics (general rule of thumb) if you are unfamiliar with the application's domain. For the issues you do find, try to think about the from the user's perspective: is something blocking (like login or registration being completely broken) you completely from accessing the rest of the app? Is an issue annoying, but you can work around it? Is it a minor glitch or a text typo? To help conceptualize this approach you can use Personas-based testing. Here is a list of some techniques that can be helpful for testing most apps. For a lot of apps, you can use the CRUD approach to testing: Can you create resources, like registering for an account? Can you read data, like opening website pages without issues? Can you update data, such as changing your username? Can you delete
Comments
Post a Comment