Think Like a Tester

Anyone who has ever done laundry has most likely faced the issue where they are folding their recently washed clothes and they discover that they are missing one sock. Sometimes the sock is missing because it never made it into the laundry basket. Sometimes the sock was left in the washing machine. There are even jokes about how the clothes dryer sends socks into another dimension!

What’s interesting is the reaction that people have to the missing sock. Some people shrug their shoulders and figure that the missing sock will turn up eventually. Others will spend most of their day looking for that missing sock: they’ll search through the laundry room, all of the undone laundry, their closet, under the bed, etc.

This is a great metaphor for what testers do when they encounter a strange and hard-to-reproduce bug! Some testers decide that since the bug is hard to reproduce, they should go on and test something else. Other testers decide to devote every moment to finding the cause of the odd behavior, to the exclusion of all other testing. Which is the correct behavior? The answer is: “It depends”. In this post, I’ll list three reasons why you might want to hunt for the elusive bug, and three reasons why you might want to put off the hunt for later.

Reasons to Hunt for That Bug:

When the bug happens, it’s a big deal
You might be testing a system where everything works just fine most of the time. But when the bug occurs, the system crashes, or data is lost, or a customer can’t submit an order. This is a serious problem. Even if the bug happens just 1% of the time, it’s important to figure out what’s going on, because you will lose users as a result of this issue.

The problem is intermittent, but happens frequently
Currently I’m plagued by a bug in some software I’m using. I’m logged into the software, but about 50% of the time the application forgets who I am. This is really annoying. If someone were to ask me about this software, do you think I’d recommend it? If I didn’t need this tool for my work, I’d have switched to something else a while ago. You don’t want your users to give you poor reviews or stop using your application!

The problem hints at an important performance issue
Perhaps your software works just great when you test it with one or two users in your test environment, but you’re seeing strange behavior in your Production environment. Don’t just shrug this off with a “Works for me” statement! This bug could indicate that there is a problem with your application when it’s under load. Perhaps there’s a memory leak that gets worse the longer the application is used. Or maybe the calls to the server are taking too long, and the problem is compounded as more and more calls are made, locking the database. Whatever the reason, it’s important to find out the root cause of the problem and fix it before your customers see it.

Reasons to Save the Hunt for Later:

You’ve been testing for weeks, and you only saw the problem once
We all know that software and hardware isn’t perfect. Strange glitches can happen, including service interruptions in hosting environments, power surges on equipment, and loss of electricity or Internet connection. The bug that you saw just once could have been caused by any one of these things. This is the kind of bug to watch for, but not to chase after. If it happens again, then you can start looking into it.

You’re pretty sure you know the cause already
If you think that the reason why you saw a bug is because a team member forgot to deploy one part of the application, or someone forgot to turn a toggle on, or your test user was deleted; and the bug went away as soon as those things were fixed, then there’s probably no reason to hunt any further.

You are in a time-sensitive situation, and you think the issue doesn’t pose a risk
It’s very aggravating to have a giant bug show up in Production and then hear from a tester “Oh, I saw that bug, but we were in a hurry and didn’t have time to investigate.” But if the bug is something obscure that you think that a user will never do, and you are needing to meet an important deadline, it might be okay to wait until after the release to dig in further.

Here’s an example: a team is trying to release some new search functionality to their application. The team has been testing for weeks and it appears that things are working well. The day of the release, a tester discovers that if she enters a search term with 1000 characters, there is an intermittent bug. Rather than calling off the release and spending hours looking for the bug, the team should probably go forward with the release and investigate later; because it’s very unlikely that end users will be doing searches on 1000-character terms.

Do you have a “missing sock”?
The next time you encounter a strange bug, ask yourself: is this something that should be investigated now, or something that can wait until later? The size of the bug, the frequency of the bug, and likelihood that it will be seen by users can help you decide.

“Clean Code”, by Robert C. Martin and guest contributors, is frequently mentioned as one of the top books that software developers should read. I had been wanting to read the book for years, but I knew that it would require a big time commitment. Since I had a goal of reading one tech book a month this year, I decided it was time to take the plunge and finally read it!

