I am active on a number of social media sites and writing platforms. This quick article will highlight a few of the additional articles I have written for other platforms and how to follow me on social media. That way you can stay current on what I’m working on and testing discussions.
Over the past year, I have written a few articles on LinkedIn revolving testing and balance. I recommend taking a look at them if you like what I have written here. Below are links to articles I have written for LinkedIn, DZone.com, and Testlio’s company blog.
I had hit a wall, my test automation was taking over 5 hours to run and I wasn’t sure what I could do to bring that time down. I knew that there were environmental issues that were slowing down my tests. Around two hours in the number of page timeouts jumps up to nearly 50%. WebDriver has never worked well with test environments that were extremely under powered, but there was more to it than that. This was a sudden jump in time of execution and timeouts.
Eventually we found the problem, but after all the research, I wanted to loose my head.
I was knocked out! I was asked a question about API testing and I was mentally knocked out. While I have tested APIs before, I have been focused on front-end testing lately. The last time I did it in an automated fashion was as a proof of concept. At that moment, I realized I have been focusing on front-end test automation too much and I really needed to brush up on my back-end testing skills.
It is easy to let your regression suite get out of hand. We tend to throw every test case we create in the regression suite. It is a test case dump yard for everything test we create that isn’t in the smoke test. We want to make sure everything works as expected before each release. When we do this long enough, we end up with thousands of test cases.
Before you know it, your regression suite is a forest, when you only need a few trees. There has to be a better way.
Test cases are the keystone of the QA house. Test cases document functionality of the applications we test, training material for new team members, and the building blocks of our test plans. With them we can demonstrate and clarify what we are testing during our regression and production test runs. Without them the following problems arise:
When your test automation is running fine, everything is great with the universe!
Then it happens. A test cases fails and your trace isn’t entirely clear as to where it failed. Even when the trace is clear, you still have to walk through the test steps to capture a screenshot for the bug. Imagine being able to capture screenshots at the moment of failure.