Malgorzata Czerwinska, Soflab Technology, discusses Independent Validation & Verification in Agile teams.
That’s kind of truism if I say “Agile methodologies became more and more popular nowadays”. They’re successful, they promise a lot, and – most importantly – they usually fulfil their promises. It seems Agile will keep its top position between other software development methodologies for the next decades. It shouldn’t be surprising that, being successful in small teams, Agile is stepping into the corridors of enterprises with growing confidences. To meet new challenges, further approaches are created for the scaling of Agile. To name only a few: SAFe, LeSS, & DAD are just some examples of the agile scaling frameworks, of which companies may choose among.
Enterprise scale means complex software projects – at least if you count the people who are involved. Complex project requires complex quality assurance activities. One of the proven ways to assure satisfying software quality is the Independent Validation & Verification (IV&V) approach. Independent Validation & Verification is a term used for software examination carried out by a third-party organisation (or at least a separate team), not involved in the development of the product. IV&V provides project managers and other stakeholders an objective analysis that helps them deal with system issues and deliver improved visibility into the progress and quality of the development effort.
So we have Enterprises, which would like to extract benefits from the Agile approach, but, at the same time, assure at least a similar quality, which is provided by IV&V. If we take a look at the Principles behind the Agile Manifesto, we can find such statements as: the highest priority is to satisfy the customer, working software is the primary measure of progress, continuous attention to technical excellence – all of that is often called “build in quality”. But how to build in this quality?
From the scaled agile framework’s point of view, things seem to be obvious – many separate agile teams, following continuous integration rules, build a compact and solid software, providing a stable system. Such a system can be easily verified by an independent testing team, which executes E2E tests. They can also execute acceptance tests of any type – starting from functional tests, going through all kinds of required non-functional tests, ending on whatever you can imagine to test, when you have your software ready. But doesn’t it bring us back to the 80’s, when waterfall became popular and started its successful march through the software development lifecycle? How to merge the 21st century agile achievements with the best and effective QA practices? What about shift left testing?
SCRUM, one of the most commonly used Agile methodologies, announces: no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis. I believe it might work – for “one team” projects. However, for some reason life has forced organisations to create different roles inside each of the development teams. And yeah – what a surprise – a tester will always be needed – side by side with developers. Now there’s just a small step missing, namely – placing the independent tester into the development team. May it work? Yes. Does it bring any advantage? A lot. Is it easy to implement? Obviously not.
Does it work? Let’s take an example of the Soflab Technology – one of the independent test vendors, which we can find at the top 20 Leading Testing Providers report, prepared by the TEST magazine. Soflab is successfully delivering independent test services inside Agile Teams for various projects and companies. The key to this success are advantages of combining IV&V and Agile methodologies – shorter time to market with flexible response to customer needs, improved with objective software quality verification, which supports one of the core agile values – transparency.
Then what are the scratches on this perfect image I draw above? Actually – if I were a Project Manager, I would call them challenges. However, arguing as a tester – I see them as traps. There’re various traps waiting for everyone involved in the software development process.
Trap No. 1 is waiting for the team. The team should have a “ba” spirit – the team should be a group of colleagues, who have a common aim and fun, when the aim is achieved. But how to build a friendship, if the team members come from different companies and developers have the feeling to be under control all the time? Daily meetings may easily become “judging sessions” where “tester-spies” are looking for the developers’ mistakes, to report them to the management. An eternal problem appears here – how to ensure developers that testers are in their team to help them, and not to make their life harder? Well, with regret I must admit that I don’t have any golden solution for that. But, I can honestly say that, according to my experience, after the first sprint of a “testers vs developers” division, teams usually “self-organise” to collectively say, “my team is better!”. It’s Agile magic, and we can support this magic, trying to manage other traps, which are waiting for IV&V Agile teams.
Trap No. 2 is waiting for the developers, especially if they haven’t experienced testing in their close environment yet. “My US is too technical to be verified by a tester. It’s not related to the GUI” is often what we hear from developers. But the truth is, that whatever has been done, that can be checked. Testers should have sufficient technical skills to be able – after a short introduction – to verify any US at given project. Moreover – what might be more important – the tester learns the details of the produced software, giving invaluable contribution to the E2E test team works and/or preparing manuals for the DevOps or final users. Not without reason, testers usually have complex knowledge about the software.
Trap No. 3 is waiting for the testers. And it may be a really tricky trap, if the tester’s experience is based on UAT tests or another final product verification. Testers, keeping their “nitpicking approach”, must remember that they’re working with a product that is under development. In fact, sometimes this product is even in a “pre-development” phase. They can’t limit themselves just to the verification of the “acceptance criteria” of the user story or any other “test case”. The tester should push himself to think out of the box, to go where neither the developer nor the product owner went, and finally – to TALK about his findings with the team. I know an orthodox Agilist who’s favourite joke is “tester reported a defect in bug-tracker!”. So yes, tester must remember that “Individuals and interactions are over processes and tools”, however at the same time tester at the enterprise project mustn’t be so orthodox. She/he must distinguish if the issue may be fixed offhand or should be reported, in order not to be forgotten. Creating issues repository at a very early stage builds knowledge about the product quality, which can be easily transferred to the managers, E2E testing teams or other stakeholders.
Finally, trap No. 4 is waiting for the management. The management is used to receive the set of metrics, to push the teams if the metrics are not satisfying and call emergency meetings if the metrics are not satisfying at all. But in agile projects, metrics play a different role – they should be used to learn how to support the team, not to breath down the team member’s neck. Moreover, it’s important to give the people space to make mistakes. Remember – we’re at the development phase. Only those who do nothing, make no mistakes. Let’s give people a free hand, so that without unnecessary pressure developers may, together with testers side by side, create amazing things.
Four traps seem to be enough to make the impression that IV&V in Agile team is a difficult experiment – but who said that agile is simple? In fact, we all know that Agile is easy to understand, but difficult to implement. So, quality assurance practices in the agile environment can’t be easy, likewise! But when they succeed we receive a solid knowledge about our product since the very beginning and we’re gaining time to solve problems before they even occur.
Is Independent Validation & Verification at Agile teams an oxymoron or new quality at QA? Based on my own experience, I can say with conviction that IV&V in Agile team remains an apparent contradiction. Soflab’s experience proves that it’s always worth a try to create new approaches to assure quality, which match the challenges of current times.