I was fairly certain that I would learn a lot about good coding practices, and I definitely did. But what really fascinated me was the emphasis on testing! The author states that it’s not possible to refactor code well unless you have good tests in place. He sites this example from when he was coaching a team who decided that their test code didn’t need to be maintained to the same standards of the production code:

“From release to release the cost of maintaining my team’s test suite rose. Eventually it became the single biggest complaint among the developers. When managers asked why their estimates were getting so large, the developers blamed the tests. In the end, they were forced to discard the test suite entirely. But without a test suite they lost the ability to make sure that changes to their code base worked as expected. Without a test suite they could not ensure that changes to one part of their system did not break other parts of their system. So their defect rate began to rise. As the number of unintended defects arose, they started to fear making changes…Their production code began to rot.”

As someone who is passionate about software quality, I knew that automated tests were crucial. But I didn’t realize just how crucial they were for simply keeping production code clean and updated!

In one of the main sections of the book, the author gives an example of completely refactoring a parsing tool that he had created. One step at a time, he pulls out arguments from functions and puts them in new functions, creates interfaces to reduce code repetition, and so on. The reason he is able to make all these changes to clean up his code is that he has tests in place! He begins his refactoring by making sure that all the tests pass. Then he makes one change at a time, running the tests after each change. As long as the tests continue to pass, he knows he’s not breaking anything.

Software testers might be reading this review and saying to themselves, “This is great! I’ll tell all my developers to read this book.” While that is a great idea, software testers need to read the book too. Because now that we know that the quality of test code is just as important as the quality of production code, we need to write really clean code as well!

Some of the important clean coding principles outlined in this book are:
• the name of a variable, function, or class should tell you why it exists, what it does, and how it is used
• functions should do only one thing, and they should do it well
• functions should either do something or answer something, but not both
• functions should be read from the top down: if function A calls function B, function B should be listed below function A
• strive to use as few arguments in a function as possible; two should be the maximum
• avoid writing comments as much as possible; the code itself should clearly state what it does through good naming
• standardize on common spacing practices, so everyone’s code looks the same; this will make it easier to read
• don’t leave commented-out lines in the code; either delete them or fix them. The longer they are there, the more others will be afraid to touch them for fear of breaking something, and they will clutter up the code

I learned all this and so much more in “Clean Code”. I recommend that everyone who writes any type of code, production or test, take the time to read this book and put its recommendations into practice.

One of the difficulties of being a software tester is that when you’re doing your job really well, it’s unnoticeable! Unlike software developers, who are creating a product that will then be seen by management, software testers create tests that will help validate that the product is working correctly. When we do a great job, it’s not clear what the difference is between the product that would have gone out to production if we hadn’t found all the bugs, and the product that actually did go out to production.

The problem with not being seen by management is that it becomes difficult to advance in one’s career. Fortunately there are four different ways that we can make sure that our managers and others see the impact we are making.

Tell Them:
Make sure that you are letting your manager know all of the ways you are helping to make a great product. For example, in your daily stand-up meeting, you could say “I found an important bug yesterday in the chat feature that would have kept users from accessing their chat window if it went to production.”

Also be sure to mention whenever your test automation catches a bug: “Our automated regression suite caught a critical bug on the User Info page shortly after the change was deployed to the QA environment.”

Show Them:
Managers love dashboards and metrics. Remember that managers often have their own managers to whom they need to report. If you can make your manager’s job easy by providing them clear data about the quality of your application, they will be very grateful.

For example, you could create a dashboard that shows the pass/fail rates of your nightly regression tests. This dashboard could show the different environments you are testing in, and ideally it should show that the passing rates in your Production environment are near 100% because the automation found the bugs well before the new code made it to Production.

Or you could start keeping metrics of escaped defects: these are bugs that made it to Production without being noticed. Ideally the number of escaped defects will be zero, but even if it isn’t, your metrics for each release can demonstrate that your team is getting better at releasing bug-free code.

Teach Them:
Having lots of great software testing skills is awesome, but what is even more awesome is teaching those skills to others in your company so they will be as effective as you are. Your company probably has a number of different ways that you can teach others testing-related skills. For example:
* Talking about an automated test framework you are using in a departmental meeting
* Leading a workshop for other testers about how to adopt the test framework
* Mentoring a new or struggling tester

