Category Archives: Leadership

The New QA

Our applications are growing larger and more complex in business functionality, and they are available on multiple platforms.  Our business partners expect more functionality with better quality delivered in a timely fashion while our technical leaders attempt to simplify designs and make it all possible.

The ability to deliver value in an application AND making it simple to use challenges experience designers, developers, analysts, and especially testers.  An expectation to evaluate application behaviors in depth through just the user interface has not only become a fallacy, it has become insufficient and risky.

High profile projects in your organization must be delivered quickly and as a tester, you cannot wait for completed code to begin testing, and you cannot assure quality merely by testing through a UI.  The definition of testing must extend beyond exercising code to evaluate requirements and risks.  To expect high quality products at a good pace, you must foster and nourish quality as a team sport.  Your time is now and project teams are ready to hear you!

Testing now begins when work is assigned.  You are the Question Asker and you scrutinize acceptance criteria.
Soon after the assignment of a story card (or your method of work conveyance upon your team), the Three Amigos is your first opportunity to foster team quality, your first opportunity to “test”.  Your tests include

  • A check for acceptance criteria clarity
    • Does everyone have the same, deep understanding of WHAT is being built?
    • Have those understandings been verbally explored and vetted?
    • Have you vocalized your assumptions and had them clarified?
  • A check for validity
    • Is this product being constructed at the right time?
    • Are there dependencies that could prevent its timely completion?
  • A check for value
    • Some products are defined at some time in the past – does the present context of the project still support the work defined by this card?
    • Will the completed work still be valuable to the project and the product?

Testing continues as products are designed.  You are the Quality Advocate for testability in designs and implementations.
Most products require some thought before their construction.  The project team explores possibilities for implementation during design meetings.  Your testing continues at these meetings.  While you could also attend design reviews, a design review may imply that the design has been decided – this is too late.
When the design of a product is discussed, your primary goal is the testability of the product.  If the design addresses just the business intent of the product, then it is not testable.  As a tester, advocate for testability.  Make a request for error logging, for transaction transparency, and for data transparency.  An introspective product is a testable product.

During implementation, paired programming becomes paired collaboration.  You are the Quality Accomplice with simple tests at the ready and encouraging reflection on how the product in front of you will interact with the system.
Quality must be built into a product: the product is defined in a manner that is clear to everyone, the product is designed so that inspection is simple, and the product is constructed and checked multiple times during its implementation.  As a tester, you are the Quality Accomplice by having tests ready for execution at any time, and by working with the developer to help them create a quality product that meets the business intent.  To work effectively with a developer, you must understand the system and its components, and how the components interact to provide value.  With that understanding, you can ask questions how the code in component A will interact with the code in component B under multiple scenarios.  This collaboration helps everyone reflect on the integration of small parts defined in story card and their contribution to a product that operates correctly in multiple scenarios.

I encourage you to go forth and experiment with these ideas.

 

 

Advertisements

No Limits #1

I made a wiring error that left this power supply useless.

20180309_201808

I started from scratch to build this replacement.

20180309_201730

Cool!  Now, build another one ’cause I need two.  That are almost alike.

20180309_201940

This one needs a wicked heat sink.

20180309_202225

How will all those components fit on this board?  Perhaps a different placement of the heat sink?  It seems I need more space.

20180309_202420

I don’t have to use the original board.

When you think, believe, act, or talk with limits to methods, behaviors, or actions, you also limit your possible solutions.  See your world as if it always has fuzzy borders, as if the edges of your vision fades to a cloudy background full of possibilities, as if every challenge has multiple solutions.

As a tester, I am challenged frequently to scrutinize gherkin that describe what to build, software that was built using both knowledge, experience, and interpretation, and, most challenging of all, suggestions on what and how to test.

You start by stating you see things differently.  Engage your peers in a conversation to nourish your gherkin into robust examples, to explore new and changed code frequently, to understand alternative viewpoints on what others want to learn about product behaviors.

Then, challenge (respectfully but with assertiveness).  I say challenge because sometimes products are not as complex or interrelated as they seem, because a simpler test may lead to adventurous exploring, because you need to use your time wisely, and because the succeeding conversation may uncover the assumptions that have become hidden with familiarity or painful with production issues.

Uncover the perceived limits and unlock many potential solutions.

Perry Mason and Assumptions

That’s twice!  Twice this week my assumptions caused a bit of trouble.  Last Saturday, I placed an order for parts.  They are not expensive but I’m careful about my selections and want to verify multiple times that I have the right parts.  On Saturday, I was confident in my selections and I placed the order.

On Sunday, I performed a test with a voltage regulator.  By design, voltage goes in and exactly 3.3 volts comes out.   I connected my 3.7 volt battery to the input and found 2.9 volts at the output.  My assumption was the battery voltage was greater than the output (that is, 3.7 > 3.3) so the regulator should work.  I didn’t have the right parts.  Fortunately, I was able to remedy this assumption by amending my order.

Today, I was updating a Java program.  I needed a string representation of date and time so I used the SimpleDateFormat object to create the representation.  I handed the format() method a Calendar object and started the program.  I was not getting the expected result.  Ignoring sarcastic little voices, I reviewed my changes and added some logging.  The voices were correct; it was the format() method.  My assumption was I needed only to provide the method a Calendar object.  It needed a DateTime object.  Fortunately, I was able to remedy this assumption.

Assumptions are sneaky.  Sometimes we know about them and discuss them, other times they drift in like a slow forming fog.  You don’t know its there but you discern some challenge.  It’s too subtle to change a direction but you’re cognizant of it.

I have many example of this experience through my recent Earl Stanley Gardner binge reading.  Gardner brought us Perry Mason.  If you are aware of Perry Mason only as a TV series, I strongly recommend the books.  They are engaging, humorous, and full of clues.  There are strong analogs to story cards.  When a story card goes awry, check assumptions and check the story.  One or two facts get misaligned and a defect is created.  Gardner weaves multiple facts and multiple explanations for facts.  It the end, Perry Mason, in the role of tester, fights through the fog of assumption, illuminates small details, and finds the one true story to exonerate his client.

As a tester, you will benefit greatly by having your assumptions dashed, and attention to detail challenged.  This week, two assumptions caused some delay in executing my hobby.  What assumptions might we be making that could cause a delay in our projects?

 

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.

 

 

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.