As of writing I am managing the testing of a large enterprise IT program, where we are implementing a new commercial enterprise solution (COTS).
Over the last many months there have been requirement workshops upon requirement workshop to write down what the new system should be able to do for the various business units. We have had many representatives from the business units as part of the workshops and now have about 1000 specific business requirements that needs to be tested.
Some requirements are closed questions, others are more open-ended or similarly require some thinking. Currently the ratio is that 70% is done by test automation and 30% is for a few of the subject matter experts to test. Management was happy with this, as this made the project faster, the solution more robust and the project less reliant on taking the business people away from their “real work”.
The other day I reached out by mail to more of the business people involved in the workshops to let them know that testing had started, and that they would be able to access the solution under test when it had been “hardened”. But so far, only a few “track leads” would be involved.
The feedback surprised me, as my message was both good and bad. Good in the sense that they would not be involved so much, but also bad that they would not be involved so much. One wrote back to me:
- There is still a risk that the solution will not be as the workshops intended, as the requirements and solution might not capture precisely, what was agreed during the workshops
- Having been part of the workshop, we are held responsible by our coworkers as to how well the new system supports the business
- Why don’t the project want our involvement on this?
... but that was “just feelings”, they wrote in the end. And indeed it is – No matter how it looks at first, it’s always a people problem and even if we have a successful test automation effort – we can still fail to appreciate the experts knowledge and by that fail to solve the business problems.
More about “Leading when the experts test” at ConTest NYC 2019.
7 thoughts on “How Automation Affects the Business”
[…] How Automation Affects the Business – Jesper Ottosen – https://jlottosen.wordpress.com/2019/09/21/automation-affects-business/ […]
Question: did the workshops have easily-defined outcomes that were recorded anywhere (preferably in hard copy!)?
I ask because “There is still a risk that the solution will not be as the workshops intended, as the requirements and solution might not capture precisely, what was agreed during the workshops” sounds as if that particular user (and their constituency) are likely to find fault with anything that emerges from the process, no matter how well it fits the finalised requirements. They may need hard evidence of what really was agreed waved in their collective faces. Then any amount of “yes, but” will not amount to anything. (Unless they have someone senior in the organisation backing them. The only way around that is to do your best to make sure you have somebody more senior backing you.)
Ah, I love the smell of office politics in the morning…
LikeLiked by 1 person
Hi Robert, Great feedback – Appreciated!
We do have lists and lists of requirements, but I know that even they will have bugs…
It’s the same ones as mentioned here:
[…] How Automation Affects the Business Written by: Jesper Ottosen […]
[…] application of standards and obligations and who gets to do the work – that we forget to align with the business side of things. And thus the beatings continue until morale improves – if you don’t align […]
[…] and rule-based confirmations of features and functionality. While the UAT would focus on the more business visible and more intricate activities. In case there is UAT at all – but for large public and enterprise deliveries (B2B) there sure […]
[…] In one project where I added automation, we have run nearly 8000 automated runs in a year (and 200 SME-based). We actually run the tests more often, and we cover the important things every day – and […]