Lead Them:
Your manager can’t see you as a leader if you don’t speak up! One great way to lead is to suggest process improvements for your team during your Sprint Retro meeting. When your team adopts those ideas and sees the quality of your product improve as a result, you’ll be seen as a positive change agent.

Setting up a Community of Practice (CoP) meeting is also a great way to stand out as a leader. In the meeting, all the testers at your company can gather together and share ideas and solve problems. If your company already has a CoP meeting, volunteer to lead a discussion or talk about an innovation that your team recently adopted.

Common Objections to Being Seen:
Software testers are often introverts. Many of them enjoy working quietly, testing features and writing automation without much interruption from others. Some prefer not to be the center of attention. It’s OK to feel this way, but it will not get you promoted!

If you are shy or fear public speaking, start out by making small improvements. You could begin by creating a blog post or test dashboard. Then you could try adding one comment in each Sprint Retro meeting. Next, you could volunteer to demo a new feature at a meeting. You can continue to add small steps in this way until you feel comfortable enough to run a workshop.

Final Thoughts:
Software development processes have come a long way in the past two decades; there are very few managers today who don’t understand the importance of software testing. But they may not notice your contributions to your product unless you make sure to be seen. I hope that the above suggestions will help you show your manager what a great asset you are to your team.

It’s been my experience that working with Regex makes everyone’s head hurt. No one wants to have to look at ^(19|20)\d\d[- /.](0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])$ and figure out what it means!

But in spite of that, Regex is a very powerful tool, and it’s good to know how to use it, even if (like most people) you’re not an expert. This post will serve as a very gentle introduction to Regex, so that when you encounter it in your testing you’ll feel more comfortable with it.

The first thing you should know about Regex is that it stands for “Regular Expression”. It’s simply a sequence of characters that define a search pattern. It’s very useful for doing things like editing a string or checking to see if a phone number, date, or postal code fits the accepted pattern.

The second thing you should know about Regex is that it’s a lot easier to use when you have a Regex tester available! I like to use regexpal.com, but there are many other free testers available on the Web.

Regex varies slightly depending on what language you are using, but the basic building blocks of Regex are the same in each. Here are ten different Regex symbols that will help you get started:

^ : The carat symbol indicates that you want to match the beginning of a word. For example, if you were using a pattern that started with ^ball, you could match the word ball or the word balloon, but you could not match the word football, because it doesn’t begin with ball.

$: The dollar symbol indicates that you want to match the end of a word. So if you were using a pattern that ended with ball$, you could now match the word football, but you couldn’t match the word balloon, because it doesn’t end with ball.

. : The period symbol will match any character. You can use this when one of the characters in a string is going to vary. So if you had the pattern foo.ball, you could match football or foosball.

*: The asterisk symbol indicates that the character should be matched one or more times. In the pattern fo*tball, the letter o can be matched one or more times. So with this pattern, you could match fotball, or football, or even foooooooootball.

\d: The slash and d symbol matches any numeric digit. The pattern football\d will match football1, football2, football3, and so on, but not football or football!.

\w: The slash and w symbol matches any character from the basic Latin alphabet. So if you were looking for a pattern of 12345\w, it would match 12345a, 12345b, 12345z, and so on, but wouldn’t match 123456 or 12345!.

\s: The slash and s matches a space. If you had a pattern of foot\sball, it would match foot ball but not football.

[ ]: The square bracket symbols indicate a character set. So if you wanted to match any number from 1 to 5, you could use [12345]. A pattern of football[12345] would match football1, but not football6.

|: The pipe character is an either/or pattern. A Regex pattern of cat|dog will match cat, and will also match dog.

( ): The parentheses group pattern items together, the same way they do in mathematical expressions. Let’s say you were trying to find a match for November or December, but not for September. You couldn’t just use a Regex pattern of ember, because that would match all three months. But you could use (Nov|Dec)ember; using the parentheses combined with the pipe character shows that the month could either have Nov or Dec, and then should continue with ember.

