I'm not a fan of using tags and label to categorize tests as "WIP", or having a category called "flakey"! Categories are great for groupings by functionality/feature or groupings by component. Often tests get put into folders based on one of these 2 architectural decisions, and it's often good practice to have tests in folders that mimic the product architecture. So I prefer to limit to categories that reflect a functionality-stripe across these. Using tags to denote flakey tests is unwize, because it means someone has to do a commit on the repo when you work out that the flakey test was in fact a product bug, not a test bug. It mixes status data with code! Your bug tracker and triage process is where you want to track risks, tagging flakey tests is a smell, because it openly tempts you to bury them.
Really useful, I understood some lacking parts of the test automations on my end
Great presentation. A lot of good content.
Very good and helpful video. When can we expect same for Mobile Apps automation ?
Very Informative Video about selenium
I'm not a fan of using tags and label to categorize tests as "WIP", or having a category called "flakey"! Categories are great for groupings by functionality/feature or groupings by component. Often tests get put into folders based on one of these 2 architectural decisions, and it's often good practice to have tests in folders that mimic the product architecture. So I prefer to limit to categories that reflect a functionality-stripe across these. Using tags to denote flakey tests is unwize, because it means someone has to do a commit on the repo when you work out that the flakey test was in fact a product bug, not a test bug. It mixes status data with code! Your bug tracker and triage process is where you want to track risks, tagging flakey tests is a smell, because it openly tempts you to bury them.