Iām on a team that is agile-like. I know that immediately raises at least the caution flag, but hey, itās what Iāve got.
We use JIRA to manage our stories, and one thing weāve insisted on for a while is the presence of Acceptance Criteria for each story. So far, so good. But hereās my problem:
Sometimes while working on a story, the original idea for the change is abandoned (business user changes mind, or itās not a workable idea, or whatever). But the developers are utterly unwilling to update the JIRA to show what was actually implemented!
Results are as you would think: I pick up the story, I try to test it, it fails spectacularly, the developers say āOh, thatās not what we did.ā Utter waste of my time. Iāve brought it up in retrospectives, Iāve tried handling it privately in emailsā¦ they are always āsorryā but do not change their behavior. This happens about every six to eight weeks.
Short of actual mayhem (so messy), any advice to better enforce what I feel is simply common sense??
How agile-like are you? If youāre having standups or participating in reviews, it seems like test should be aware of the changes to the story, and in the whole shift-left mentality, you should be pushing at that point that the story needs updating (or updating it yourself).
I think youāve done the right things by mentioning this, but since itās not getting addressed, you should likely work on being a squeakier wheel. I tend to reject stories pretty quickly if they fail a smoke test, and it goes back to the dev who implemented it. Itās not clear to me from your post what happens in your world right now (e.g. does the story ever actually get updated?) In any case, pushing it back/rejecting it puts the burden on the guilty party to fix it. It does make you a bit of a blocker (i.e. not testing a story till itās in a testable state), but I donāt think thatās unreasonable.
We are non-agile-like in that we seldom have the whole team working on one story at a time, so our daily standups cover basically āIām working on this; I need help/donāt need help because itās going this way.ā So changes to stories are not covered in standuup.
When I reject something as a test failure that falls under this category, I get a sheepish visit from the coder who says, āErā¦,ā and then I make him dictate the story update to me while I typeā¦ I kind of have to do this if Iām to make any progress with test, because otherwise I may wait >1 day before itās updated. I suppose I could just refuse to test until he/she updates the story.
Can I ask have the team leads or managers publicly supported you with this change of process or are you still trying to implement this yourself?
The reason I ask is I have been in situations which a similar ie the testing resource needs the development resource to change a legacy process that is impeding testing. In one situation the technical development lead supported me publicly and within the team so the change was implemented, slowly but surely.
A different situation the management supported me publicly but not within the team so nothing happened. Unfortunately it also affected my relationship with some of the development team and it ended up being a toxic environment for a thinking tester.
If you are able to provide some resource wastage figures for testing say over a couple of releases, then have a chat with the development lead and get him/her to buy into the change possibly it will hasten the process. I am sure with all your experience you have done this a million times and donāt really need any direction from me but just to let you know you are not alone in what your trying to achieve.
Talk to the devs before starting to test the story and confirm everything is up to date on Jira. Agile is about more communication and individual interactions and less about processes.
Donāt make people do stuff, would you like him to make you do something? Instead, ask.
Sounds like talking is working though. You could just talk earlier to avoid sad faces and see how that works out for you and your team.
Well, you have run a few experiments and looks like it is unlikely they will change their behaviour. Lead by example and change yours!
I get a sheepish visit from the coder who says, āErā¦,ā and then I make him dictate the story update to me while I typeā¦ I kind of have to do this if Iām to make any progress with test, because otherwise I may wait >1 day before itās updated
I think with a slight modification this is probably a good behaviour to get into to. Before beginning testing on each story do this - You are then essentially driving the collaboration, and perhaps by persisting with this approach the team will see the benefit (and possibly realise that it would be easier to update first). Even better is to try and get involved as soon as possible and ask questions regarding the feature - if you can get early builds keep asking questions relating to the software and the story. You will at least know what is going to be implemented. You can make statements about the suitability of the software, and what testing has been performed without the story being updated if you know what the product is supposed to do and who the stakeholders you are representing are.
Even though we donāt practice a traditional agile approach where I work the collaborative spirit is very much alive and kicking, and we will spend time supporting developers in lots of testing during active development. We all know that things will dynamically change during development and unless youāre in some highly regulated industry then the documentation is going to be the last thing (if it ever is) to get updated. We often end up in the situation where our documentation is only updated weeks after we have finished testing, but by collaborating with the developers, product owner and any other stakeholders we can get our hands on we can be confident that we have built the right thing, and by using our general testing and product knowledge we can be happy that have done a good job on looking for show stoppers.
I think the previous advice to change your behaviour and hope the team will see sense and follow is good.
The thing is, the team agreed to make it a team rule to update the Acceptance Criteria if things changed. Soā¦ Iām getting agreement but not action.
I can certainly try to always talk to the devs before starting to test a story (though we donāt all work exactly the same hoursāsometimes that might not work). This might save me time overall.
When I say āI make them tell me the actual acceptance criteriaā I am not actually pointing a weapon at them. I am looking at the JIRA and saying āokay, if you tell me what the user actually agreed to, Iāll type it in here for you.ā They could conceivably refuse and rush away, but no one has actually done so to date.
I would absolutely love be involved earlier, but my team is working on four things simultaneously and Iāll be testing all of them. (We have a tiny waterfall that wants to be Agile but isnāt.) Your suggestion is my ideal. For the biggest projects I do this, but otherwise I canāt.
You are definitely describing a previous contract I had. Our issue was build releases directly into test environment (while I am testing) without any notification. Everyone on our team agreed to notify the single tester (myself sitting right beside them) but the senior developer had his own agenda and always seemed to just forget. All the junior devs followed suite and it was chaos for each release. Nothing changed and I tried everything including feeding devs home baked cookies lol. Once there was a change in senior developers I raised the issue again, the team agreed again, the change was driven by the senior developer & myself to assist the team in the process. The change seemed to happen naturally and over a couple of release cycle was baked in.
I totally agree with everything that has been suggested here and under normal circumstances (meaning team leads/management are backing you) this helps everyone on the journey and with time change is implemented.
Trying to change a culture that does not have managerial full support actively on a team agreed decision is highly difficult and I wonder if it that doesnāt start entering the field of a specialist coach like Toby Sinclair. He spoke about during AMA talk this week about the difference between a āTransactional & Transformation Coachā Toby Sinclair . I have included a link to his blog where he provides a high level brief about both styles.
Is your company open to training sessions suggestions? I hope things improve one way or another and please keep us all informed on your progress. Good luck fellow tester
I sometimes think many people use the term Agile and hide behind it, to avoid their responsibilities of due governance. In an adult working environment, we are all beholden to apply some due diligence and adhere to the governance that makes a project run. If habits donāt chance, I would be on the RAID log so fast and thinking about escalating.
There is only so much, good cop, routine you can do, without it starting to seriously impact your day and goals. Surely the answer is to make sure ALL concerned, know their roles and responsibilities. Rather than having to change yours to solve the problems of the world.
I would argue
A culture shift here could help too. If folks are committing and youāre comfortable reading code, I donāt think itās unreasonable to be like āI noticed a couple commits in the PR for feature foo, and it looks like some of the logic is different than whatās in the the story . . . is that intentional? Can we update the story?ā
If youāre not reading code, then it could just be a matter of occasionally poking and asking the question āany implementation detail changes I should be aware of for testing?ā to try and get people to realize what level of documentation you need as a tester.
Do you have a Scrum Master? If not, whoever is inputting to Jira is in the driving seat and needs to keep the tickets updated. Iām fairly new to Agile and development, but the concepts are age-old and common sense. If no Scrum Master, I suggest getting a bit more Agile-like and appointing one or taking it on yourself.
Oh yeah, definitely. It should a team decision if it impacts your work schedules. In this case though its 5 minutes every other day.
But Tracy said they do know their responsibilities, they just do not follow up on them consistently.
In my experience it s hard to tell what is the best solution in general. There are pros and cons of being the nice guy that helps. A typical pro is you get stuff done faster, a typical con is you have more work. A typical pro of being the anal guy is things get done faster as well, a typical con is the team moves away from communication to ass covering or lack of trust. But as I say, its hard to talk in general, better to talk about a specific case. In this case a simple 5-10 minute conversation 5 times a week before testing a new story should be a good experiment to run.
It seems that the team might be missing the important role of Product Owner, the person on the team who represents the business user?
In the ā3 Amigosā model, that role is the one responsible for defining the product and making priority calls and thus are generally OK with being held accountable for updating the acceptance criteria. At the end of the day, they have a vested interest in reducing messiness when it ensures efficiency and more value being delivered.
Defining that model and ensuring that all 3 roles are represented in any discussion (PO, dev, test) was one of the biggest steps forward in product development that I have experienced.
Yeah, we do have a Scrum Master. But I get the impression he is as surprised as anybody if the implementation of a story took a sharp left.
We actually have a quite-involved Product Owner who comes to all our stand ups and sprint meetings and who often acts as our go-between to other business experts in the company. In at least one of these cases, the change to the story happened after a āhallway meetingā with her ā āHey, we canāt get you X in ABC way ā what if we got you X by doing LMNOP instead?ā And she said that would work and they proceeded. But nobody wrote anything down anywhere.
If the tester is not present in those conversations, then that is only 2
legs of the stool and is the reason for the imbalance.
If the tester is present, then she should be able to ask when and who will
update the acceptance criteria (test is one possibility, if the PO is too
busy).
We do everything in the same way as youāre experiencing and I find that before testing something it helps to have a print out of the JIRA, note the requirements and then have a quick chat with the developer or BA about what I will test.
It is slightly more time consuming but if youāre having to retest everything all the time then this method will save you time. Also if you do it often enough, you will end up with the devs or BAs coming to you, when something is ready to test, and discussing it.
In addition, this quick pre-test chat allows you to clarify aspects of the requirements. Iām no perfect tester and even I misinterpret things sometimes.
I hope that helps you save some time and change the culture a little.
