Category Archives: Collaboration

Goldilocks and Test Automation

I’ve struggled with the right level of automation for a long time and alluded to a level of salvation here.  Since that post, I’ve moved on to engage automation using Given-When-Then (and its collateral ideas) much like a sailor engages a lighthouse at night.  In my most recent experience, it was more like a sailor is on the bridge watching the light and I’m below deck providing interpretation and direction.

My testing team created an excellent suite of automated regression tests for the stored procedures used in our application.  But I’m struggling with the number of tests created for this suite.

It might be that my definition of “regression tests” is more economical than that of my teammates and I own that communication error: I probably was not clear on what I thought this task should produce.  But it also goes to the heart of what I believe about automation tests.

In 2007, I, like many others, was enamored with automated tests against the UI of my applications.  A steady diet of automation tools over the succeeding years (starting with HP QTP) were both valuable and frustrating.  I eventually gave into the frustration because the tests I, and many others, wrote were fragile and numerous.  My response was to limit what I automated because inflicting such a level  of maintenance on a product team was just wrong.

I watched as other teams continued to indulge in not only creating these tests but to develop frameworks around frameworks that provided some theoretical value and, in my opinion, dubious claims of a positive ROI.  I was unimpressed with what appeared to be the emperor (in their “new clothes”) dining happily on over-heated porridge.

With training and some practice in Given-When-Then and its description of business outcomes, I started to see practicality again in test automation.  A test that evaluates business outcome is, in my opinion, more stable, valuable, and maintainable than several poorly designed automated UI tests.  Then, there are two questions.  Always.  Two.  Questions.

Can I automate this test?  Of course, I can automate just about any test.  The avalanche of software utilities that pop up around tools for test automation is evidence of over-indulgence in coding.  Not testing.  The second question is most key:  Should I automate this test?

I advocate for tests designed for simplicity and to exercise isolated business outcomes.  The tests should be motivated by risk, value, and maintenance.  Upon a review of these criteria, I stand the best chance of balancing tests (the most value) and the code (that which must be maintained to deliver the test).

My team and I will meet to review our regression suite.  I look forward to exploring differing definitions of “regression test”.  I welcome their perspectives that could help all of us discover the combination of test and code that is “just right”.

My GWT Identity Crisis

There are a few things I’ve not tried yet.  Sadly, possibly, I’ve not tried karaoke, and I’ve not tried kite boarding.  I am however getting my first experience in applying Given-When-Then in describing product behaviors on a real project.  I’m very excited at the possibility of merging business behavior with automation.

I engaged Specification By Example, I attended hands-on training, and I have participated in periodic drive-by creations of GWT scenarios.  I felt very ready.  Hurtling into some of our project’s first story cards, I was shocked to review GWT that contained behavior AND, take a deep breath, implementation details.

As an example, I offer a scenario from an API I wrote for a website.

GIVEN active flights exist,

WHEN the website requests a list of active flights,

THEN the reply includes all active flights

AND their unique identifier,

AND their altitude,

AND their last update.

This GWT represents my interpretation of what I have learned and, as noted above, my limited experience.  Here is how the same scenario might appear if I violate one of the most fundamental rules.

GIVEN the active_flight field indicates true,

WHEN the website executes GET against the activelist API,

THEN the response contains an HTML table detailing the flight’s GUID,

AND the flight’s altitude as an integer,

AND the last update in a UTC format.

In my opinion, this is more than a violation of the “no implementation details” rule.  This description locks the behavior to a specific column of a database, defines the verb and API name, prescribes a specific rendering method, and calls out individual field data types.  Its as if a developer provided the information they needed to implement the scenario to an analyst.

While this is clearly an extreme example, I recently read such a scenario.  When I asked, the reason implementation details were included was because this is a “technical story card” (different from a “business story card”), and because it is easier to provide all the information in one place.

(ahem) Bull.  Shit.

In my opinion, this method of practicing and segregating GWT ignores one of its most quintessential and valuable aspects: collaboration.  Yes, I read Specification By Example and attended training.  I learned the mechanics but in both cases I left with something more.

I perceived an overwhelming feeling that during a conversation about product details between an analyst, a tester, and a developer, these few people begin to share not only their ideas but their understanding.  It IS NOT the GWT itself that encourages automation or reduces defects rather it is those precious minutes where an honest, introspective, and respectful dialog clarifies the behavior of a simple product.

