October 10, 2016
Enterprise IT, Softwaretesting
atWork, automation, change, checking, conference, context, nordictestingdays, shift, testing, test_strategy, trends
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.
October 4, 2016
atWork, conference, context, cynefin, nordictestingdays, quadrant, rapidsoftwaretesting, stakeholders, test_strategy, value
I rarely test software these days. I mostly lead testing of IT solutions.
Testing in the context of:
- Updating all corporate PC’s from windows 7/8 to Windows 10
- Consolidating network equipment from more devices to one box, on 80 global locations *
- Move 40 live business applications from one data center to another *
- Take over application maintenance for a specialized public organization
- Implement track and trace for pharma products from production to shops
- Migrate HR data for 2500 people from one system platform to another
Yes, it happens that I participate in a project that is about developing a new business application, but my activities are less about testing software and more about testing in IT solutions in general.
Mostly I manage test activities and describe testing in these contexts. My preferred way of working is in setting and implementing test strategies. I prefer complex and non-ordered projects (Complex and Chaotic – I’m looking at you), it fits well with my context-driven approach of finding the “test solution that fits the context”.
Testing is in it self a solution, that must solve a business problem. Great testing is all about providing information to the stakeholders. I don’t care especially if this is done by someone TESTING or a TESTER. It is my responsibility to setup the testing activities (information gathering) that supports the team, faces the business & technology and challenges the product “sufficiently“.
Sometimes “sufficiently” is merely confirming and going through the motions of explicit requirement coverage. This is a special challenge to me, as I know of many effective and Rapid approaches, that could add valuable information. When I face this challenge, I try to look at the full picture of the project, and what the business want’s to achieve.
The business of the business is business. What matters is not software or projects, but the solutions to the challenges the business have. And the context of testing is similarly so much more than the software.
*: As mentioned in “How to test in IT Operations” at Nordic Testing Days 2016.
April 22, 2016
Enterprise IT, Softwaretesting
atWork, collaboration, communication, community, knowledge, leadership
Apparently my Internet habits are very teenage like… I miss my WiFi and cannot leave the phone in the pocket. What I am is a digital settler, connected to my processional community.
I realized this at a training recently, where it was noticed that I had my phone out DURING CLASS. Was it FOMO – no, I just had a thought about testing to share on twitter. As I would usually do during conferences and my working day. We had a good laugh about me always needing my internet and my phones. I took it as a compliment, as that would mean that I was a YOUNG digital rookie, sharing and collaborating. .. like only the cool kids would do.
When I model myself to the Teaching Trios model
– I am a digital settler by age/ introduction time. But collaborating and having an online professional interaction is not based on age, nor should it be frowned upon. Online community interaction is done by all ages, diverse and really nothing new. It’s past hype, and not ground breaking. There are models now of how communities evolve and function
. And the business, career and personal benefits explained over and over again.
Yet I have more followers on twitter than the company I work for. Sometimes when someone else at work shares curated testing papers, I have seen it already and have met the people who wrote it. (Read Meet the famous people)
When I model myself towards Simon Wardley
‘s three-stage model (Pioneers, Settlers, town planners
). I don’t jump anything brand new, but I do want to take the groundbreaking and turn it into a framework for others to succeed… So to my kids Netflix is TV, and my mom follows me on Facebook to see what I’m up to. (no good
, I swear).
April 3, 2016
atWork, brain, business, collaboration, communication, community, knowledge, learning, sharing, She4He, value, WomenInTech
Treat your testing people as knowledge workers, not rote industrial resources. The later is a spiral to the lowest value, the former is about giving the business valuable knowledge. A modern tester is a knowledge worker – whose prime area is finding information, filtering information, relating information and presenting information. It is a non-linear process, that requires a touch of both creativity and consideration.
The best testing tool is the brain, and the knowledge worker ponder the problems both consciously and unconsciously. She can work without using the hands or legs, but not with a simple headache. It takes a lot of thinking and collaboration with the stakeholders to identify what questions about the product has value to the business. The (context-driven) knowledge focused tester focus both that it works, and that it adds value to the business.
The business focus are far from the classic mindset of testing established around the millennial (2000). where testing is about finding defects and going through the motion of deriving test cases from specifications. – I know I’ve been there. That era is long gone, even dead at some time to Whitaker and Alberto Savoia. Be provoked or even insulted, but it’s the future.
But wake up – it’s not where the testing world is today. The old tools of design techniques and coverage metrics makes less and less sense to the business. They are old-school and classic approaches, in the not so cool way. The cool kids on the block are poppin’ tags – getting new stuff, sharing and exploring. They know that change is the new normal and that what works in one situation doesn’t work in another. Their primary concern and focus is getting knowledge to the decision makers. They are the knowledge workers
January 12, 2016
Enterprise IT, Softwaretesting
atWork, collaboration, control, indian colleagues, leadership, management
One of the ways I lead the team of testers in my project is through delegation of power from my own role…
1) A test manager in my group asks guidance. The members in the project team does not reply her requests or give her the information she needs. As a test manager in the project she does have the theoretic power, but not the practical power… I send her back with all my powers – to tell them that because I said so, they should respect her. I don’t mind taking “stars” of my shoulders and giving the power of my role and position to someone junior to me.
2) A tester on my project team approaches me to ask for permission to create tasks on our task board. I immediately grant her a “do every thing you need to do, without asking“-permission. By all means take the initiative and ownership. I probably fail to manage everything, so we need to work together on this. By all means go ask the developer, create test cases, find things we didn’t know – think.. and test.
Sometimes I think, this is perhaps a Danish “equality” culture – but then I realize it is a collaborate approach for the modern knowledge worker. It works equally well with people from both India, Denmark, Philippines and China.
My style is not to CONTROL – but to facilitate KNOWLEDGE. In my team the team is the star…
December 18, 2015
Family and fun, LEGO, Softwaretesting
acceptance, AFOL, atWork, geeks, oracle
One of my coworkers had gotten himself a LEGO 10242 MINI Cooper, and by the help of the other consultants it had been build (to spec?). We look over the remaining pieces and discuss how come. All the 1×1 plates are quite expected, there are extras of these because the weights aren’t that precise and the pieces are cheap. Also customers easily loose them, so it’s cheaper to send some extra than to handle through customer service. On BrickLink inventory there is even a fan made list of the usual extra items….
But an extra black 2×4 plate – naa. That’s odd.. And surely it missed on the bottom of the car. I had prior knowledge .. but have not built this exact set.
Now I have another hunch that the two gray 1×3 tiles and 1×1 dark green bricks in to the rear are missing somewhere. A good thing those consultants have a test department, one could say… Still the pieces seem not to be 1-CRITICALLY missing, so the model is DONE and accepted. So even if the LEGO tester gets to ask “what if” – we have to remember to hear the answer to “does it matter” – even if it is our favorite hobbyhorse
December 7, 2015
Autism, Family and fun, Softwaretesting
atWork, business, change, collaboration, context, decisions, eurostar, LEGO_friends, value
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!