I’ve kept these examples very simple, because there is so much to Regex that you could spend months learning it, and it is very easy to get confused! But these commonly used symbols should be enough to get you feeling a bit more comfortable with it. Take some time to play around with a Regex tester to practice what you’ve learned, and if you’d like to learn more, try an interactive tutorial like regexone.com. Have fun!

The summer after I graduated from high school, I got a job at a discount department store. In my first week on the job, I was trained to use the layaway register. Then the employee who trained me left to work elsewhere. Consequently I was the only non-management employee who knew how to use the register. This made me feel special and important! Unfortunately, it also meant that I got put on 12-hour shifts, and that my lunch break was frequently interrupted, because management needed me to be on that register.

As a software tester or developer, it’s fun to feel like you are the only one who understands how something works! But this is no good for you, or for your company. For example: Bob is the only one who understands the build system. Others can use it, but whenever the slightest thing goes wrong, people call on Bob for help. This means that Bob’s nights and weekends are frequently interrupted by pages, so he never feels like he really gets any down time. Or consider Marge: she is a great software automation engineer who wrote the entire automation test suite. But she is the only one who knows how to run and debug the tests. So when Marge goes on vacation and tests fail, no one knows if there’s something really wrong or if the test is just flaky. This means that sometimes bugs slip out into Production.

It’s great to have specialized knowledge, but make sure you don’t have a monopoly on that knowledge! You need to teach other people to be able to do what you do. Many people object to this idea, saying they don’t have time to teach others. But really, you don’t have time NOT to, because if you don’t you and your product will suffer.

Here are some ways to share what you know with others:

Have someone shadow you
While you are doing that thing that only you know how to do, let someone watch you do it and ask questions. The more they get their questions answered, the more they will understand the process.

Have a group training session
Create a presentation that will show people what you do and how you do it. You can even give them some hands-on activities to practice what they are learning. And if you record your presentation, you’ll be able to teach people in the future without doing a thing!

Do one-on-one training
If something is so complicated that you think you can only train one person to do it, set aside a big block of time to train them. But once they are trained and have proven that they can do the job, make sure they train someone else, because the more complicated something is, the more important it is that several people know how to do it.

Write good documentation
Sometimes leaving clues in the form of really good documentation can be helpful. If you are good at writing directions, you can create a step-by-step process that anyone can follow. One caveat to this suggestion, though, is that software changes rapidly; instructions that are outdated will just serve to frustrate people and make things worse, so make sure to keep your documentation up-to-date.

Let someone else do the job while you are watching
There’s no substitute for having someone try something out themselves, encounter a problem, and figure it out on their own. If you are nearby, you can watch what they are doing and only step in and help if they really need you.

Let someone else do the job while you are elsewhere
Once your trainee is starting to feel more confident, have them do the task while you are off doing something else. Don’t go on vacation, though; be available to help if something goes really wrong.

Having a special skill can be a source of pride, but don’t try to hoard that skill! You’ll make your team better by training others to do what you do. And you may become even more skilled in the process!

As any regular reader of this blog will know, this year I’ve been reading and reviewing one testing-related book a month. Well, I’m cheating a bit this month! I’m currently reading a very long book that I knew would take me two months to read (Want to know what it is? Check back in with me in four weeks!), so this month I’m reviewing a book that I read a couple of years ago: “The Way of the Web Tester” by Jonathan Rasmusson.

“The Way of the Web Tester” is the book I recommend for manual testers who want to learn the basics of automated testing. It’s a friendly, accessible book that gives readers both the “big picture” about automated web testing and the details about how to implement it well.

The book is organized in two parts: Part I describes the basics of how automated testing works, and Part II is devoted to helping people who are new to programming understand good coding techniques.

In Part I, the author begins by explaining the automation test pyramid, and then describes each level of the pyramid from top to bottom. He begins with the top level of the pyramid because that’s the most accessible to manual testers, and this idea makes a lot of sense; when you’ve been testing a system by going to the web page and clicking buttons, it’s easy to transition to automation that goes to the web page and clicks buttons!

The author then moves to integration tests, explaining how HTTP and REST requests work, and then to unit tests. Finally, he gives examples of how the all the tests can work together to test an entire system. I really like how he emphasizes that developers and testers should be working together to create test automation, so that work isn’t duplicated.