Just writing GWT provides a small window into a product.  Collaborating over the value of a specific business behavior encourages teamwork and quality where everyone can take pride and feel their contribution matters.

 

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.

An Experiment for 2016

I missed writing.  I think about it every day but it’s like drooling over a pizza ad.  It’s nice but pizza with the family is much more satisfying, leaves an impression, and has more impact.  My inspiration to return came from Julie Zhuo reminding me of many great things I have read about writing – thank you Julie!

I focused a bunch of time on building a new web site for my hobby.  I like building it and I like testing it.  It gives me an opportunity to stretch my testing muscles lest they atrophy from the daily experience and negotiation of leading a testing team.  I enjoy the test lead role but when I need to do something to relax, I code and I test.

With a large and successful project behind me, I had an opportunity to catch up with our testing community.  Notably, I finally read Specification By Example (SBE) by Gojko Adzic (I realize I’m late to the party on this one).  I was seven chapters deep and realized I’ve miss so many opportunities to implement SBE ideas.  Then, there was a post on an internal blog recommending all testers read the book.  There was a momentarily satisfaction that my actions and the universe had aligned.

Ever since I started automating test cases, I was apprehensive about their existence beyond the end of the project.  We live in a very dynamic industry so the solution we implemented would inevitably change.  My tests would fail when change hit some critical mass.  I resolved to do better but better was to recommend caution around what was automated.  My constant challenge was writing automation that could survive change AND deliver a valid result.  I was a little successful but not always satisfied.

SBE crystallized my reasons for cautious automation.  I was unable to articulate why because I hadn’t found a suitable alternative.  But the logic and wisdom of automating business outcomes resonated with me.  The business outcome has a much lower frequency of change so automation makes sense.
It also defined why I had such apprehension.  What I have seen is automation of not only business outcome, but automation of test cases that provide little information just because they could be automated.  I also saw automation evaluating lower level functionality – which is valuable – but it was executed from the UI.  Both of these added technical debt and impeded project pace.

With the new year and a new project, I’m ready to experiment (it feels more like a hurricane of righteous purpose but I’ll calm down after a bit).  I discovered that our Requirements/Business Analyst community also favors the approach.  So far, I’ve suggested SBE to two other projects and the response is positive.

 

 

The Most Important IT Skill

My wife and I attended Curriculum Night at the high school where our boys attend.  It had already been a busy week (and frustrating one if you count the removal of a poorly designed kitchen faucet).  But Curriculum Night is something I have enjoyed for many years and would not consider missing it!

My son is enrolled in AP Programming so I was very curious about the curriculum AND the teacher.  I was impressed with the cognitive level of assignments he had last year, and this AP course had my expectations high.  I sat through informative yet similar sounding sessions on Pre-Calc, English, and Physics before hearing about the AP Programming course.

When I arrived for the session on AP Programming, the teacher greeted me with a hardy handshake, an excited “Welcome!”, and invited me to sit where my son usually sits.  He was animated and nerdy (cool).  He had spent ten years in the industry before deciding to teach (nice).

He started talking about the curriculum, noted the students receive one new programming concept per week (they are working on arrays this week), and finished with how their work is evaluated.  My interest grew.

Students are expected to review each others’ work, note the differences between the implementations, and they are invited to speak in front of the class about their discoveries.  The teacher stated the ability to communicate was as important as learning how to write programs!

I was elated.  An experience in collaboration and empathy respectfully facilitated by the students is a great IT lesson.  In my journey through my testing career, I discovered that, as a Test Lead or Tester, testing is a very social activity.  The ability to convey and negotiate ideas, collaborate with multiple personalities, and develop a working team has been as rewarding as writing programs and tests.  Getting that experience in high school is like preventing defects early in the project!

Testing is not for the Shy

I recently joined the Test Design Exploration team.  This is one of many groups within our enterprise available to mentor testers.  Our charter is to explore test design techniques, provide opportunities to use them, and discuss how techniques might be used in projects.  We establish a schedule of test design topics and testers sign up to attend sessions.  For example, we’ll be exploring All Pairs in an upcoming session.

