Testing roles are shifting

1 Comment

New ways of delivering software and solutions challenge existing perceptions of what roles and activities testers and test managers have. Some are getting more into development others into people skills. Sometimes forcefully, other times as part of self-organizing teams.

This post is a link collection for the talk: Testing roles are shifting, but where to? for the Ministry of Testing Meetup Copenhagen chapter, march 2017.

Introduction

Shift Left:

Shift Right:

Shift Coach

Shift Deliver:

 

Additional links

Continue the discussion Where are testing roles shifting to?

Co-creating Smarter Tester

Co-creating Smarter Tester

Shift-Deliver, TestOps and Management of Changes

5 Comments

Shift-Deliver is a label I choose to put on the changes the roles and activities of the TEST MANAGER, when the test manager moves towards (also) being involved in the ITIL change requests, delivery management, configuration management and branch management that happens when the solution goes from the test phase to production. Another label could be “TestOps” as presented here, as the intersection of Testing and Operations. TestOps have been identified for along time. ….Interesting.  🙂

In my IT outsourcing context, this is less about software, and more about solutions. In at least two of my long term enterprise scale projects, half the job was test management (of operations) projects, half the job was regarding ITIL change management. My change management activities was mostly making sure that

  • the process was followed
  • that information was provided to the stakeholders
  • that testing happened
  • risk mitigation happened

I was hired as “the quality guy”, but expanded the role over the time I’ve been on the team to take ownership of all of our build and release infrastructure as well. Basically, I’m responsible for everything from the moment code is checked in, until it hits our production servers 

To use a quote by Alan Page. Again Alan is a representative of what happens with regards to trends in testing. He might be wrong, as well as I. I try to label the trends to understand them. These four trends that I have spotted are not mutually exclusive, neither do they all four need directions. Change is happening to the classic test manager rolle of going through the motions of test cases and documents. This is clear when looking into these posts:

Initially I discussed Shift-Deliver, Shift-RightShift-Left and Shift-Coach  at Nordic Testing Days 2016 during the talk “How to Test in IT operations“ and coined the labels on the EuroStar Test Huddle forum.

DSC03562

Trending: Shift-Left

7 Comments

TL;DR: Shift-Left is about testing early and automated. Shift technical with this trend or facilitate that testing happens.

Shift-Left is the label we apply when testing moves closer to development and integrated into the development activities. The concept is many IT years old, and there are already some excellent articles out there: What the Shift Left in Testing Means (Smart Bear, no date), “Shift left” has become “drop right” (Test Plant 2014), Shift Left QA. How to do it. Why it matters (Work Soft, 2015).

To me Shift-Left is still an active trend and change how to do testing. This goes along with Shift-Right, Shift-Coach and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“.

Here are some contexts where Shift-Left happens:

  • Google have “Software Engineer in Test” as job title according to the book “How we Test Software at Google“.
  • Microsoft have similar “Software Design Engineer in Test” as discussed by Alan Page in “The SDET Pendulum” and in the e-book “A-word
  • A project I was regarding pharmaceutical  Track and Trace, had no testers. I didn’t even test but did compliance documentation of test activities. The developers tested. First via peer review, then via peer execution of story tests and then validation activities. No testers, just the same team – for various reasons.
  • A project I was in regarding a website and API for trading property information had no testers, but had continuous build and deploy with even more user oriented test cases that I could ever grab. (see: Fell in the trap of total coverage)

The general approach to Shift-Left is that “checking” moves earlier in the cycle in form of automation. More BDD, more TDD, more automated tests, continuous builds, frequent feedback and green bars. More based on “Test automation pyramid” (blog discussion, whiteboard testing video). Discussing the pyramid model reveals that testing and checking goes together in the lower levels too. I’m certain that (exploratory) testing happens among technicians and service-level developers; – usually not explicitly, but still.

To have “no QA” is not easy. Not easy on the testers because they need to shift and become more SET/SDET-like or shift something else (Shift-Right and Shift-Coach and Shift-Deliver). Neither is it easy on the team, as the team has to own the quality activities – as discussed in “So we’re going “No QA’s”. How do we get the devs to do enough testing?

Testers and test managers cannot complain, when testing and checking is performed in new ways. When tool-supported testing take over the boring less-complex checks, we can either own these checks or  move to facilitate that these checks are in place. Similarly when the (exploratory) brain-based testing of the complex and unknown is being handed over to some other person. Come to think of it I always prefer testing done by subject matter experts in the project, be it users, clients, testers or other specialists.

We need to shift to adapt to new contexts and new ways of aiding in delivering working solutions to our clients.

jollyrum

