With technology such as self-driving cars, trains that don't require train conductors, and emulating the movements for Pokemon Go a few years back - Software truly can do anything. This includes the development of software that tests software! Imagine having to do a test repeatedly, that would remove the humanity in our job, so we automate stuff. Test automation is an extremely exciting idea that holds great promise. However, we must be mindful, automating some testing maybe helpful in saving time, however, it can also be not helpful
Below are a few things to consider when automating:
What is your mission?
In this post, I describe the tester being the light in the dark. For this sprint, ask yourself and your team - What are your goals? Next, set the objectives. In the last week, I had a few hours downtime so I could automate a few things, time I never seem to have these days, which I thought was amazing. Then BANG! out of nowhere, I had to do some testing to ensure that certain functionality of the platform is working. As the tester, I understand that I need to what is the most important thing at the current time. There is no point in doing some automation if it does not help with the current mission.
Your investment in test automation is valuable depending on your current mission - Do you need to get something tested by tomorrow and it takes 1 day to test and another day to automate, is it worth it?
Use automation when it advances the mission of testing. Evaluate your success at automation in terms of the extent to which it has helped you achieve your mission - James Bach, et al
Start test automation early
Test automation is a challenge - it requires planning, research, design, and time. If one of your missions is to automate testing, start while the product is still being designed, while the test cases are not that plenty. Similar to life, in testing, you will come across issues to automate effectively. The way you design your tests and solutions will result from trial and error as every company has different products, there is no one-size-fits-all answer.
I have found that programmers are open to suggestions of what to test all the time. In whatever part of the testing project, I would suggest just having a few minute chat with the programmer asking them about their day, how their project is going, if there's any changes that have not been documented.
I have found that in most projects design is always influx. The programmer and product manager can put them on a schedule and budget and plan for them. However, there will always be uncertainties of the overall design. Ensure that as the tester, testing is part of every part of the process, talking to the programmers about what to test gives them confidence that what they create will be tested well and ensure that your relationship with them is as close-knit as possible.
Test Automation for instant impact
Too many people think that test automation means automating manual testing and an overemphasis on regression tests. Think of it in a different way, Automate things that will be used for the next release.
Here is an example, Let's say you have 3 sections in your product - Section 1, Section 2, and Section 3. Section 1 will have include a few changes to the interface and some changes to how some functionality interact with each other. It is smarter to automate Section 1 of the product than to automate Section 2 as it may most likely not have any changes.
One of the things I am grateful for is never have enough time doing something. This is a good problem and now we need to ask ourselves, "What am I meant to do now?"
- List down things I have to do
- Rank them based on my current mission (Critical, High, Medium, Low)
- Sit down with the product manager to ensure that priorities are aligned
Once you have sat down with your manager, you will now have a list of things that you have to do in priority. This is extremely important, you will onyl do the tasks that are most important during that moment in time. One project maybe important one day but the next it is not important at all. Understand, if you do unimportant things, a deadline for a project may be missed.
Short and snappy reports
In anything you write, make a conscious effort to condense your words in less than 200 characters. Similarly to how you write a bug report, the summary line is the most important line. No one is going to read a few pages of detailed reports. There are only so many hours in a day, no one has time to wade through pages of words. Aint nobody got time for that.
Larry Page of Google mentioned that his co-workers now that sending him anything that is much longer than 160 characters (a tweet) increases the likelihood of him not reading something. Testing is a service - we want to capture someone's attention in writing.
A good automation test summary gives the reader enough information to help the reader decide whether to read more into the report or not. Here is an example of reporting that I use:
Header [Test Suite Name]: Number of Tests Passed - Number of Tests Failed
- Section 1: [Test Suite Description]
- Section 2: [Failed Tests Name]
- Section 3: [Passing Tests Name]
- Section 4: [Action] - What action is needed with the information on the tests that failed and tests that have passed?
- Understand your mission - Knowing what your goals are and what objectives you need to do to achieve those goals are important to ensure that you are contributing to the mission.
- Start your automation early - Do not automate when the product is complete, automate when little parts have been completed to not overwhelm yourself with the amount of testing required for future releases.
- Automate for instant impact - Automate the most important things, what part of the product will have changes for the next release? Automate that first.
- Report your findings - Provide information for the status of the product to the team to ensure that everyone is on the same page. This will allow the team to decide on what the next steps are.