Operational Acceptance Testing. There’s a woolly phase of testing if ever there was one. Not everybody understands it, not everybody does it. But the fact is, every test manager should consider OAT to some degree prior to a significant system or change going live.
Without OAT, the risks of disruption to service can be considerable. How would your business stakeholders feel about an application being offline indefinitely due to the fact there was no change backout facility? How confident are IT ops that they can restore from backup if an application change corrupts the database?
Here are a few checkpoints that may be pertinent to consider when thinking about scope for an Operational Acceptance Test plan.
I’m pleased to announce I have just started a new contract with Unilever.
From the Unilever website:
No matter who you are, or where in the world you are, the chances are that our products are a familiar part of your daily routine.
Look in your fridge, or on the bathroom shelf, and you’re bound to see one of our well-known brands. We create, market and distribute the products that people choose to feed their families and keep themselves and their homes clean and fresh.
My role at Unilever is Test Manager for an internal Joiners/Movers/Leavers process to be rolled out initially in the UK. I’m responsible for Integration Testing, Service Rehearsal Testing, and UAT, as well as suggesting process improvements and making recommendations for future testing.
This contract fulfils a lifelong ambition to work for a FMCG company, and I’m very excited about this project and the possibility of future projects with Unilever.
When everything is going wrong and you’re spending most of your day putting out fires on projects, it’s easy to think project management is more art than science.
If you want to improve the chances of success in your projects, this list of ten common problems is well worth considering – covering everything from organisational culture to improper management of risk.
Read the full article over at PMHut.
Testing doesn’t have to wait until business requirements have been defined. Testing can start right at the inception of a project – by providing a level of assurance that new systems or proposed changes to existing systems will deliver real business value.
The traditional approach
Traditionally, testing has always been “that little bit at the end” – the part of a project that gets squeezed and squeezed as the other milestones slip, while the final delivery date remains immovable.
What if we could turn that round? Imagine if it were possible to start testing early on a project – not just from the requirements stage, but from the very beginning of a project when an idea for change is first conceived.
The Agile manifesto has been around for over a decade, and Agile remains one of the biggest buzzwords in the software development industry.
Despite this longevity (a decade is a long time in the IT world), few people really understand what Agile is. Some see it as a form of rapid software development, others see it as simply an excuse not to produce documentation.
So what exactly is Agile? In this great collection of posts, Kelly Waters explains how (put simply) agile development is a different way of managing software development teams and projects.
Read the 10 Key Principles of Agile over at AllAboutAgile.com.
As with all leadership roles, one of the most often overlooked aspects of being a good test manager is the need for pursuit. Pursuit of excellence, of elegance, of truth, of what’s next, of what if, of change, of value, of results, of service, of knowledge. Great test managers are never satisfied with traditional practice, static thinking, conventional wisdom, or common performance.
While this article isn’t written specifically with test managers in mind, we can all learn something about the value of being a ‘pursuer’, and how we should question ourselves before automatically embracing the status quo or adopting ‘cargo cult’ practises.
Read this excellent article about leadership over at Forbes.com.
Depending on the context, a little stereotyping can be fun: we can all recognise how we fit one or more groups based on our class, beliefs, earnings, or other demographic factors. However, stereotyping can also be damaging, particularly when it comes to careers.
Have you ever stopped to consider how stereotypical you may be as a software tester? This blog post touches on a few common testing stereotypes, and links to a couple of interesting articles about how you can avoid stereotypical behaviour in your testing career.
(Don’t miss the link to the TestingGeek’s ‘Wrong Reasons’ article!)
Read the post in full over at the uTest blog.