6

A strategic approach If you cut a couple of hours and don't make other changes than next week more tests will be added... and the time will increase again. So this is an excellent opportunity for a discussion on strategy. Not to seek immediate answers (hence I'm not providing them), but to start the conversation for your given situation to see what will ...


3

One test. Two setup steps. What you have described is very common, particularly as test scenarios get more complex. What you need is one test with setup that does the user logging in, the user selecting the item (save the id) and then deleted and then you go the dashboard. So don't think in terms of your two existing tests, think in terms of a new test but ...


2

It's an single integration test. First of all it has nothing to do with playwright, it's common automation scenario which can occur while using any automation library/frameworks. I have faced this similar scenario in qtp, selenium, protractor, and playwright . Usually this will be an single integration test where we dynamically store ID on a test level ...


2

Management usually likes to have reasoning in terms of time/money, so I'd go with the following approach: Take last X (e.g. 30) executions and get average execution time for the whole suite and each test scenario Select top 10-25% scenarios which take the most time on average to execute Create a nice presentation view (e.g. table) with current execution ...


1

From your question I see that you want to make a smoke test on a production system. Testing on production could be very risky in some scenarios. So there are few questions that you should analyze: Do you change the state of the system accessed only with specific user or they will be available to all prod users? If the data is available to prod users for me ...


Only top voted, non community-wiki answers of a minimum length are eligible