Our team has been meeting regularly to prepare the sessions and set up a schedule.  I like our group – they are very experienced and bring some fresh ideas to our topics.  Recently, we provided a status update and some clarifications around our scheduled start date.  With the business complete, someone suggested that our team create a SharePoint site where testers might ask questions of our team should they be to shy to ask during a session. I liked the idea of having a place to follow up from our sessions.  Accessible to everyone, it makes our team more transparent, and I think we are willing to support it.  What stuck with me was the description of a tester to shy to ask a question.

When I started as a developer in this organization a while back, the fact that there was a whole group of people dedicated to testing was new to me.  I thought it was pretty cool!  But I rarely saw them during a project and heard from them even less.  When I moved to a testing job family, I tended to be very vocal.  Actually, it might have been called pushy or obnoxious.  But with a lot of feedback and practice, I found a testing voice that is more collaborative.  I also learned that testing demands more of a presence from a tester. I suggested to my test design teammates that we should encourage testers to ask questions.  The sessions are a safe place to do this, asking questions in a group gives them great practice and confidence, and maybe we can deliver more than test design mentoring.  They all agreed.

Testing is not for the shy.  There are developers that will push you around with very technical language, dispute defects, question the credibility of your tests, or just ignore you.  There are project managers that will pressure you to reduce testing.  In my opinion, this is not the identity of a tester.  Take back your identity!

You are a tester and quite capable of

  • Learning C#, Java, or any other language
  • Defending your defects both at a technical level and, more importantly, at a business level
  • Establishing credibility through early collaboration and shared goals
  • Being a contributing member of any project team
  • Expressing the risks of reduced testing

I’m looking forward to exploring test design with testers in my organization.  But I think they can learn more by asking questions in the sessions or anywhere they go.  The bigger challenge for me is encouraging them to believe in their capabilities, and to have them respectfully act on the behalf of the quality in the products they evaluate.

YOU Can Improve Testing in Your Enterprise

Can a single blog post describe how to make a change in your enterprise?  Maybe! If you came this far, then I believe you can be the catalyst.

You know your organization needs a change.  It’s a nagging awareness that things could be better, or an annoying realization that other companies are doing it better, or dream-like world where testing is integral to the project, part of a team, part of a solution.

Am I the Only One Who Knows?
Perhaps you’re asking, “Is it just me that knows?  Do others know?”  Maybe – but think about the conversations at lunch, in the hallways, at happy hour – has anyone ever vented about testing?  Perhaps someone was subtly dismissed by another team member, or another felt they let a project down in not testing enough.  In all the venting, has anyone said, “It can be different”?

Maybe you can say it.  Maybe you have said it at happy hour.  It might have felt as if you just said y’all gonna climb Mt Everest.  Some look at their drink, some take a drink, and some review jukebox selections.  Then, everyone went back to work the next week.

You Were Right
When you said, “It can be different”, you were right.  You were also suggesting everyone climb Mt Everest.  Making a change in an enterprise is an uphill climb, requires a dedicated team, must demonstrate benefit, and must demonstrate repeatability by anyone.  So, you should start today.

Even the first step towards a lofty summit begins with some small action, some small preparation.  You know you want something different, but what does different really mean?  It might mean more respect for some, more time for testing for another.  That small action could be to identify what could be different.  Make a list and look for themes.

Your Opportunity
Does your list suggest better team dynamics?  More test planning?  Support for training?

Two questions:

  1. Can you prioritize the list based on value to your testing?
  2. Does anything on the list align with what your enterprise needs?

Where there is alignment of your list and enterprise needs, YOU have an opportunity.  That opportunity is to demonstrate value in testing as a benefit to your enterprise.

Your Next Step
Pick something on your list and describe what you could do to achieve it.  Let’s say you pick more training.  Training is a broad topic so you want to take a small step.  What might be a small first step?  Read a testing magazine (there are many), read a testing book (there are many), or watch a testing training video (there are a few).

Regardless of the small step you take, apply what you learn and share what you learn!  By applying a new skill, you demonstrate to yourself that change is possible.  By sharing what you learn, you begin to influence others.

The Beginning
Your small step is a beginning.  A beginning that could embody the change or changes that echo off your office cubicles.  Good change starts from within, and it continues with good people.  You will need help and should not be afraid to ask for it.  Often.  Change is possible – find those like-minded testers, find a business sponsor, collaborate on a purpose and principle, and propose a beneficial, sustainable, and exciting change in testing for your enterprise.

What will you do today to be that change?