Getting the minimum documentation from the agile developers

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??

Thanks.

1 Like

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.

2 Likes

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.

1 Like

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. :smile:

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!

Hope this helps. Let me know how it goes.

1 Like

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.

1 Like

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. :slight_smile:

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 :+1:

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.

1 Like

So true.

Sometimes a gap between knowing the responsibilities and actually carrying them out :slight_smile:

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).

Tracy,

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.

Printing the key page for the discussion is an excellent idea and Iā€™ll definitely be stealing that one. Thanks.