A Short WFH Primer

I admit that when I started working from home, it seemed like a break.  It also provided my wife some peace of mind knowing that one day per week (usually Friday), I was home with the kids.

For the first few times, I realized I didn’t have to be “in the office” until 7 AM so I could sleep until almost 6:55 and still make it “in”.  By the time I had breakfast, I probably wasn’t all that available or effective until 7:30 or later.  Also, I felt sluggish throughout the day.  I needed to try something different.

On my next WFH day, I did what I usually do: I got up early to exercise, showered, and ate breakfast.  I felt more ready when I “arrived” and more awake during the day.  As I grew into this, I found the speaker and microphone on laptops suck.  Having a headset or puck helps me hear the conversation better, and they can understand me.

Do I take breaks?  Yes!  After a meeting, I might go up and down the stairs a few times, or go get the mail.  Were I at the office, I would normally walk somewhere to get water, collaborate with a peer, or oblige nature calls.

By treating the experience as I would for any other work day, I found I was just as effective when Working From Home.

The Decline of Civil Conversation

Perhaps I’ve been in too many meetings but I would like to call a truce on conversation artifacts such as frequent interruptions, unanswered questions, and inattention.

I generally wait for a lull in a conversation to add new information or ask a clarification.  When someone else is speaking, I practice some active listening or I take a note.  Mostly, I wait.  What I’ve noticed is someone will be talking or I will be talking and someone interrupts.  Blatantly interrupts.  Sometimes they want to clarify something or add their information.  I welcome it but an interruption seems rude.

Many times the conversation is going along and someone asks a question.  I would expect a short period of silence as everyone considers the question and a response.  What I’ve noticed is someone will start speaking about the same topic or another topic apparently clueless that a question had been posed.  I want to hear what they want to say but many times I want to hear an answer to the question.  An unanswered question feels like friction to the conversation.

Lastly, during those lulls or short periods of silence, someone looks up from their laptop and begins talking about a topic already covered or asking a question already answered.  This is exceptionally frustrating and takes time to provide the information they missed.

I blame social media for these annoying artifacts.  Anyone can post an update on social media sites at anytime and this practice may be carrying over into everyday conversation.

Listen twice as much as you speak, consider questions carefully, close your laptop unless you are reviewing a shared screen.  Enjoy a topic, collaborate, and move your conversations forward faster.  Who knows, it may even shorten your meeting!

Challenging Questions – 1

The challenge becomes one of changing the question from

Why would we need a tester at this design meeting?

To

Why isn’t the tester invited to the <any product discussion> meeting?

 

Testing as an Advocacy

When you work in testing long enough, you develop or adopt positions on many aspects of testing.  Some positions may be influenced by your environment, some by your peers (respected and otherwise), and some by practice.  Work in testing longer and you may want to share your positions and occasionally encourage others to adopt them.  We see this with testing models or techniques, testing schools of thought, and testing automation.  I believe it is testing positions and the varied interpretations, discussions, and debates that makes the craft a satisfying career choice.

I believe it is becoming something more.

With the introduction and practice of agile methodologies (Scrum, DevOps, et al), the practice of testing inside those methodologies has grown in importance.  Testing must not “wait until the end”, or plan large testing events “after the code is deployed to the test server”.  Waiting impedes project pace by time spent waiting and by discovering defects that were in the code while we were waiting.
The demands of business are driving the adopting of CI/CD and testing can not only help with that, it can drive it.  Testing must drive project pace and to drive project pace, we must become advocates.

Testers advocate for testability, shift left, and buying more than building.

Testability
Testers must advocate for testability in requirements and designs.  Testing can no longer afford to wait for information.  Rather, it must influence requirements for a single clarity and collaborate with team members to share that clarity.
Additionally, testers must actively participate is product designs (high level and detailed) to influence them for testability.  Request the design be transparent with key information and behaviors by using some form of logging, and request the design be controllable by having the ability to mock product objects.  When a product has good testability, it easier to test and can be tested earlier and quicker.

Shift Left
Testers must advocate for Shift Left.  Shift Left encourages new and changed products be evaluated closer to construction.  In many cases, this means more unit tests and deeper unit tests.  In some cases, the unit tests become the regression suite that can execute at any time.  Regression no longer need occur at the end of development!  We need to know as soon as possible if a recent change has impacted the application.
If much of the testing is shifted left, what do testers do?  They are reviewing the unit tests and suggesting more, they are exploring risks, and they are exploring environmental dependencies such as security, configurations, and connectivity.

Buy More Than You Build
Testers must advocate for buying tools and utilities rather than requesting them be built.  There are certainly many cases where building a tool or utility makes sense.  For several other cases, buying tools and utilities can get testers testing quickly.

I believe by advocating some or all of these ideas, testers become project drivers and CI/CD supporters.

Lead on, Testers!

Lead Testers and Lead Testing

As I exit a project with disappointing results for me personally, I’m motivated to re-invent my role by combining select experiences from past projects.  At the start of my next project, my conversation with project team members might take on this flavor.

My role as test lead is to facilitate testing, advocate for smart testing, and to guide testing within our project.  Developers may create and execute unit tests, and analysts may evaluate product definitions; both are testing activities.  I encourage them to collaborate early with project testers for feedback, to augment the testing, and to identify automation opportunities.  The goal is not a fully tested product; the goal is verifying business behavior that delivers value at a rapid pace.

I go into the project with a position of achieving 100% automation.  I’m not advocating for 100% rather I’m setting a goal of 100%.  I want to use automation to demonstrate behavior not just after a product is complete, but frequently as we make changes to the product.  I want our automation to provide confidence to our team so they can continue to add functionality, explore different implementations, optimize the product for performance, and verify we still deliver business value.

