Optical character recognition technology (OCR), or text recognition, converts text images into a machine-readable format. In an age of growing need for efficient data extraction and analysis processes, OCR has helped organizations revolutionize how they process and...
It’s all about that team, ‘bout that team, not individual…. With apologies to Meghan Trainor (It’s All About That Bass), that team is what everyone is talking about when it comes to effective agile software development and DevOps. More and more companies are realizing that having the developers, the product owner, and the testers all working together at the beginning of a development cycle pays dividends.
A Different Approach
This is especially important in a shift-left mentality where testing is done early and often. Everyone on the team shares an understanding of the requirements. Everyone understands the tests that are needed. And there is a consensus about whether a feature was specified sufficiently. The result is that there are efficiencies in development. Development interruptions are eliminated. Delays, lost effort, lack of timely feedback, and unwarranted assumptions that give us results we don’t want become a thing of the past.
Wait a minute! How is that approach different from the way software was developed in the past? There was a team. It had developers who provided the technical solutions and fixed defects. It had product owners who provided the requirements. And it had testers who made sure that everything worked.
That’s true. But they didn’t always work together efficiently. Sure, developers could get their questions answered by engaging the product owner directly. When it was time for testing, the testers could get information they needed from the developers and/or product owner. However, many times, choices or decisions were made with only two parts of the project team, usually between just the developers and the product owner. The testers found themselves on the outside looking in. Inefficiency, reworking and missed deadlines were built in. Not much of a team.
Don’t Forget the Testers
To have an effective team, ALL parties – the three Amigos: developer, product owner AND tester – must be invited to contribute from the beginning. Why? Because each brings with them their own, many times different, viewpoints on almost anything you’re planning to build. The product owner thinks about what the business hopes to accomplish by building it. The developer is concerned about the details needed to implement it, e.g. what information is needed when and which technologies are needed to accomplish the goals. The tester thinks about what might go wrong, either within the system under test or in the external context upon which it depends. Sometimes these three viewpoints are enough, but sometimes others are also needed. The big change here, though, is inviting the testers.
Yes, it all starts by empowering testers and instilling a “whole team” view of quality. Including testers early on in the development process is quite a change from the approach that many companies took (and some that still do) when it came to testing and testers: “When the developers are done, we’ll let you in on what they were doing and let you test. And don’t miss anything!”
The Psychology of the Tester
Okay, so it’s really important to include testers early on. What do they bring to the table? I’ve been asked that question many times. Part of it is the way that their brain is wired. They are naturally curious, naturally analytical, and critical thinkers. It also helps to have a thick skin.
That’s all nice, but how can somebody with all those personality traits influence a project? Testers can work closely with both developers and business representatives to ensure that the desired quality levels are achieved. They can use those traits when supporting and collaborating with business representatives to help them create suitable acceptance tests, defining what done is, working with developers to agree on the testing strategy, and deciding on test automation approaches. Testers can thus transfer and extend testing knowledge to other team members, thereby influencing the development of the product. Everybody benefits.
If you’re considering making the change to the whole-team view in agile product development, don’t worry about the testers. They’re a tough bunch. In almost all cases, over time the old-style attitude that testers should just be along for the ride fades. The rest of the team eventually develops a newfound respect for testers. One that helps to foster growth, efficiency, and effectiveness, and along the way enhance the project’s and team’s – there’s that word again – chances for success and your ability to deliver value to your customers.
Do you want to get a head start to GUI testing and learn more about the major GUI testing techniques and types? Go ahead and check out our comprehensive GUI testing guide now!
Related Posts:
What Is OCR (Optical Character Recognition)?
Optical character recognition technology (OCR), or text recognition, converts text images into a machine-readable format. In an age of growing need for efficient data extraction and analysis processes, OCR has helped organizations revolutionize how they process and...
Support Corner: API Testing and Simple POST Requests
Ranorex Studio is renowned for its robust no-code capabilities, which allow tests to be automated seamlessly across web, mobile, and desktop applications. Beyond its intuitive recording features, Ranorex Studio allows custom code module creation using C# or VB.NET,...
The Top 10 Test Automation Challenges
It’s difficult for any IT organization to execute DevOps effectively without test automation. However, it’s often easier said than done. Overcoming the challenges of automated software testing can end up slowing down product delivery and impacting quality, the exact...