Chicken for Christmas – Tradition is a choice

1 Comment

TL;DR: Testing is always something that we choose to do – and how we test is similarly a matter of choice. As is Christmas traditions. .. it’s just man-made rules, we can choose to change them.

So I was discussing what we should have for Christmas with the stakeholders. One of them wants the traditional rice pudding, the other wants – untraditionally: chicken. And you know what – that’s ok. Traditions are guidelines, not rules – we can make new traditions, just by choosing to.

Testing in production used to be a great no-no. I’m still feeling odd when we do it, but I have come to see it as another tool of the trade. It has a name now “testing in the wild” TTitW as has been presented at EuroStar 2015. Also this is how Netflix have been testing for years, from GitHub, as it is open source too (!).

You might argue that changing testing (in the wild) is not allowed. I will challenge that assumption – being allowed to do something is a choice too. You choose to follow the the process frameworks, requirements, rules… and you can choose not to. The tradition of manual predefined testcases are so four years ago!

Sometimes it’s just a matter of saying up-front, that you are tailoring the process. So choose an approach that actually gives meaning and value to the stakeholders and context. Deconstruct the traditions and commercial bodies of knowledge and make some new!

What testers find

1 Comment

Not all my projects are thundering successes… Different early decisions have set the scene – but still the play, so to speak,  have been full of lessons in what testers find – when asked open questions:

  • A team had previously synchronized information in the old context, so they where invited to test the new solution… which turned out would eliminate the need for synchronization. but nobody had troubled them to tell them so.
  • That the development team was not acting agile, sprints and scrums in words only
  • That the biggest PBI (product backlog item) in hours, actually was to get GUI automation of modal-windows to work.
  • That despite having a requirements sheet, the actual value of the sheet was zilch
  • That despite putting in extra hours and overtime, the quality and stability of the delivered did not improve
  • That the biggest problem towards integration was problems between .Net and java implementation of SOAP
  • That simple requirements on virus scanning documents, was both hard and expensive to solve
  • That part of the project deliveries was upgraded business guides, when tested they needed corrections too

Calling them all defects or even software bugs, does sound odd to me, because those that really take time is not the software issue it self, but misunderstandings and due to not knowing everything (will we ever). Standards tell you that testing finds risks in the Product, the Process and the Project – it seems to me even more we find issues in management decisions, architecture decisions, cultural issues, organisational change… it’s just software but it does have a business impact.

tractor

Lego Role Models for Girls

Leave a comment

Who had the family’s largest LEGO set his Christmas – not the boys (age 8-10), neither the “boys” (age 40 and up) – it wasn’t me* – but the 11-year-old girl and her 8 wheel 42008 Service Truck – 1276 pieces, power functions, pneumatic, gears and 44 cm forcefulness. There was no boy band merchandize, no glitter or similar gender framing. Quite a project – as is the story about the “Research Institute” mini-figure set.

42008-121110 More

A commercial body of Knowledge

3 Comments

What I know of the ISO29119 is that specifies specific numerated techniques, documents and document content. I know this from their website, where I can read that it will cost me $1000 to buy “the book” (club discounts available) – the body of knowledge.

It’s a collective work written by a number of people in the industry, and have been years in the making. Some of the people work in consulting and provide training in the framework, some of the companies sponsoring the work provide consulting in implementation of the framework. Companies can have an audit for a certificate too. That will require a large investment as the organisation have to (norminative) conform to plenty of “shall”.

But besides that it’s a closed book (and it’s not even on Amazon). To me the 29119 is misguided from the beginning, it should be a book – a commercial body of knowledge, like TMAP or like ITIL. Something that you could buy into or not. Not something in any respect labelled as a international standard.

  • It seems it requires either a range of documents and lot of tailoring
  • It seems to be some what “dated” in the addressing ways of testing being added in recent years
  • It seems to claim that it has consensus in the industry
  • It seems that some people have tried to participate , but failed
  • It seems that some people did not want to participate on principle, even if invited
  • It seems to claim that it is a silver bullet, a one size fits all

I cannot evaluate the implications for my customers asking about compliance without elaboration – on the details of 29119, and on the customers objectives. What is the business driver for complying with said framework? Which is actually what I was looking for – what helps the (customer) business making a business?

I doubt that someone else’s delivery framework can provide you with the DNA, the unique value proposition, of the specific context that is needed – for you! #ImLookingAtYou. If we blindly comply with the framework what is the driver besides cost and commodity. If the driver is something else, then start right there. Start with how testing and artefacts implements the strategy, values and decisions that you have. Start with “innovative“, “quality of life“, “coherent” – how does that relate to your testing.

See also

Older Entries