How to Streamline Testing

How to Streamline Testing

How do you maintain the quality of your software while making your testing efforts more efficient?

Back in my first post, I lamented the way that testing and code quality seemed to be little more than lip service in my prior employment experience and how I strove to change that perspective at my current company. I am very lucky to have the opportunity to attempt these changes and I feel that there have been many successes. Yet even with that opportunity, one thing doesn’t change: there is SO MUCH that needs to be done. So how do you maintain the quality of your software while making your testing efforts more efficient? Spoiler alert: there is no silver bullet. However, here are some things that help us streamline testing.

Planning

Having a plan for testing is essential to help streamline the process. It can be as informal as a checklist or as detailed as a complete list of tests, but defining the direction and scope of testing ahead of time is a huge time saver. You may want to see if there are some more efficient test automation tools that can be of use for this project and future ones too. It could help you streamline the process and get the results you need. Beware of putting too much effort into planning. The amount of planning should match the impact of the work. There is nothing more important than time, and spending thirty minutes filling out test planning paperwork for a ten-second test kills productivity, enthusiasm, and momentum.

Pull Requests and Code Review

Testers should be looking at the changes made to code, attempting to understand those changes, and asking questions when they don’t. This will help confirm if the test plan is accurate or needs revision prior to testing. It will establish a dialogue with developers that can reveal updated or missed requirements that can lead to unnecessary delays in testing. As testers and developers build their relationships, testers improve their code understanding, which in turn improves their understanding of what and how to test.

Regression Testing First

As with planning, not every test effort will require regression testing. But when regression testing is part of the testing plan, do it first. That way, if you find that something that previously worked is broken, it’s as early in the process as you can make it. Too often, a majority of the testing time is spent testing the changes first, and then regression testing is done. This approach usually means that regression testing is short-changed. If regressions are found late in the cycle, there may not be enough time to correct them before release, leaving product owners no choice but to “accept” them to get their new feature released according to their timelines.

Multiple Testing Environments

This might seem obvious, but it’s surprising how frequently companies only have one, or even just part of one, test environment. Here’s a good return-on-investment (ROI) exercise to support more than one testing environment: If important (and potentially revenue-generating) features are delayed because they are stuck in the testing queue, do the investigating and find out how much the “delay” is “costing” the company to help make your point. Having the ability to test in parallel reduces queue time and time spent in test set up and context shifting. Even a partial second environment can have a significant impact on streamlining testing.

“Tetris-ing”

Yes, this is a reference to the 80s block stacking game, but the analogy is valid. This tactic is most beneficial when you have more than one test environment, but it could still apply if you have just one. Not every feature will require a complete environment for testing. This is especially true for systems that have both front-end and back-end components. Identifying those features that do not require an end-to-end test environment and deploying them simultaneously means that two (or sometimes more) features can get tested at the same time. And as above, parallelism streamlines testing.

“NOT” Testing

(Unconventional Testing)

Production Testing – Don’t shake your head like that. Read a bit first. This may not be possible for some companies, but for others, it should be seriously considered. Testing takes time and time is money. All testing has a cost that should provide a “Return on Investment”. If the risk is very low, it can be more cost-effective to roll out a change to a single production machine, a small group of production machines, or the whole system and then monitor the effects than to configure a testing environment and run tests. An example would be an ETL query that has been modified to include or exclude a type or status in the result set. In addition, you can eliminate the need to run costly join queries or track down data between sources with a reverse ETL query. New integrations and Proof of Concept (POC) work also fall into this category since the work is essentially “on spec,” with the expectation that it will provide benefits in the long run.

Over-The-Shoulder Testing – Or you could call it “Developer-Tester Peer Testing”. Test environments don’t always have the resources that production environments do, especially for data heavy jobs. When this is the case, we often do a one-on-one code demonstration, where the developer walks through the existing and updated process(es) with the tester and must provide before and after data, either to show that it hasn’t changed, or that it has changed according to the new requirements. This type of testing should be planned, and the tester should posit various use cases, scenarios or possible issues (missing data, bad data, no connection, no directory, etc.) and the developer should be able to show or demonstrate the code that addresses them. This type of testing is where developer-tester relationships are built.

Developer Testing – And before you start yelling: no, I am not advocating or in any way suggesting that developers can replace testers. But testers should realize that good developers do test, and great developers test a lot. They write unit tests, they generate files and do differentials on the outputs, and they validate data inputs and outputs. And if a tester doesn’t know that those tests were performed, they will test them again. This is a duplication of effort. We advocate developers documenting their unit tests and any testing they’ve done, so instead of repeating those tests, testers “validate” them. Or they can “reject” them (after a discussion) if they feel the testing doesn’t cover what was planned. They then perform any additional planned tests (like regression tests). The objective is to reduce the duplication of testing effort.

Automation

Or more accurately, testing with tools. All testers use tools to test. Some use more complicated tools than others. Look for opportunities to remove manual and repetitive test operations, whether it is generating test data, validating test data, or full-blown automation suites. If you are making your first foray into automation test suites, resist the urge to begin with your user interface, especially if it’s is evolving. You’ll end up spending more time maintaining tests than using them. Instead, look to validate your APIs and other backend systems. The initial investment is more, but the longevity and robustness of your tests will provide a much better ROI.

Central Library

In our business, we have many customers making requests and receiving responses from us. Most use a standard format, but quite a few need custom requests, custom responses, or both. We maintain sample requests and expected responses in a central area. Developers, testers and even account managers use these samples to either baseline existing code before making changes, verify that code changes haven’t negatively affected expected responses or for troubleshooting. Having a central repository saves time and reduces duplication of data. Your business may also have common data or processes shared by many groups and could benefit from a central repository.

