In agile delivery teams, it’s recommended that stories and features are discussed before being developed. A checklist called “Definition of Done” can be used as a reminder to check that the delivery team has everything needed to prepare the delivery of the feature. A key ingredient is a shared understanding of how to confirm the delivery – for the whole team.
Story shaping requires at least three people to get together. They are not amigos nor amigas. They are often three, sometimes two people, and often more. They represent the different viewpoints needed to deliver: builders mindset, testing mindset, security mindset, operations mindset, business mindset, etc.
No one person can hold all these viewpoints – at least a builders mindset and a requester/business mindset is needed.
If you skip doing story shaping your acceptance criteria and testing activities will be misaligned. And you will either have overdone the effort needed or underestimated the challenges of the story.
Thank you to all who have replied to the tweet below.
remind me: what was the better name for the collaboration formerly known as "three amigos"?
There are so many different IT projects out there – that assuming every IT project is about source code is quite a blind spot. Projects that deal with commercial standard systems or outsourced software might have source code underneath – but many teams does not have access to the source. Additionally, many legacy systems from the 90’es and older does not have the same automation capabilities as we have now.
Not all software projects are about consumer facing native apps and websites. While they are numerous there’s still plenty of systems out there for internal and business-to-business use. While the trends from CI/CD are picking up for B2B and internal systems, things doesn’t move so fast.
The testing activity has been under change for long. And it’s clear that the testing activity has shifted. Even the test managers have to re-calibrate – as other roles will be doing the test management activity. Be prepared, as someone else will do your testing job. Work on building self-reliance in others and be prepared to hand-over what you can do.
I often find myself as the only testing person on the project. The testing activity is done by automation specialists and end users in one project, and by technical operations staff and end users in another. In these projects either the technology or the business knowledge is paramount, and not so much exploration, flaws and edge casesfor specialized testers to explore.
Similarly for the test managers – there’s a trend/shift, that sometimes the test management activity is shifting away from the test managers. Even to me – even if I’m sometimes more an a “project manager of the testing activity“, a “Test coach” or similar. The trend is already there – coined sometimes as “whole team approach to quality“. Yes, most of the test management activity can be done by scrum masters, Release Train Engineers and even project managers ….
Recently I was asked to assist a large transition project for a holding company with many brands. Each brand had their own applications and technology stack, but the holding company had decided to move the hosting. So the holding company’s Project Management Office (PMO) was put in charge of facilitating the brand’s testing activities – an activity they had never considered nor done before. My role would only be to provide guidance, not do the actual facilitation.
Which got me thinking….
What if the testers, are not testers – but other "titles" doing testing. And what if the facilitation of this activity is done by – others than test managers
And after some deep thinking. – I do have the privilege to be able to adapt. I don’t need to hoard knowledge or make power moves (anymore) or worry about health-coverage or any of the lower Maslow pyramid terms (anymore).
It’s very natural for me to hand over project approaches to my co-workers. I’m often on the “blue team” to outline the strategy, My best field of work is to bring clarity and consistency, not scalability or repeatability to the practise.
I naturally hand over learning anyways, so why not re-calibrate when the thing I do has reached a stage, where it’s repeatable. And then focus on building the skills in others, work myself out of the test management role as we know it.
And don’t worry that someone else will eventually do my (testing and test management) job. The first step is to acknowledge the trend/pattern, second to redefine and bring clarity! Let’s explore and see what we find!
Someone else will do the building, not Emmet. Their task is repeatable.
You, yourself, is responsible for getting the training, learning and knowledge you need. Don’t wait for your boss – be proactive, it drives your success. Here are some places to start:
Meetup’s are happening online now, which removes one primary barrier to attending great talks. Similarly conferences go online, some with a fee, some for free – some even in multiple time zones. Lastly online training sites are abundant with relevant information for the challenges you have. Yes – also for you!
With plenty of talks about risk based testing, test management in the light of automated deliveries, BDD etc. With live slack groups the experience is almost as the physical conferences :). Next up in may is the Online Test Conf, Spring 2020 with topics for everyone in convenient global time slots.
When your boss says there’s no budget for attending conferences in person this year (again!), there are other ways to attend – physically. You could try to submit a talk and get accepted, but the barrier is quite high. A great way is simply to reach out and volunteer to help the program committee. If you can time it, with regards to the budget year, ask you boss based on the conference program aligned with your company strategy. At least what the boss should do is to allow it to be company time – else take the time off. …
If you are hungry to learn
What I see in the global testing community is that Scandinavians are complacently waiting for the company to pay time, money and effort to their learning, while people in emergent economies (Hi Sfax and Argentina) are eager to learn and on the forefront of the trends of the trade. They are driving the change of a positive inclusive community.
Among the currently shiny new test automation things are visual “script-less” test automation tools. But the visual test flows are still code – and thus require discipline to structure and maintain. Otherwise you are just adding yet another layer of spaghetti code.
Among the current shiny new test automation tools are visual “script-less” automation tools like LeapWork [9], Blue Prism [10] and UiPath [7]. These tools are a part of a new class of business process automation tools called “Robot Process Automation” (RPA) [4]. There are two sub types of – “RPA” which focuses on processing data and Robot Desktop Automation (RDA).
RDA is interesting in the context of test automation [9], as they can automate GUI interactions – also on top of enterprise package applications (SaaS, COTS, OOTB etc. [2]). The test automation challenge for most of these enterprise applications (SAP, MS Dynamics [6] etc.) is that they come with no access to the code-base, even if these are pure-play web based – the GUI is all there is.
All you can to these type of business solutions is usually to add customization and configurations by entering or editing data directly in through the GUI. Some of these systems allow configurations and customization in the form of config-file – they really should be under change control [3], as they are part of the pipeline.
visual tests are code
part of the ship
part of the crew
Bootstrap Bill Turner
Using RDA tools for test automation [9] is a novel [1] uncharted approach [12]. The editing of the “tests”/flows is usually done in a stand-alone application studio (Graphical IDE) with interactions to the solution under test (across the GUI and over Citrix and RDP) and to any test management and issue tracking system.
Interestingly the other more “data processing” RPA tools like Automation Anywhere [5] uses a VB-Script like syntax. Writing and maintaining “scripts” like that is quite like the common approaches to GUI automation using frameworks like Siluki, tagUI, Applitools [11].
Applitools
etc. are coding frameworks you can apply if you have the application code base
or want to write test automation directly as code. There could be benefits in
coding UI testing in all web-only projects directly using Selenium and Applitools.
Most enterprise business solutions are often stand-alone applications, or their
web code is horrible to hook into, as often the selectors seems randomly
generated (been-there-done-that).
Hence the primary driver for RDA adoption in for test automation is to take the RDA & RPA [4] tools and apply their strengths in process automation of enterprise business solutions [2] to drive the test execution. And of a business flow could be “automating” activities during onboarding [7] or an SAP purchase order as below images:
Another key
driver for adoption of RPA for test automation is their visual approach in presenting
interactions/tests as flows. Some do it gracefully and user-friendly (LeapWork)
– others have a more old-school workflow/swim lane approach (Blue Prism, UiPath).
In both cases the visual flows illustrate an interaction across multiple GUI
applications to perform business actions (yes, this still happens).
These drivers probably to make the barrier to entry seem more manageable. The visual ones very easily turn into visual spaghetti code if you don’t keep an eye on it and use sub flows, low coupling and high cohesion [13]. … as with any other non-trivial code (of a certain McCabe complexity [14]). One interesting way to go about a “coding” practice for visual test cases could be inspired by how BDD can be implemented in LeapWork [8] with annotation and self-referencing unit tests.
At the end of the day even a visual test automation project is a coding project, that should be part of the project code base like everything else [3]. And probably best maintained by software engineers within the project team (where possible) – unless you want a team of test engineers spending all day playing catch-up to maintain the automation code.
Since 2017’ish.
COTS/OOTB = Commercial of the shelf, out of the box
I believe it is possible to have challenging opportunities and career advancement within the broad field of testing – for all kinds of people and backgrounds.
I’m probably both spoiled and privileged, so see down below for context of the following model. It is a model for career paths that is in active use as of writing. Some might consider it old fashioned or limited, but I do hope that you can learn a bit from it with regards to defining career paths for testing specialists.
Let’s look at the following titles:
Tester,
prepares test cases in a test case management tool
performs the testing activity
Technical Test Analyst,
prepares and initiate engineered tests
Test Manager,
prepares test plans, test strategies
lead the testing activity
You might have other titles at your place – the point is to identify the titles and not take the work areas too literally. On smaller delivery teams the testing specialist is both the analyst, test manager and the one performing the tests. On larger projects there may be more testing professionals with more defined roles/titles. On other projects the test managers job is more around leading SMEs in testing (and less the testers).
Notice that the test manager manages the testing, they are not a people/line manager of the testing specialists. All the testing professionals may have the same manager or be distributed into the delivery teams. That usually depends on if the company’s focus is on consultancy/projects or on products/deliveries.
Based on the titles above you can identify the work usually being done, but not the skill level or span of control. This is where we usually add (promotion) levels like:
Junior
Advanced/Associate
Senior
Principal
Do use the promotions that your company uses for developers (and similar titles) and other roles! If you have ninja developers as a formal promotion level over lead developers, the by all means add that to your testing titles as well. Do insist and argue! If you fail, move away and let that company deal with not wanting to improve their people. (having the option to turn away can be a privilege too).
The levels of formal training could follow the levels of promotion. ISTQB training is one approach that is similarly scaled. That can be helpful if your organisation has a quest for certificates (for some business reason). Certificates are though just a race to the bottom.
The advancement from one level to the next could be on the basis of independence of the person. A junior level is an entry level and will usually require that the person tries it out and have a skills mentor. Advance and associate levels apply the know-how consistently on one project/delivery team.
The higher up the level, the more teams the person can apply the knowledge to at the same time (span of control, see also the law of raspberry jam). Alternatively it could also be to be able to generalize practices learned in one project and apply it to a project/delivery team that works in a different way. Senior and principal roles is more into the strategic work or work as a adviser. They could be the advisers on bids & tenders for new projects or be more of an test architect working with implementing principles for the testing activities.
Context: I work in the Danish IT outsourcing sector in a global IT company of 3000+ people. The software testing team working across projects is 30+ people (globally). The title “promotions” are used consistently in the company for various job titles: Developers, project managers etc. I have applied a similar model for 20+ testing people at other outsourcing companies and the job titles are consistent with similar software development companies in Denmark.
Denmark is a country where trust in others is very high, where there is a high wealth equality level (Gini) and where privileges are equal privileges. In the company 30% is female, with many female “middle managers” and also high in the technical hierarchy.
I honor of the World Autism Awareness Day 2017: I have reward systems for myself and my two sons with autism. The principles are as follows:
Reward the behavior we want more of. Don’t reward required activities, but reward when we choose to do help with chores. Ignore when we choose not to, do not remove credits.
Rewards are things you would not get otherwise. Verbal praise and encouragement are given even so. You have to earn it – and get it when you finalize (a deal is a deal).
We use token economy and postponed gratification. Training for the mash mellow test improves forward thinking.
Rewards are usually LEGO. Specific piece request from Bricklink. Every token/mark is a ten’er (DKR 10).
The teenagers (13+11) have been rewarded for doing the dishes, preparing food, taking out the garbage etc. Initially 15 tokens gave a trip to McDonalds, but as mastering progressed the rewards became bigger. One time 50 tokens/marks was needed for a reward. The options to help (“The Mark Menu”) was at one point over 20 chores. Over time they lost interest in saving but did the chores anyway, so some of the chores where made required. One day the oldest added “Do not fight” to the list of required (non-rewarding) activities 😉 Next up is to save for a game on Steam..
I’m being rewarded every time I run (5K, outside. Half a mark for treadmill), for my morning exercises and a few other thing I struggle with. I have just finished a sheet of 140 marks that I worked on since September 2016). The new target is to buy myself first a Bugatti and then a McLaren. Not a new minivan..
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 them 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.
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.
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
Complexity is a Matter of Perspective 