Tech teams are the most āvisibleā when things go wrong! The rest of the time we are the silent ones working away in the background
In our company we are currently on a project āback to the floorā where members of the Tech team are spending time with Customer Service agents and getting feedback, suggestions and ideas that way. We test a lot of processes which work when we are testing, but there is still the disconnect between us testing and the Customer service agents day to day role and all the challenges it throws the agents. so part of being a tester in that situation is we have to be inquisitive and pre-emptive of issues before they occur. Through that process I have identified some features we already had in the system which people were not using, and this will save a lot of time for everyone.
TLDR - donāt just be people who look for problems, reach out and talk to users about solutions, and the end users day to day work is a kind of testing that we need to capture the results of!
Hello! To report back, we got a small group together and chats on a 1-1 basis with customer success etcā¦ We gave them visibility of all our release tests and talked through how we work. We ended up creating a critical feature list and have identified some test coverage gaps. It had been so useful. They are also coming to do sone release testing with us!
This seems very useful and something Iāve done previously but didnāt really gather much traction. Iād be really interested to see your template you use for this if you would be happy to do so? Happy to discuss on dm if you think we can work something out?
Hiya,
Yes!
Basically it had rationale at the top of the reasons why a feature could be critical like security - protecting data amongst other things.
Then it lists areas of the product with specific features.
Happy to help you further. Just message me here or on twitter. @fisherjmelissa
This is true that most testing work is invisibleāsomething that happens inside your head and leaves no artifacts behind.
Just like, Software developers have code, databases, and configuration files to show that they have been productive. Designers have mock-ups and data from user studies. Product people have a living conversation that teaches the technical team what needs to be made. However, salesforce qa might have nothing to show at the end of a workday. This generally leaves salesforce qa feeling like no one understands what they do all day.
One of the reasons testing work is invisible is because literally no one sees it. Testers get a new build, hide in their cubicles for a while, and then emerge with a few bug reports (or sometimes nothing at all). The work isnāt observed by anyone.
The solution is collaborate closely with developers, from when a change request is reviewed until the change is ready for production. Try to do testing with a developer sitting with you, or at least nearby, for some part of the day. This will allow them to see how you are performing testing work, and you will have the opportunity to demonstrate bugs when you find them rather than having them get lost in a bug-tracking system. I usually find it helpful to ask the developer about their concerns while they are around. They know the implementation and how it integrates with other parts of the product, so they may have some suggestions of what to test or what risk idea to explore next. Also, this is helping in design and write unit tests, observing code that is being written and occasionally discovering bugs in that process, and, yes, exploring the product in a browser, too.
If you want your work to be understood, then make it visible. Demonstrate the testing you have done, tell them about the test ideas you want to perform, and describe the risks and bugs you have discovered. As visibility is the first step.