Test Management System

This is an extension of the central repository idea that is specific to testing. We use a test management system to house all of our tests, whether automated or manual, in one location. Tests can be curated and grouped by descriptions and keywords to map to coverage areas. This means that regression testing can be limited to only the areas affected by the changes under test rather than running a complete regression every time. One copy means only one place that tests need to update when features change and only one place to look when searching for test documentation with new team members.

The examples above all have one or more common threads: return on investment (ROI – or as I like to ask, “Is the juice worth the squeeze?”), reduce or eliminate duplication of effort, and pragmatism. It also offers employees ways to embrace many of the concepts mentioned in my previous post on the Quality Mindset, including heightening awareness, extending and encouraging trust and ownership, and accepting risk. Each company’s needs and circumstances are different, so feel free to change up what you’ve read here or to use it as a springboard to come up with your own method of streamlining your testing.

To Have A Quality Mindset, You Need A Quality Environment

To Have A Quality Mindset, You Need A Quality Environment

In Part 2 of the Quality Series, why a Quality Mindset requires a Quality Environment…And how to build it.

Karl Hentschel

“Quality is never an accident. It is always the result of intelligent effort.”

– John Ruskin (1819-1900)

“Quality is not a consequence of following some set of behaviors. Rather, it is a prerequisite and a mindset you must have BEFORE you decide what you are setting out to do.”

– Edwin Catmull (1945- )

In my previous post, I explained how Bidtellect envisioned changing “Quality Assurance” from a step in the software development process into a shared Quality Mindset. But a Quality Mindset requires a Quality Environment in which to work. The quotes above led me to many books, two of which, Good to Great by James C. Collins and Creativity, Inc. by Edwin E. Catmul, were instrumental in helping define a quality working environment.

A quality work environment could be instrumental in increasing the productivity of your workforce. Starting from the onboarding process to the beginning of an assigned team project, your employees should feel valued and accepted in their workspace. Adopting the culture of co-working spaces could be a great idea to encourage inclusion. This could be a plausible option for those planning to start a new business or a non-profit organization. There are various companies like Ethical Property (ethicalproperty.co.uk) that tend to provide quality workspaces. However, the concepts below are intended for everyone in a company, but are especially intended for company leaders. Note that I didn’t say “manager” or “coordinator” or “director” (although it really helps if leaders with those titles buy-in to the quality work environment concept). Company leaders are the people in your organization to whom others look because they get the work done.

1. Develop and Support Competence

This may seem like a no-brainer, but in order for people to have a Quality Mindset, they need to know what they’re doing. That means, they either bring experience to the company, the company provides experience to the person, or a combination of the two. For instance, let’s say you require the services of a plumber to fix an issue with the pipes in your house, and you hire Royal Flush (you can read more here) as they are considered the best. What makes you choose them in particular? The reason being, you needed a service that lasted for longer and did not require constant re-calls. In a similar vein, when hiring someone for the company, keep your long-term goals and the quality they can help you achieve in mind. Don’t ask a plumber to build a brick wall or a mason to wire the lights, unless you plan on training them properly.

2. Model Discipline

But not the kind you’re probably thinking of right now. I’m talking about internal discipline, not external discipline. Not a manager, a director or vice president enforcing rules, but rather individuals doing the work to the best of their ability. (Notice I said “work”, not “job”. This is important for later.) Discipline is (and should be) a modeled behavior and takes the form of disciplined thought and disciplined action.

3. Extend and Build Trust

Disciplined people, engaging in disciplined thought and taking disciplined actions don’t need to be managed. They will do what needs to be done without needing to be told, if you trust them to do it.

4. Extend and Encourage Ownership

Ownership and trust or kind of “chicken-and-egg” because each fosters and reinforces the other. I have a standing rule for my Quality team: You don’t have to ask permission to take responsibility. Responsibility doesn’t necessarily mean you will do the work, but it is expected that if you take ownership, you are responsible for ensuring it gets done. This ownership isn’t limited by your “job” but rather the work that needs to be done.

5. Heighten Understanding

A leader is responsible for heightening people’s awareness of what they do not know. Do not confuse this with competence (although for junior people, it may by applicable). This is more about making people aware of what occurs outside of their competencies. Get people thinking about “the company” as a whole, rather than just the testers or the developers or the technology team, etc.

6. Show (Frequent) Appreciation

Appreciation is often regarded as a leadership responsibility and it most certainly is. But that doesn’t mean leaders are the only ones who should recognize individual or group accomplishments or appreciation for hard work, diligence or tenacity. They should model appreciation and encourage it amongst team members.

7. Clear Obstacles

Bureaucracy is a reaction to incompetence and lack of discipline. It is a leader’s responsibility to get the right people, facilitate the right chemistry, and develop and support them. Once they engage in discipline and take ownership, the controls can be loosened and the bureaucracy decreased or removed.

8. Accept Risk

… and with it the mess it creates. If you trust your people and allow them ownership, there will be times when they will get it wrong. You should NOT be looking for ways to keep people from making mistakes. A true leader will enable people to resolve problems WITHOUT BLAME. This reinforces the trust and ownership (above) and KEEPS FEAR AT BAY. People who are afraid they will get blamed, afraid they will become unemployed or afraid of ignominy DO NOT trust or take ownership…nor do they create their BEST work in the end.

Read More on the Bidtellectual Blog

Cookieless? We Got This.

Cookieless? We Got This.

How Bidtellect’s contextual tools set you up for success in the cookieless future.

Follow Us