FAQ Agile testing

Most asked questions

Of course, there are methods that help with this. One way is to involve the testers early, already in the requirement setting phase through methods such as Acceptance Test Driven Development. It gives all roles an opportunity to discuss the solution and expected behavior before development begins for each individual requirement. You can then start designing the tests even before it is possible to test them.

Testing each requirement after they have been coded is also a possibility, as you can specify that Test will be a step before the definition of done is fulfilled. Then testers can start testing before an entire build is finished, which is clearly preferable in an agile environment. Depending on the technical competence of the testers, you can also run pair programming with testers and developers together, but it is a method that requires a little more skill.

Some form of mindmap and learning at least one scripting language to use. If you use a mind map when you test or plan your testing, you can in practice hand it over to a developer where they can follow exactly what you have done graphically, without having to read 14 A4 pages of documentation. See where it went wrong and get a link to the bug report. Everything becomes much more understandable and comprehensible. I like Notepad++ and Xe Max you can make good macros in. Then I always use a clipboard tool.

Using the same agile board as the rest of the team/colleagues/company makes it easier. If you have a tool that people use and look at, then there is no reason to bring in a new or parallel tool. Concrete tips if you don’t already have a tool: Asana or Trello.

Tips on how to motivate the developers in your team to take greater responsibility for the quality of the code you develop.

You can approach developers in different ways depending on their personalities. I don’t think there’s really a set process for this but the single biggest success factor for me is approaching the developers and offering to sit with them and test for a period as soon as they have something testable.

Talk to the developers, be with the developers, be next to the developers, ask how things are going. And ask the question, when do you have something palpable and squeezable. And then you can sit together and test, maybe just a quarter of an hour, half an hour, maybe a whole hour. And with a bit of luck then I can screw in different testing techniques that I can, and the developers think it’s great fun to learn something new there too. And if you find a lot of bugs, it is usually easier to get closer to the developers, because they see the very value of being able to find it earlier then.

Then you must be quite responsive as well, because some developers periodically want to sit concentrated and think for themselves and then you have to let them do it, so you actually have to personalize it a bit.

The biggest pitfalls are when introducing agile testing. Agile testing is simply moving the quality work further to the left – shift left. This includes activities that may not be pure testing, e.g., code reviews, and you may have a superstition that it is very quick to introduce it.

But this is a question of a cultural shift. Therefore, the biggest pitfall is simply that you are in too much of a hurry, you think that it will go quickly and that everyone can test. To some extent, yes, but it’s a matter of skillset and mindset, not everyone may have the will and the kind of familiarity to become a good tester. So, you have to build the culture and that takes time. And that’s the first step – to let it take the time it needs.

Then there is a superstition in automation, that you can automate everything. You press the green deploy button when you’ve written your code and it goes into production and everyone is happy. There will be steps in between that take time to work out, that will still be manual and that need to be worked in.

So that I think a certain amount of superstition and a certain amount of being in too much of a hurry, those are the biggest pitfalls.

To learn more, check out our article: https://qestit.com/blog/5-pitfalls-in-agile-transformations/

It’s the kind of answer you might not want to give – it depends entirely on how the test leader role looks today at the various organizations.

But if we look at the test leader in an agile team, I don’t think that role will remain, but the test leader will become a bit of a spider in the web. The person who looks at what’s coming and syncs between teams. Because I think pure test teams will disappear, that is groups of QA.

QA and testing will go out into the teams and the test leader, if it remains, will be a coach. The one who looks at common tools, common processes, synergy effects and so on. Then the test leader role will probably be phased into other, perhaps management roles. And as my colleague Amanda said, it may be that you look more at agile processes than at tests, because tests as such will be baked into the quality mindset and the activities you do to simply increase the quality of what you produce.

But it’s nothing that happens overnight but will probably take a couple of years. So that the test leader role will remain in some color and form for quite some time.

The times it has flowed very well is when I have sat down and coded with a developer. The two of us have sat down and written the feature code and then the test code and we have written at the unit level and then at the indication level. And if it’s something small and light, maybe we can push it into production right away and see that it’s done and out in the three hours we’ve been sitting together at the desk. Then you get all the elements in very naturally and easily and it is usually very easy for the developers to continue working so late.

