30 Days of Agile Testing, Day 24 & 25: What can & can't be automated

I thought I’d add Day 24 and 25 of the challenge to the one post as I think they go quite well hand in hand.

I’ve asked on here before about What to automate as I’m never quite sure what I should automate.

As TestRail are sponsoring the challenge, I thought I would look to their blog to see what was on offer. I found two interesting blog posts, the first about Reasonable UI automation and the second about The future of near instant deployments and continuous human testing.

Between all of these, and given that I’m still learning webdriverio, I decided to look at the login screen. I hear many automators laugh already, bear with me on my reasoning for this. My reasoning was largely risk based. If you don’t supply a password, you should not be allowed to log in and you should remain on the login page. If this failed it would be an indicator that someone could potentially get past this screen (in a financial application that stores a lot of personal information) and is a pretty high risk for us. It’s not a happy flow through the system, I regularly check manually that I can log in with valid credentials but I don’t always remember to check the negative case. I’m the only tester on the team so it made sense to me to automate this.

What can’t be automated? I struggled with this one a bit so my answer here is a bit weaker. My team felt that automation should/could be chained and have e.g. user logs in, user navigates to page X, user does action Y which navigates them to page Z. You can do this if you want to but it’s not advisable so I worked towards communicating this to my team. Again, I took the risk approach. I highlighted that if step 1 failed then the chained events that followed would also fail which wouldn’t really tell us a whole lot about them depending on what we were checking in the steps.

How have you all got on with these tasks? What have you automated? What have you felt that you could not automate?

3 Likes

Some blogs I found from others participating in the challenge

Honestly, I think testing the negative login cases explicitly is a smart thing to do. :slight_smile:

The only test that I’m against as a general rule is a generic login test…since you should be doing that in your tests that go through the system as a whole.

1 Like