My favorite part of Part II is the Programming 101 chapter, where important practices such as choosing good variable names, spacing code, and using the DRY (Don’t Repeat Yourself) principle are discussed. These are so valuable to people who are new to coding.

Another thing I love about the book is the use of two cartoon characters. They are “Tim the Tester” and “Diane the Developer”, and they pop up throughout the book, asking questions that the reader might be wondering, such as “How do I know if I’ve written enough tests?”

If you are new to automated testing, or if you’ve struggled with it in the past, “The Way of the Web Tester” is definitely a book you will want to read. But it’s not just for beginners! I learned a number of things from the book as well, such as how mocking works and how to write unit tests that test UI elements. It’s a great, easy-to-understand book for anyone who’d like to make their test automation more robust.

Recently, I took this great course on Locating Web Elements from Andrew Knight, through Test Automation University. In addition to learning helpful syntaxes for accessing elements, I also learned about yet another way we can use DevTools to help us!

One of the most annoying things about UI test automation is trying to figure out how to locate an element on a page if it doesn’t have an automation id. You are probably aware that if you open the Developer Tools in Chrome, you can right-click on an element on a Web page, select “Inspect” and the element will be highlighted in the DOM. This is useful, but there’s something even more useful hidden here: there’s a search bar that allows you to see if the locator you are planning to use in your test will work as you are expecting. Let’s walk through an example of how to use this valuable tool.

Let’s navigate to this page, which is part of Dave Haeffner’s “Welcome to the Internet” site, where you can practice finding web elements. On the Challenging DOM page, there’s a table with hard-to-find elements. We’re going to try locating the table element with the text “Iuvaret4”.

First, we’ll open DevTools. The easiest way to do this is to right-click on one of the elements on the page and choose “Inspect”. The Dev Tools will open either on the right or bottom of the page, and the Elements section will be displaying the DOM.

Now, we’ll open the search bar. Click somewhere in the Elements section, then click Ctrl-F. The search bar will open below the elements section, and the search bar will say “Find by string, selector, or XPath”.

We’ll use this tool to find the “Iuvaret4” element with css. Right-click on the “Iuvaret4” element in the table, and choose “Inspect”. The element will be highlighted in the DOM. Looking at the DOM, we can see that this is a <td> (table data) element, which is part of a <tr> (table row) element. So let’s see what happens if we put tr in the search bar and click Enter. It returns 13 elements. You can click the up and down arrows at the side of the search bar to highlight each element found. The first “tr” the search returns is just part of the word “demonstrates”. The next “tr” is part of the table head. The following “tr”s are part of the table body, and this is where our element is. So let’s put tbody tr in the search bar and click Enter. Now we’ve narrowed our search down to 10 results, which are the rows of the table body.

We know that we want the 5th row in the table body, so now let’s search for tbody tr:nth-child(5). This search narrows things down to the row we want. Now we can look for the <td> element we want. It’s the first element in the row, so if we search for tbody tr:nth-child(5) td:nth-child(1) we will narrow the search down to the exactly the element we want.

This is a pretty good CSS selector, but let’s see if we can make it shorter! Try removing the “tbody” from the search. It turns out the element can be located just fine by simply using tr:nth-child(5) td:nth-child(1).

Now we have a good way to find the element we want with CSS, but what happens if a new row is added to the table, or if the rows are in random order? As soon as the rows change we will be locating the wrong element. It would be better if we could search for a specific text. CSS doesn’t let us do this, so let’s try to find our element with XPath.

Remove the items in the search bar and let’s start by searching on the table body. Put //tbody in the search field and click Enter. You can see when you hover over the highlighted section in the DOM that the entire table body is highlighted on the page.

Inside the table body is the row with the element we want, so we’ll now search for //tbody/tr. This gives us ten results; the ten rows of the table body.

We know that we want to select a particular <td> element in the table body: the element that contains “Iuvaret4”. So we’ll try searching for this: //tbody/tr/td[contains(text(), “Iuavaret4”)]. We get the exact result we want, so we’ve got an XPath expression we can use.

