Welcome!

Agile Computing Authors: Pat Romanski, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui, Carmen Gonzalez

Related Topics: @CloudExpo, Agile Computing, @DXWorldExpo

@CloudExpo: Blog Feed Post

Four Secrets to Managing Your Testing Workflow By @JustinRohrman | @CloudExpo #API #Cloud

How do we manage the flow of work and keep testers productive?

Four Secrets to Managing Your Testing Workflow
By Justin Rohrman

Take your typical project.

New code appears in pieces - the front end is ready, but the API that front end makes request on isn't even on a test server yet. There is a performance optimization project going on the side.

One tester is dealing with a critical support issue, another is supposed to get a new feature any minute now, and the last is completely blocked.

This is normal life in software testing. Work comes in fits and starts, and is often hard to predict.

How do we manage the flow of work and keep testers productive? Here are a few things that have worked for me.

1. Go beyond test cases
In the past when new feature development was just starting, the daily tester scrum was a steady flow of people saying write more test cases!

Test cases dominated the conversation, and it wasn't just during the start of projects. When testing finally started everyone was running test cases, and probably talking about how many were left, how many had failed, and how many needed to be performed again. The test cases didn't tell us about the quality of the product, and they certainly weren't helping me figure out when I was done testing. The test cases were acting as filler, something to do when we didn't know what else to do.

We can do better than test cases.

That period of time between when a release iteration begins, and the first testable thing is ready is certainly shrinking, but there will always be some delay. Instead of ‘writing test cases' in that buffer, I'd rather contribute as a team member. Test Driven Development (TDD) is growing but is still something practiced mostly by outliers, the developers that really care about their work. The technology stack can be tricky of course, and the underlying premise of TDD is that the developer is actually good at testing.

Testers are professional test designers; those who have done it for over a year with attention are relative experts. That might be intuitive; we might not be able to explain the how or why we picked a certain combination of events to test, but we still have that hunch that proves useful. When I sit with a developer, I usually ask questions in rapid fire - how do you know what the value is at this point? What happens if the user clicks Submit too soon? If this code is changed will it break this -  and at the end leave with a few new automated checks and hopefully a slightly better feature. When there is a build, I go all in, but there is no point when I'm just waiting.

I can already imagine the protests - this will take too long and we'll get fewer features. Maybe, maybe not. You could get fewer features, but they would also be working better on the first try, while training the programmers to improve first-time quality. I have left a sprint more than once using this method with five working and ready to go features, instead of the usual three done and a fourth in a questionable state. Try it out with one person on one feature, and see how it goes.

2. Fix unnecessary blockers
Serious blockers, things that prevent you from working on the project at this very moment, are one of the big reasons iterations get that herky jerky, start and stop feeling. The worst offender is a new build that falls over the minute you look at it - the dead on arrival (DOA) build. At first glance, this might not feel like a testing problem. Surely the test team didn't cause the build to fail or login to throw exceptions. The problem is up-stream of testing.

On small teams, the hardest part of preventing the DOA build is cultural. I worked on a project once where a good week only had two or three DOA builds. On a bad week we didn't get much work done. Developers were working too many hours under too much pressure and things were falling apart. All it would have taken to move forward was the developer checking out the latest code and spinning up the build to poke around a little bit. Nothing too heavy, but enough to see that basic functionality is there.

If you're on a bigger team that is committing code not just a few times an hour, but more like a few times a minute, then grabbing the latest code probably won't do much good. By the time everything is checked out and running, your up-to-date environment isn't so up-to-date anymore.

Having some amount of automated checks running with every build, even on local development systems, can really help in this type of environment. In addition to being able to see when a new change potentially broke something else, you can easily see areas with no coverage and remember to look there for surprises.

But, what if the blocks are mental?

3. Make use of "down time"
The phrase ‘I don't have anything to do' is like nails on a chalk board. There is almost always something that can be done on a project, somewhere I can work in and create value. We testers usually find ourselves in software, but there is a lot more we can do, and people that can be helped, in those rare instances that there is no new software to work on.

  • Product Managers: Product managers are experts at talking with customers about their needs, and turning that vision into something the developers can use as a direction forward. In the past when things have been slow, I like to find those product meetings and start asking probing questions about who will be using the feature and what value they want. Maybe those questions help make a better feature. At a minimum, I walked away with a good understanding of software in the pipeline.
  • Support: Support always has something time sensitive in the works. Sometimes that is a hard to reproduce bug, sometimes it is getting educated about what is in the latest release. The support call and email logs have always been useful for me. I like to look for patterns in questions to guide my testing and add weight to a report. If five people call that need help with some aspect of the product, I can probably find a bug.
  • Documentation: I see documentation less and less. It seems that most companies are moving to SaaS and expect people to just figure it out. When I worked on a heavy weight installed product, the documentation needed to be tested just like the product. Do the new features work the way the docs explain? Are the installer instructions correct, do they actually work? There were always bugs to be found in those pages.

4. Think beyond the short-term flow
A lot of what i have talked about so far - finding waste; getting people past blockers - is geared toward getting people back into the game right now. That is a good strategy when we are worried about the next build, or even the next release, but we have to worry about the months in front of us, too. There are things we can do now that will pay off in the future.

Hopefully you have cross-functional teams, the next step is to develop a culture of pairing.

Two brains are usually better than one, and getting a developer and tester sitting together and working on a feature will have surprising results. I've done this a few times on teams with developers that trusted me.

The general idea was that we happened to both be in the office early when it was quiet and easy to work. I was playing some music and testing a change that made it into the build last night and that developer would ask me if I had a minute. I always did, and that builds trust. I'd roll over to his desk and ask for a demonstration of the change and take some notes about simple things, maybe a button that could be moved or a missing label highlight and then we'd get down to business.

I'd ask questions, like what happens when I add a special character here or forget to populate that field, and then we'd immediately try it out right there in the dev environment.

Sometimes we would find bugs, and I'd go off and do my own thing for a while while he fixed them. Sometimes, we could come up with questions that neither of us knew the answer to and we'd make a note to ask the product manager.

The end result was always knowing more about the feature, and having decent quality before the change made it into the test environment.

The other tool I like to use is strategic automation. This takes time to realize, there are technology stacks to learn, build systems to configure, and then the checks of course have to be written. One team I worked with had a product based on a REST API.

When I joined the team, there was one test against the API that made sure someone could authenticate, but that was it. My first task was to get that running with every build, so if authentication broke in an obvious way, we'd know about it before someone tried to log in.

Over the next few months, I spent time building out API tests in areas the developers were concerned about. I found quite a few problems while building the tests, and one by one they were added to the build system and would throw alarms when something bad happened. Finding out about problems faster helped us get them fixed faster.

Flow is all about smoothing out the ups and downs of software work to find a steady, stable pace to work. There are lots of reasons to work on flow  - maybe you want to know how much software can be delivered in the next couple of months, or maybe you just want to not work your team to death.

Pick a place, smooth it out, and let me know how it goes.

Read the original blog entry...

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

IoT & Smart Cities Stories
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...