Then they must take responsibility for when they release not so good stuff. If perhaps it applies to something less critical, you can get a little more trial and error. The team must be allowed to fail occasionally to move forward.

I think there is a place for user acceptance testing, even within the agile testing framework. Because it is the case that you must not only do things the right way, but you must also do the right things. And the last chance to validate it, it’s if you have a UAT at the end. It should run in some kind of environment that is kind of sacred, very production-like, where you don’t release garbage, use like some kind of sandbox environment and test other things in it.

Agile is, after all, a way of working on how to develop in smaller iterative steps. Then that it might not go into production right away, that’s another matter. So there are big gains with the agile process developmentally, regardless.

That you don’t hand things over several levels down, but that everyone is on board during the development. Tests come in early, the requirements are included, business is included and so on. So that process is superb. Then, of course, you want to get that out quite quickly too, so that you can see that it plays. If you don’t have that opportunity, it’s a bit unfortunate, but it wouldn’t stop me from enforcing that you have an agile development process. Because it’s a little bit two different things anyway.

The biggest change that needs to happen is about communication and collaboration between different roles. Getting the different competencies to cooperate more closely in their daily work is a key to success. Since agile is a culture rather than a process, it is about fostering such a culture throughout the organization. This applies not least in the management level, as these must go from being controlling managers to facilitating leaders, two concepts that are very different. It is important to introduce the changes in small pieces at a time.

A “tester” can have as many definitions as there are … Well, testers. As a tester, what do you need to know to do a good job in your context? What do you need to know to solve your problems, and to be able to help your team in the best way?

To be a little more concrete, and not just come up with counter-questions, I can say that I have benefited a lot from being able to program. It facilitates my own work, as I can easily process output from log files, databases, or the like to find information. It also gives me the opportunity to, for example, create test data and automate repetitive or time-consuming tasks. In addition, it becomes easier for me to convey problem descriptions to other programmers in my team as I can point out the exact line of code that is incorrect, suggest a concrete solution, or even contribute my own bug fixes.

The more you can, the more fun you’ll have! There’s no reason not to learn programming – or anything else, for that matter!

If by “definition of ready” you mean “when is this documented requirement in such a state that I, as a member of the team, can start implementing a solution with the belief that it will live up to expectations?” then the answer is the team.

In an agile world, you often have recurring sessions where the team goes through the requirements in the backlog with the product owner to iron out any questions and make sure everyone agrees on what needs to be done, why it needs to be done, and how together we make the end user happy and happy with the delivery.

The absolute number one way to get developers to give up milestones is to never, ever penalize a developer who gives up a milestone. Because if they experience it as negative to give up milestones, they will stop doing it. But I usually do the opposite, that if I discover a problem, then I spend maybe an hour a day or something to help the developer. The developer might need help finding test data, help running tests, help with anything.

So, never punish the developers for what they do, actually. it must become a positive circle. This presupposes that I can and must approach the developers, that there is a way in, that I can sit next to them and talk, have a communication. Make sure that it is positive for the developer that you are there.

 

There are lots of different ways to handle this. One way that was new to me, on the current assignment, was that if a team builds an API that my team will consume, it’s my team’s responsibility to go in and write API tests in the other team’s code base, so that the whole time are free to update as long as their regression tests pass. I think that was very smooth, because we get exactly the security, we need to use the API and they have full freedom to update it whenever they want. So it was a very pleasant experience for me.

Otherwise, it can easily become so tangled and cumbersome, and each version has to be managed and checked off with stakeholders and so on, but it worked very smoothly. And if it’s not such a simple case, like API and client. Maybe both should write some client code and such, then I mostly believe in talking to each other. The developers in the teams, the testers, etc. A few stakeholders in each team simply get to sit down and talk and come up with a common plan on how to do this.

Because there are many different types of QA activities that can be performed by non-testers, teams can be held accountable by doing as much as possible before it’s time for system and acceptance testing.

Several different methods belonging to different test levels can be applied. Everything from collaborating on requirements development and writing acceptance criteria together (e.g. through Acceptance Test Driven Development), or having code reviews, using static code analysis tools, applying pair programming and, in the best case, also test-driven development (see Test Driven Development), as teams automate integration and system testing, many defects can be caught before they reach the system testing stage. Then one can focus on exploratory tests and ultimately also enlist the help of customers or customer representatives within the organization to perform acceptance tests.