Shift-Right, you wild one!

3 Comments

The Shift-Right label is that more and more testing (and checking) can happen on the live application in production. Some call it monitoring, some call it Testing in the Wild. It is a very wild idea for some people and some contexts #YMMV. It may very well be the best way of testing in some contexts.

Once I consulted on a network stabilization and delivery optimization project for a consumer bank. They had many issues in their production environment… I strongly advocated that they did test controlled and structured in production on the network changes and other operational activities. (I have talked about “How to Test in IT operations“ at Nordic Testing Days 2016). More on testing during IT deliveries in Shift-Deliver.

Shift-Right is trend that people have covered well before me, here are some pointers:

The key is really as Alan puts it “testers should try to learn more from the product in use” and with that comes the tools of Google Canary builds, NetFlix Chaos Monkeys etc.

kabuum

This trend goes along with Shift-Coach, Shift-Left and Shift-Deliver discussed separately. Initially I considered shift-right to be regarding consulting, but after hearing Declan O’Riordan at DSTB 2016 I realized that shift-right was the right label for test in production, testing in the wild etc.

Similar posts regarding things in the wild: Bugs HappensThe Kcal bugTradition is a choice and Can you see beyond the visible.

The Shift-Coach Testing Trend

8 Comments

Shift-Coach is when testers and test managers trends towards being coaches and facilitators of the testing activities. Shift-Coach is more about leading the testing than leading the testers to paraphrase from @DevToTest Joe DeMeyers blog post.

The ground breaker for this trend, is to me, the talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015 by Stephen Janaway. Stephen explains how reorganization of the test manager role forced him to be more a facilitator than embedded in the teams. Similarly many other great test managers talk more and more about people skills and coaching, especially in agile projects. I want to define shift-coach around the facilitation testing activities, and place testers that doubles as scrum masters in the Shift-Deliver trend.

In traditional (v-model) projects testing has often included people that were not professional testers; – in user acceptance tests this has often been business subject matter experts. The testing was done by someone with the best knowledge of the topic, and that may not have been the professional tester. That more and more projects do this – more and more, is a big challenge for many testing folks. But it is a significant trend in testing world of 2016.

Shift-Coach trend is visible when Alan Page  talks at Test Bash Philly 2016:

You’ve heard the rumors, and you’ve seen it happen. An organization or development team decides they don’t need testers, and you have big questions and massive concerns. Is quality not important anymore? Are they irresponsible or idiotic? Are their hats on too tight? Do testers still have jobs?

Alan Page is a career tester who has not only gone through the “no-tester” transition, he’s taking it head on and embracing it. Alan will share experiences, stories, strategies, and tactics (and failures) on how he’s taken everything he’s learned in over twenty years of software testing, and used those skills to have an impact on software engineering teams at Microsoft. Whether you’re going through this transition yourself, think it may be coming, or just want to tell someone what an absurd idea this is, this is the talk for you.

This trend goes along with Shift-Right, Shift-Left and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“ and coined the labels on the EuroStar Test Huddle forum.

legocoach

Drive the Testing – Coach!

When good enough is the perfect fit

2 Comments

Similar to scope creep we may also experience “test creep“. Test Creep is when the tester adds more tests than what is in scope. Just as well as more business functionality is added during scope creep, more testing is added in test creep. Both aren’t necessarily bad, but in time-boxed or similar (budgeted) constraint projects creeping isn’t necessarily value adding. This is probably easier to understand in an agile project focusing on minimal viable product , but may happen in other contexts too.

It is test creep, when the tester feels an obligation to run an extra drill down into browser and OS configurations, when scope is less broad. It is creeping the scope of testing, if the testers feels a “/need/ to write testcases for this first” when exploratory sessions fits the mission. Consider test creep like gold plating, in that way that it tries to refine and perfect the product – when good enough is the perfect fit.

Test creep can happen intentionally, happen by management or by product owner request. It may happen unintentionally, and usually it is with the best intentions – as more testing always is better testing – right? (But it Depends) Sometimes yes, we as testers are to blame that we add more scenarios, rigor and details, because a testing mindset drives us to investigate the product.

In discussing this with Mohinder and Darren, we found that – it’s not only a matter of removing wait time for testers. This may add more time, to test but the scope creep in testing may happen none the less. A Lean mindset with focus on what adds value to the business and a discussion on the minimum viable testing will assist the project in avoiding test creep.

 

minecraft_creeper_wallpaper_by_lynchmob10-1440x900

Uncovering better ways

3 Comments

I am uncovering better ways of developing solutions – by doing it and helping others do it. Through this work I have come to value:

  • Apply the costs to add business value – over cutting costs
  • Being flexible and open  – over adding predictability 
  • Providing information for decisions – over ensuring the reliability

More

To scale even agile needs governance

1 Comment

Key takeaways from [ “Why Agile doesn’t scale, and what you can do about it” | Dan north (@tastapod) | GOTO Aarhus 2013 ] If you want the full version see his full slide deck here.

2013-10-30 15.21.48

Being agile is about getting something out the door – it’s very good in doing SHIP IT – Tweak it – think it build it. Wax on – wax off. Being agile is about people and tools  and is a great approach for problems that allows to be solved with these borders.

The challenge is in the more complex  domains with a bigger solution, a bigger problem, a bigger program with many people, many dependencies, many teams. In these (NP?) problem domains other factors come into play: Governance, Customers, Money and the organization as a whole (see slides regarding Agile Adoption Patterns).

In the later contexts agile as a delivery model doesn’t scale without project governance and portfolio management to oversee and prioritize based on strategic returns on investment. Shipping any minimum viable product from time to time in a larger context requires more oversight on “are we nearly there?” “are we ensuring delivery?” “are we ensuring credibility?” .. are the many global teams going agile in each their direction?

The same goes for the testing efforts – agile scales to a certain point, and at that point the scrums, the state-models and so on are a part of the solution engine. It’s what’s tests something, but with size comes the need to know why we make the decisions we make – and  are we there yet?

5993667708_727f601b5e_z

Disclaimer: GOTO Aarhus 2013 is sponsoring my attendance as a blogger.

On applying a single method

1 Comment

Simon Wardley, Leading Edge ForumOh not again – should we be an agile or six sigma shop? ]

First, every system of any reasonable scale consists of multiple components. Those components are all evolving (due to the effects of competition) and you can (and should) map out the components of any system before embarking on trying to build it. Below in figure 1 is a basic map from a heavy engineering project with a large IT component

Now, all the components are evolving from left to right and as they do so their characteristics change – they move from an uncharted space (the novel, the chaotic, unpredictable, uncertain, potential differential) to the more industrialised (the common, appearance of linear order, the predictable, the certain, the cost of doing business). 

The same thing with your testing – that is: If you dare to take a holistic approach and not only focus on the mechanics. See also:  Mapping testing Competencies , Learn to think like a businessWhen do testing happen? 3D model for testing contexts Black or white – it is the same box

Mapping testing Competencies

2 Comments

[ Recognise and Acknowledge Your Skills  | Ministry Of Testing – The Testing Planet | June 2013]

The below model is directly inspired by the Vancouver Agile Quadrant introduced in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Crispin and Gregory 2009 based on the original matrix from Brian Marick in 2003. It consists of four primary branches – as seen on the illustration. It is not a matrix or a table, but four directions with each their cloud of buzzwords. For specific contexts a mind-map will be a better choice of illustration – try drawing your own competencies.

Tester Skills Matrix

Tester Skills Matrix

Older Entries