Skip to main content

Testing: Automation exploration

Image Source- http://www.issart.com/blog/wp-content/uploads/2016/11/TestingAutomation.png

If this image wasn't what came to most people's mind when they heard automated testing, multiple hours and meetings would be saved. As much as the automation helps in testing, it isn't the answer to everything, and - in fact - it can add more work to your test load. As with all other software, it need maintained, and as the product evolves over time (even with only small adjustments), the automated tests need the same level of care that any other section of the product does, if not more.

Okay, enough of the lecture.

I have a project, written for both Android and iOS, that I have been given permission to add tests to: which made my day. I am trying to approach this professionally: test plan, user stories, decent documentation, and all. I spent several hours getting both the functional items and the stories written up (albeit in a brief form), so I knew what tests and checks needed done.

I can do white-box testing on this - he let me into the code, so I get to explore everything!

And found a single test: I wasn't precisely sure what the test was for, so I added it to my notes.

So off to explore! I know I want to stay someplace in the Selenium system (after all, it's the one I have the most experience with), so looked at the various options that were out there. I found two items that were recommended, and at first thought of using them both. Until I looked at the requirements.

Now, I fully understand why having a testing setup is so valuable, and why resources for testing can be an issue; the list of things to install is a quarter the line count of the program itself! So now get things ready to install (find out what I have, what I need or need to update) and get ready to go.

This is a simple application - you get a question, then push the button to get the answer. For a cat-loving person, this is grand. It isn't, however, going to make money, being very simple and built as a learning project.

So, does this even need automated testing?

Yes, it would be nice to have: to make sure that the chances of it grabbing the identical question twice (or more) in a row is low, and to insure that it doesn't error out when the number of jokes passes the number of possible questions.

But is it a need? After thinking about it for a while, I decided that, in this case, nearly doubling the size of the program just to test this one item wasn't in the best interest of having an enjoyable app. The tests, done manually alongside making sure of the hundreds of other things that might be an issue, didn't add much additional time (overall, less than 10 minutes - excluding writing up the results) and the results were what I was hoping for.

And those results? The app looks good, the cats are cute, and some of the jokes are great. The only automation I did with this (and suggested changes to the owner) were accessibility items that, to me, didn't show - mostly adjusting text size.

So, the tests weren't totally manual - but a tools that is capable of catching these details without fuss, and that was run in the same time that the manual tests were done was a nice addition, and caught things that I would not have noticed.

Manual? Automated? Neither - a day's thought gave me the proper balance of tools and time to do the best possible job, for the highest quality.

Popular posts from this blog

30 Days of Postman - for Testers!

  https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/ Photo by Karolina Grabowska from Pexels   Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results. Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that help
Read more

Where Is It? Part 1 - Inputs

Photo by Pixabay from Pexels     I am job-searching, and running into some coding challenges. Most of them are simple - some seem to want one-line solutions that require two cups of coffee and a half-hour to figure out what they want. Others are far above where my skills lie, and these I give a try for, and learn. And then there are the ones that offer, seemingly randomly, a challenge - within my skills (or at least my research skills) - that could be used as part of a larger project that I want to work on. This was the case last week, when I tried for a position that was a bit above what I felt I could do comfortably. The challenge was to let someone enter items, and then give back their location. In a language I am just familiar enough to be a danger to myself in. Happily, and thinking forward about how I could use this as a part of a larger program that would  use something like this to interact with the user. And also, this is command line, and thinking of how to set this up to
Read more

Do Your Tests Wobble?

Image by delo from Pixabay “The green reed which bends in the wind is stronger than the mighty oak which breaks in a storm.”  ― Confucius  I was asked to pair Blog with Lena Weiberg - much to my shock and delight. This was the perfect opportunity to hear another point of view on something, and share it with the wider community.  ~ Part of being a good tester, to me, is making sure I stay aware of the trends in development. Knowing  how the team is working can help get comments and questions to them at the proper times, and has  the information that can be acted on. In this quest, I attended a recent online conversation where the  topic was primarily on the size of 'steps' taken in software development: making sure each step takes  a reasonable amount of time, that it leaves the system in a state that isn't worse than it was before the  change, and that could - if needed - be deployed at this point.  The concept of “wobble”  (I'm not sure
Read more