Skip to main content

Manumation, the worst best practice.


There is a pattern I see with many clients, often enough that I sought out a word to describe it: Manumation, A sort of well-meaning automation that usually requires frequent, extensive and expensive intervention to keep it 'working'.

You have probably seen it, the build server that needs a prod and a restart 'when things get a bit busy'. Or a deployment tool that, 'gets confused' and a 'test suite' that just needs another run or three.

The cause can be any number of the usual suspects - a corporate standard tool warped 5 ways to make it fit what your team needs. A one-off script 'that manager' decided was an investment and needed to be re-used... A well-intended attempt to 'automate all the things' that achieved the opposite.

They result in a manually intensive - automated process, where your team is like a character in the movie Metropolis, fighting with levers all day, just to keep the lights on upstairs. Manual-automation, manumation.

Metropolis (1927)

The answer is to use... Sorry, I don't have a magic tool, with a funky name, light-hearted ReadMe and a 3 word install command.

When presented with this situation I advise people to take a step back. Think about what they want for their team, and themselves. We want to deliver faster and easier right?

Often removing a tool, can save time and work. Could that complicated deployment system be replaced with a 5 line bash script?

Could that test suite, focus on the sort of techniques computers are good at? (reading and writing to APIs at speed, randomisation, graphing, comparison/diffing of complicated documents etc.) Many teams fall into the trap of 'look no hands' as if they are trying to spin plates rather than build quality software, fast.

Sounds simple, but when people are wedded to a tool or an idea of how things 'should be' because it was in that book - by that guy "its a best practice!" then it can be difficult to get things simplified.

Step back before things become comical. Safety Last! (1923)

But simplification is often the easiest and quickest place to start. It rarely makes sense to mix in more, to something that is already a muddle. If your team is already manually keeping the 'automation' going, then letting someone do the process manually - for a few hours will probably help you figure out what can be reliably automated, and what are the sticky complicated bits - people are quicker at doing.

Software testing is often overtaken by the above sort of [broken] tools feeding frenzy. The look no hands evangelist, may have had great ideas, but did that suite of tests really make your life easier? Did it free up time for finding the important bugs? Or are you now finding the real bugs in the test automation, while the software your product owner is paying for is hobbling along slowly and expensively to production?

Comments

  1. I know what you mean. I've seen these everywhere. Automation that was supposed to save time, but ended up requiring more work to maintain by hand. Especially in software testing.

    But any automation is code at the end of the day. And poorly implemented automation is simply code with code-smells. And tests created with many of these software testing tools are rife with poor code hygiene, such as hard-coded IDs, magic waits, and un-readability that compromises the maintainability of the tests (and sanity of the testers/developers).

    We need better tools that work for us, not the other way around.

    Oh, and if you are looking for an robust way to automate testing for web apps, try UI-licious (https://uilicious.com). I'm the maker of it, and I gladly invite you to try it and tell me if this is still manumation needed. ;)

    Shi Ling
    @taishiling (twitter)

    ReplyDelete
  2. Thank you for providing this information. Visit us for Getting Best PYP Online Courses at Affordable prices.

    ReplyDelete
  3. Delving into the world of software investigation unveils intricate layers just like the precision of chemical injection pumps in Dubai. Both require careful analysis and execution to ensure seamless outcomes.

    ReplyDelete
  4. It's interesting to observe common patterns among clients. Just like the meticulous attention to detail in ourCar Detailing Ottawa understanding these patterns can help tailor solutions that meet their specific needs and preferences effectively.

    ReplyDelete
  5. Spotting patterns is key! Unlock success with our Rig catering services in Texas, where precision meets satisfaction. Elevate your workday routine and let us fuel your productivity.

    ReplyDelete
  6. Manumation, the worst best practice" delves into the intricacies of automation in manual processes. Just as efficiency is sought after,Mobile Car Wash services in Ottawa offer a hands-on approach to keep your vehicle pristine. It's about finding the right balance between automation and personalized care, whether in business practices or vehicle maintenance.

    ReplyDelete
  7. "Spot on observation about 'Manumation' – that delicate balance between automation and manual intervention. Much like the intricate dance, indulge in the nuanced harmony of شوكولاتة بالملح (chocolate with salt) to sweeten the complexities of the tech world."





    ReplyDelete
  8. "متجر شوكليت الرياض" invites you to explore a world of delectable indulgence, offering a curated selection of premium chocolates and sweet delights. Immerse yourself in the rich flavors and luxurious offerings of Riyadh's finest chocolate emporium.





    ReplyDelete
  9. Manumation, the worst best practice" certainly rings true as a cautionary statement in various industries. While automation is meant to enhance efficiency, relying solely on it without considering human elements can lead to unintended consequences. Shifting gears, if you're in Ottawa and seek a convenient car cleaning solution, Mobile Car Wash services in Ottawa offer the perfect blend of technology and personal attention. Embracing the convenience of mobile services ensures your vehicle gets the care it deserves without compromising the human touch in the process.

    ReplyDelete

Post a Comment

Popular posts from this blog

Betting in Testing

“I’ve completed my testing of this feature, and I think it's ready to ship” “Are you willing to bet on that?” No, Don't worry, I’m not going to list various ways you could test the feature better or things you might have forgotten. Instead, I recommend you to ask yourself that question next time you believe you are finished.  Why? It might cause you to analyse your belief more critically. We arrive at a decision usually by means of a mixture of emotion, convention and reason. Considering the question of whether the feature and the app are good enough as a bet is likely to make you use a more evidence-based approach. Testing is gambling with your time to find information about the app. Why do I think I am done here? Would I bet money/reputation on it? I have a checklist stuck to one of my screens, that I read and contemplate when I get to this point. When you have considered the options, you may decide to check some more things or ship the app

XSS and Open Redirect on Telegraph.co.uk Authentication pages

I recently found a couple of security issues with the Telegraph.co.uk website. The site contained an Open redirect as well as an XSS vulnerability. These issues were in the authentication section of the website, https://auth.telegraph.co.uk/ . The flaws could provide an easy means to phish customer details and passwords from unsuspecting users. I informed the telegraph's technical management, as part of a responsible disclosure process. The telegraph management forwarded the issue report and thanked me the same day. (12th May 2014) The fix went live between the 11th and 14th of July, 2 months after the issue was reported. The details: The code served via auth.telegraph.co.uk appeared to have 2 vulnerabilities, an open redirect and a reflected Cross Site Scripting (XSS) vulnerability. Both types of vulnerabilty are in the OWASP Top 10 and can be used to manipulate and phish users of a website. As well has potentially hijack a user's session. Compromised URLs, that exp

Test Engineers, counsel for... all of the above!

Sometimes people discuss test engineers and QA as if they were a sort of police force, patrolling the streets of code looking for offences and offenders. While I can see the parallels, the investigation, checking the veracity of claims and a belief that we are making things safer. The simile soon falls down. But testers are not on the other side of the problem, we work alongside core developers, we often write code and follow all the same procedures (pull requests, planning, requirements analysis etc) they do. We also have the same goals, the delivery of working software that fulfills the team’s/company's goals and avoids harm. "A few good men" a great courtroom drama, all about finding the truth. Software quality, whatever that means for you and your company is helped by Test Engineers. Test Engineers approach the problem from another vantage point. We are the lawyers (& their investigators) in the court-room, sifting the evidence, questioning the facts and viewing t