How would you go about testing additional work done that is out of the scope specified

In my experience I’ve been told not to test any additional work that was done outside of the scope specified by the user story in the sprint, for example a loading bar that wasn’t in the mockup of a page or a bug found and fixed while adding something else to a piece to code.

I’m interested in how you all would handle such a situation.

My current interpretation is that depending on the risk involved I should advise the product owner that this should be checked.

1 Like

What was their reasoning behind you not testing anything beyond the scope of the story?

Is it time? Concern over scope creep? Misunderstanding on their part what testing is?

Do you work off detailed and specific test scripts, or do you have more flexibility with exploratory testing and using test charters?

If you were to raise these things, who would you raise it with, and what would they do with it?


Was that just added by dev without PO or team involvement? I would talk to dev to understand the reasoning behind the additional bit. I would cover it regardless because it will be in production tested or not. Then, it may be a good idea to understand and highlight it to the team, as well as making sure it does not make things any worse if not better :wink:


This question needs an answer that depends on the project and its processes. And often one person cannot answer it alone.

Olli is right that there are risks and priorities, and the product owner needs to know. Nufenix asks the important questions about why, resources, and who decides. Testerawesome asks how, recommends communication, and suggests testing anyway.

I think the point of the question is that the change is out of process. And whether the “additional work” is absolutely necessary, or the good idea of someone with spare time, this release and future schedules should not be jeopardized.

If this is a small project, it may be easy enough to get agreement on the additional work (its risk, whether to include it). However the advice in olli’s question, “not to test any additional work that was done outside of the scope,” suggests a larger project with a dysfunctional organization. So this is an issue for management to address.

@nufenix in answers to your questions, it’s a small team of myself and the test manager and I’m 100% sure that time was the reason behind it.

There aren’t any hard and fast rules for what we use to test i.e. charters or test scripts, just as long as it’s documented.

And for the final point it would have to go to the acting product owner, but I’m not entirely sure how that would go.

@testerawesome this is by a Dev without any PO or team involvement.

Thanks for all the advise


I agree that this may well be an indicator of a dysfunctional organisation.

In a previous life, the strict remit of the testing team (two of us) was to test applications that the in-house devs had created. (Not that anyone told us that that was our remit until I raised issues from stepping outside it.) This meant that when the company bought third-party applications in, or did IT work that didn’t originate with the in-house dev team, such as the company website, no-one tested these things.

That meant that when third-party apps were stood up on our network and were supposed to interact seamlessly with existing business workflows, no-one actually checked that for correct functionality in any methodical way. It meant that the website was never checked for content or functionality. It meant that when third-party apps were deployed, they weren’t checked for embarrassing failures, such as an online teaching tool having an appallingly obvious typo in a big caption over the top of a voiceover by the CEO, or relying on completion of one module before moving on to the next but the hand-off of the first completed module not completing properly and so preventing users moving on to the next.

I had an oh-so-polite argument with the board member responsible for IT over this sort of thing. I pointed out that we weren’t doing user acceptance testing, which when we were paying for stuff was not a good idea. He disagreed and said that I should stick to my strict remit (see above). He won. (Funnily enough, we are now good friends - online, at least.) Six months later, after he’d been let go and I was on the same path, the company went public with a new office and issued a social media post saying “Click here for a virtual tour of our fantastic new city centre offices!”.

Guess what. The link didn’t work.

I took a certain amount of pleasure in posting “You’d think someone would have checked this before publication. Oh no! I forgot - you SACKED all your testers!”

It is in the nature of testers to test. Yes, there may be limits to the testing that you do and report within the framework of a particular project’s timetable. But that should not stop anyone from exploring the app further if they have the time and ability, and offering to report issues no matter where they spring up. If nothing else, making a private note of issues discovered so that later on you can lay them on the table and say “I told you so” should highlight the spaces where an organisation’s dysfunction is harming them. The rest will be up to the management.