I will foster a sense of community as we explore the details of the design.  Together, I want to create definitions of our products that we can build and evaluate quickly, products that we are proud to demonstrate, value that distinguishes us in the marketplace.  As equals at the drawing board, I want our team to collaborate, to challenge, and to bring their diverse talents for a common purpose.

Our project will likely required services and integration with other parts of our enterprise.  I want to meet with them soon, share our story and engage their team to assist us.  I believe a proactive approach helps them prepare better, makes them more willing to participate, and contributes to our mutual success.

The Shift Left
The role of Test Lead is no longer confined to leading a team of testers, it must lead all testing within the project.  With “Shift Left” continuing to gain momentum, the Test Lead’s focus and responsibility grows to guide the testing of the project such that product definitions are clear, small bits of code are exercised, and value is demonstrated.  Success will depend more on your ability to support team building and encourage effective collaboration than testing or technical skill.

20 Things to Improve Your Testing Career

Jump start your testing career by trying a few things on this list!  Then, try a few more!

1. Experience all the BBST courses
2. Help a student with Algebra (there are built in tests!)
3. Learn a programming language
4. Become familiar with the works of Weinberg, Kaner, Bach, and others
5. Organize and maintain a testing forum where you work
6. Attend a testing conference
7. Engage an RST course near you
8. Coach a Science Olympiad of FIRST Lego League team
9. Participate in Weekend Testing
10. Read to learn and to diversify your thinking
11. Attend local testing meet ups regularly
12. Publish an article on a testing topic
13. Speak at a testing conference
14. Plan and propose one change to improve the way you test at work (then, do it again)
15. Find a hobby that requires some kind of testing
16. How about those conversational, listening, and collaboration skills?
17. Exchange new testing ideas with project managers, developers, stakeholders, and others
18. Read blogs and start your own blog
19. Create your own website
20. Offer to design a low level test (also known as a unit test) for a developer
21. Follow the testing community on Twitter
22. Learn to be effective with a word processor and spreadsheet

What might you add to this list?

A Short Collection of Essential Goals By Test Role

Here is my collection of essential goals for a Tester, a Test Engineer, and a Test  Lead.

Tester
The Tester acts on the behalf of their sponsor to evaluate new and changed products.

• Assist in clarifying sponsor requirements
• Establish and maintain good rapport with all project team members
• Offer to help craft low level tests
• Collect information through observing, inspecting, exploring, and exercising products
• Prioritize test execution by risk
• Be cognizant of your reactions to product behaviors as if you are watching you use the product
• Reflect on interesting behaviors and follow interesting operational paths to learn more
• Share observations or conclusions with others often
• Report odd things you find that distract from the value of the product
• Continue to learn and practice testing skills

Test Engineer
The Test Engineer uses their technical experience to extend the reach of the Tester, and to improve testability of products.

• Assist in clarifying sponsor requirements
• Establish and maintain good rapport with all project team members
• Offer to help craft low level tests
• Provide mechanisms for deeper or isolated evaluations of product processes and across a diversity of data
• Provide methods to mock behaviors, data, or services that allow exploration of edge scenarios and errors
• Find opportunities to simplify a requirement or technical operation that speeds information collection
• In interactions with others, clarify, elaborate, express, proxy, explore, and negotiate to provide a clear understanding of what is needed, and what is provided
• Continue to learn and practice testing skills
• Learn how to apply new technologies to testing

Test Lead
The Test Lead develops strategy, evaluates risk, works with sponsors, mentors team members, and reports on testing activities.

• Assist in clarifying sponsor requirements
• Establish and maintain good rapport with all project team members
• Offer to help craft low level tests
• Monitor project progress for new testing opportunities
• Encourage the team to test early and test often
• Be proactive with test data creation and environment availability
• Minimize work interruptions
• Provide interpretations of observations, discoveries, and defects in terms your audience can use to make decisions
• Provide relevant, valuable, and valid information in a timely manner

I believe there are more goals in each role.  What goals do you have in your test role?

The Project Scavenger Hunt

Near the middle of my last project, I met with my project manager and iteration manager to discuss the addition of new team members.  We were adding both developers and testers and, as you might expect, it was important they learn about the project, the application, and meet everyone in a short amount of time.

We reviewed the documentation we had for training and thought about a training schedule.  Then, I recalled something I did on another team.  I suggested a project scavenger hunt might reduce the training time and help new team members engage the project and team members faster.

The Project Scavenger Hunt
A scavenger hunt is a popular party game where participants are separated into teams and given a list of items to find or “scavenge”.  The items might be a paper sack, a paper clip, an empty soda can, and the like.  The object of the hunt is to locate as many items as possible in a fixed time period.  The team that brought back the most items won.

The primary intent is to have a new team member engage the team in learning about the project.  I craft my scavenger hunt questions so they must introduce themselves and ask for information.  I encourage new testing team members to talk to people – testing is a very social activity!  A list of categories includes:

• Location of Information
• Names of Team Members
• Names of Stakeholders
• Project Purpose
• Product Details
• Product Use
• Legacy Product Information
• Project Metadata (status of a specific product or defect)
• Product or Project Processes

Here are some examples:

• Who is the Test Lead?  How long have they worked at this company?
• What is the business value of this project?
• The payment transaction accepts: A. Cash  B. Visa  C. IOUs (a little humor is welcome!)
• What is the state of Defect 123?

A little creativity and imagination can generate up to 20 questions.

To round out the scavenger hunt, I include activities the help the new team member engage the product or set up their work environment:

• Exercise a Product
• Install Software

Some examples:

• Make a Payment Using a Credit Card in the Payment Transaction
• Install XMind and Map the Payment Transaction

Test It!
For a fun alternative to lecturing or reading on-boarding material, I invite you to try a Project Scavenger Hunt.  After you create one, test it with your existing team!