In my role as Director of Delivery and Enablement I work closely with the various members of our team and clients to produce solutions. Whether we’re building a custom application or an integration solution, automating a business process or just supporting one of our existing software products, every role in the team is crucial in the delivery of a successful outcome.
For this blog I interviewed one of our most experienced test analysts, Claire Huang. Of course, everyone knows that testing is important, but it is one part of the SDLC that can sometimes get forgotten about until the last minute. Below, I get a refresher from Claire on how to properly support your testers, enable them to do their best work and ensure a high quality solution is released into production.
Angela Johnson: First off, why is it so important to support and collaborate with your testers?
Claire Huang: I think everyone already knows that testers are important, as they can be the difference between a great product and a critical or costly failure. But I also think it’s important and maybe a little less known that whoever is leading projects (BAs, technical leads, Project Managers, Scrum Masters) can play a role by enabling their testing team as much as possible.
The quality of the solution delivery is dependent on direct collaboration with the BAs and Developers when writing test cases, and understanding the purpose of what is being delivered. A lot of our testing may be run in isolation, but we really need access to the team to work through issues quickly and efficiently.
AJ: What would be the first thing you’d say testers need to be successful on their projects?
CH: I’d say having clear and well-documented requirements. And that can change with the way the manager chooses to run the project, whether it’s agile or waterfall. It’s a lot easier to get clear requirements in a waterfall project because it’s often the first step (as long as the customer does not change their mind or the developers deliver the signed off requirements), meaning all the information is generally ready for testers very early on in the project. But even in an agile project it’s important that as the BAs write the requirements, the test cases are written alongside.
The agile projects I’ve worked on sometimes used ticketing systems to run through multiple small rounds of testing, and even though no one knew the overall project requirements at the start, each of those rounds still came with a walk through (sometimes even just a meeting with the BA). This meant we could handle multiple rounds of testing and release faster revisions into production. But I would be careful around verbal requirements – all requirements variations should be documented and tracked in Confluence/ ticketing system, or the document collaboration space so testers can come back and check details as we work.
AJ: How important is a good test environment and test data for you?
CH: Extremely important, but it changes with the project and the kind of software we’re testing. For testing on systems where results are driven by data, test data needs to be as close to the real thing as possible, both in volume and nature. We need data for all possible scenarios to make sure we have 100% coverage and can test everything the production system will need to do (for example, in testing a payroll integration API, it is important to have coverage for all employee types, full time, part time and casual). In projects where the test data isn’t complete or is too different from the real data, things go wrong as soon as it goes into production.
This could be very different for things like UI testing, where the data we use might be irrelevant (as long as the UI works, and meets UI rules and logic it doesn’t matter what data is entered or passed through). Environments on the other hand can be very important – most of the time we’ll never be able to test on the real environment, so the test environment needs to be as close to production as possible. If you don’t take into account different browsers, user volume and mock systems for integrations, you can again end up with a lot of problems as soon as the solution goes live.
AJ: Are there any other things you need from leadership to do your job well?
CH: It can actually make a big difference to have access to the developer tools when we’re testing, and also to properly understand the software (eg. AWS, Azure or iPaaS) that was used to build the solution. This can help us develop more thorough and useful test cases and makes identifying problems easier and faster. At IP, we often get a run through of these from the solution architect or talk to the developers to learn how the system works technically. Lots of issues found by testers at the last minute can be avoided by keeping us in the loop as the software is built.
But again it’s tricky to get that info when you’re working in siloed groups. As I said above, I’d always recommend involving testers as early as possible in the development process (even if it’s just to listen in to meetings), and also make sure you have good communication and relationships across the team. Introducing the whole team even just once at the start of the project can go a long way to encouraging collaboration and forming a single goal for the team.
AJ: Why don’t you always use automated testing?
CH: Actually, not every enterprise project will have a mature automated testing capability, even though there’s lots of benefits to that approach. Generally any larger project creating complex software will need the help of testers working manually. This is because automated testing can take a lot of time and effort to set up and maintain – those automations need to be developed and tested too, so you almost have to build your testing capability at the same time as the developers build the product itself! And of course all that can actually make it harder to work in a more agile way.
Automated testing can also just be too difficult when a solution involves too many systems or will only be used once. So yes, automated testing can save us a lot of time and effort if regression testing is required from time to time and you want to make that upfront investment, but it’s important to understand it isn’t a great fit for every scenario.
AJ: What tools do you use, when not using automated testing?
CH: When we aren’t using automated testing, we do use lots of tools for integration or performance testing. Again, it depends on the technologies we use for the project. For example, we might test using tools like AWS, SQL Developer, Postman, SoapUI, Bonita software, VirtualBox, BrowserStack, CodeSniffer, VoiceOver etc. to run the test cases or check the test results.
In summary, almost everyone understands testing is crucial for projects as it is the quality guard of the released product or solution. To do this successfully, however, testers need support from the whole team. Clear requirements, proper test environments, adequate test data and collaboration are important first steps to ensuring your testers can contribute as members of your development team and solve problems in the most effective (and fast) ways.
Building a business application? Consider these non-functional requirements first.
