Automated form fills
If you needed to test the forms on a website, you have probably seen how tedious this task can become. Every time the form isn't working properly, you have to go and manually type the same data to test it again. Based on the given input, the form can respond in various different ways. There are many things that can go wrong in a form, so we need to understand the possible cases and test each execution path at least once to validate that the user will see all feedback messages the way we intended. The longer the forms become, the more effort is required to test them manually (even when the browser allows us to select from previously entered data in a given field). A form with ten input fields would require a lot more typing than one with three fields. Field validation should work as expected, while not making the underlying code too hard to understand.
I was testing manually for too long, before recognizing that better alternatives exist. Other people may also not be aware of this, which gave me a reason for another blog post. In KeePass, we first register manually all usernames, passwords and URLs of the websites where automated form fills should happen. Pressing Ctrl + Alt + A allows the software to take the right data for the current site, fill the form and send the data. This approach becomes convenient as well, since we never type the same data on the same site twice. But we still need manual typing for each new site we choose to add and this doesn't scale well.
Sometimes two users of our software need to interact with each other or an action by a single user can trigger an update to the dashboards of multiple other users. In this case, the form filling software needs to support multiple accounts per form/URL and in KeePass I haven't found an easy way to create them or switch between them. RoboForm is another alternative that allows us to do this. In addition, we don't have to type things in advance of using them. Once a form is sent, we are asked whether we want to store the data for future accesses as well and we just need to click “Save”. Switching between multiple accounts per form is easy as well. Alt + Z opens a dialog with all accounts for a given form on a given site. With the up/down arrows we choose the proper account. Then pressing Alt + S automatically fills the data related to that particular account and sends the form. So if we want to test our form with five users, we would need to open five tabs in our browser first, switch to the each one, press Alt + Z, then ↓ as many times as the account number (for instance, 3 times for the third account in the list), then Alt + S. The more accounts we have, the more problematic movements with the arrow key become. With 5 accounts we need to press it at least 15 times (1+2+...+5) if we don't make the mistake to move the cursor too far (each time). But with a single account, independent of the number of form fields, this process is reduced to a single Alt + Z, which is nice.
We need to decide what happens when a user is already inside a system and tries to send the same form data, perhaps from another tab. In some cases it may be better to prevent the login, giving a feedback message of the type “This account is currently in use” or we may choose to redirect the user to the last page they have visited, once they try to access the same form again (Ymail, Gmail), or we may let them fill it again and then trigger logout to save/clean the old state and then login again to reuse that state. Depending on our goal, we may choose a different approach.
If we want to test whether our form responds with the correct feedback messages, we could create users with fake data and use it to automatically fill and send the form. Each user would correspond to a single case we expect to see and we need to worry about all these cases only once, not constantly during all our testing. If we tested manually for ten possible responses, it could become quite hard to remember which case we checked last and which one would be next (unless we constantly waste time to mark this on paper).
Tools that populate forms automatically have to be secure, since anyone who gets access to our machine could otherwise steal all our passwords. A master password makes it hard to start the software and show the passwords, but it doesn't protect us in cases where we leave our PC unlocked and go somewhere for a short pause, while the software is running (and it needs to run for automated form fills to be possible). In this case, curious co-workers would now have an easy, automated access to all the websites we visit frequently, which is in itself scary enough. They could check our emails, pretend to be sending our homework on Coursera or something else. That said, automated form fills should be used for our own site authentication or software testing needs, not as a means to send fake traffic to many websites.
Selenium also allows for automated tests, but I have found that the effort needed to invest in learning it may not be justified. Having to type and maintain lots of code makes me uncomfortable that the tests themselves may need to be tested. However, Selenium has the additional advantage that it can automatically click on links as well, not just populate forms. Although the tools mentioned above are just for forms, they are free and also keep our cognitive burden as low as possible, which is something I prefer.