But as with our CSS selector, it might be possible to make it shorter. Try removing the “tbody” and “tr” from the selection. It looks like all we need for our XPath is //td[contains(text(), “Iuvaret4”)].

Without this helpful search tool, we would be trying different CSS and XPath combinations in our test code and running our tests over and over again to see what worked. This Dev Tools feature lets us experiment with different locator strategies and get instant results!

As you have read in my previous posts, I’ve been taking this amazing course on Node.js. I have found that deeply learning a coding language has really helped me in my testing. In previous years I had learned just enough of a language to get by; now I see the value of really understanding a language!

One of the fun things I’ve learned in this Node.js course is the concept of default parameters. When we create a function, we usually include whatever parameters need to be passed into the function, like this:
const greeting = (name, hometown) => {
console.log(‘Hello, ‘ + name + ‘! How is the weather in ‘ + hometown + ‘ today?’)
}

Then when we call the function, we need to include arguments for those parameters in order for the function to run:
greeting(‘Kristin’, ‘Boston’)
and we’ll get this response:
Hello, Kristin! How is the weather in Boston today?

But what if you’re going to use this function a lot, and most of the time you’ll be passing in the same arguments? Won’t you get tired of typing in those arguments every time?
This is where default parameters come in!

When we create our function, we can set one or more parameters to have a default argument, like this:
const greeting = (name = ‘Kristin’, hometown = ‘Boston’) => {
console.log(‘Hello, ‘ + name + ‘! How is the weather in ‘ + hometown + ‘ today?’)
}

Now we can call the greeting function without passing in any parameters:
greeting()
And we’ll get this response:
Hello, Kristin! How is the weather in Boston today?

If we want to set the first argument to something different, we can call
greeting(‘Joe’)
And we’ll get this response:
Hello, Joe! How is the weather in Boston today?

If instead we want to set the second argument to something different, we can call
greeting(undefined, ‘Seattle’)
And we’ll get this response:
Hello, Kristin! How is the weather in Seattle today?

Or we can decide to replace both arguments, by calling
greeting(‘Joe’, ‘Seattle’)
And we’ll get this response:
Hello, Joe! How is the weather in Seattle today?

It’s really very simple once you see how it works. Think about how many times you’ve gotten tired of typing the same thing over and over in your code, and how many times you’ve accidentally missed a single quote or a comma. Typing () without having to fill in any arguments can really save time over the long run!

Anyone who works in the Software Industry knows that at some point they will need to cope with change. Consider the move from desktop computers to laptops, or from BlackBerry devices to iPhones. We all want advancements in software, but sometimes that means that we will need to change what we do. Have any of the following stories happened to you?

• You are the sole QA Engineer on a software team, responsible for testing everything the developers create and writing test automation. Now your manager is telling you that the whole team should own quality, and that the developers will be testing each other’s work and writing automation. Your job is to the be the Quality Coach.

• You have written UI automation for years, and your product has hundreds of UI tests. But there is a new policy that says you can only run a single end-to-end UI test, and the rest of the tests should be unit, integration or API-based.

• You are a Selenium champion; you know how to locate even the trickiest elements. But your company has decided to support Cypress instead. You have always written your tests in Java, and you don’t have any experience with JavaScript.

It’s hard for everyone to deal with change! In this post, I’ll outline seven steps for dealing with the inevitable changes you’ll encounter working on a software team.

Step One: Don’t panic
This step is good advice for practically everything. While it may seem that the changes on your team are cataclysmic, and you won’t possibly be able to adapt, remember that changes usually don’t happen overnight. You will have time to learn whatever new strategies you need to deal with the change.

Step Two: Have a (very short) pity party
Often the changes that are thrust upon us are not changes that we agree with. We may think that our company is going in a terrible direction, but our warnings have gone unheeded. Whenever a change happens that I’m not happy with, I take 30 minutes to an hour to pout about it. I feel really sorry for myself. Then I tell myself that there’s nothing I can do about the change, and that I need to begin to move on and adapt. Taking some time to mourn can give you the emotional energy to move forward.

Step Three: Set an achievable goal
One thing that can really help us cope with change is to set a goal to work towards. It gives us a feeling of control and something that we can look forward to. In the case of the third example above, a person who is a Selenium expert can set a goal to take a course on JavaScript or Cypress in the next month. As you gradually learn something new, you’ll feel more like you can cope with the change.

Step Four: Do a little at a time
Remember that change doesn’t happen overnight. Moreover, you’ll still likely have your usual work responsibilities while your organization begins to change. Set a goal for yourself to work just a few minutes a day on learning a new skill, adapting an existing test, or trying a new strategy. Little changes each day can add up to big results.

Step Five: Use the magic of the Internet
When I was first learning test automation, there were very few resources out there to help me learn. Things are SO different today! Whatever you need to learn, I guarantee that there is a course out there that can help you learn it. And if you don’t like the course you’ve found, you can find a new one that works better for your learning style. Consider using Pluralsight, LinkedIn Learning, Udemy, W3 Schools, or Test Automation University, to name just a few great learning sites.

Step Six: Ask for help
Sometimes people in technology feel that they need to be seen as knowing everything. This is so dangerous! The best coders and testers I’ve known are the ones who ask lots of questions, and who aren’t afraid of looking silly for not knowing something. When I ask a question in a technical meeting, nine times out of ten I find that most of the other people in the meeting were wondering what the answer was themselves, and they were just too timid to ask.

One caveat to this step, however, is that you should always try answering questions and solving problems yourself before asking for help. Don’t be that person who gives up and says they can’t do it on the first try! If you work on a problem on your own for a while, you may find that you can arrive at the answer yourself, which is a great confidence-builder.

Step Seven: Buddy up
No one works in a vacuum! We are part of software teams so that we can help each other. If you learn best by learning with a group, assemble a group of people who need to learn the same thing that you do and work together. This is especially helpful when you are learning a new coding language. People can share the problems they’ve solved so that no one has to “reinvent the wheel”.

The one thing that’s constant in life is change. By applying these seven steps, you’ll be able to cope with any change your company or team presents you with.

As you know, I’ve been reading one technology book a month and reviewing it in this blog. For the month of September I read “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” by Nicole Forsgren, Jez Humble, and Gene Kim.

You may have heard of this book, because it has become an industry standard in the discussion of how teams can deliver quality software more quickly. After reading the book, I see why it is so well accepted.

Part I of Accelerate consists of the findings of the authors based on a worldwide survey they conducted of software teams. They performed statistical analyses on the results and arrived at the following conclusions:

• High-performing software teams have:
  – more frequent code deployments
  – faster lead time from commit to deploy
  – faster mean time to recover from downtime
  – a lower change failure rate
  
• There is no tradeoff between improving performance and achieving higher levels of stability and quality- you can do all three!

• Teams can improve their performance, stability, and quality by:
  – creating comprehensive test and deployment automation
  – setting up continuous integration
  – shifting left on security (meaning, testing security while features are being developed)
  – managing test data
  – using loosely coupled architectures
  – working independently (able to deploy without being dependent on other teams)
  – using version control on everything, including build scripts

Part I is really the meat of the book. You can read this part and get what you need to know about creating a high-performing software team.

In Part II, the authors dive into the details of the research they did, from choosing the questions, to finding the people to survey, to using statistical methods to analyze the results. I think you can safely skip this chapter unless you are doubtful of the validity of the results in Part I.

Part III contains a chapter with two guest authors who are lean IT practitioners. They describe what a banking institution’s software development team looked like after they had adopted the strategies in Part I. I was a bit confused by the jargon they used and put off by some of the irrelevant details (for example, what the office space looked like- not particularly important in 2020 when so many teams are working remotely!).

Finally there are three appendices. Appendix A consists of a summary of Part I, which is really helpful if you want quick access to all the ideas. Appendices B and C discuss the statistics and statistical methods used in analyzing the survey data. You can safely skip these sections unless you are a statistician.

Accelerate is a great book for anyone who wants to help their organization deliver quality software quickly. If you are trying to make changes to your team in order to implement CI/CD practices and your manager is resistant, I highly recommend giving them this book. It’s clear from the survey results that the strategies outlined here will help teams become high-performing.