As a tester, I deal with different techies every day, depending on the nature of the project and its complexity. But working with the developers is another kind of thrill, though sometimes it gets hard to handle two different hemispheres. However, we do manage to yield a successful product release.
Let me share a recent experience with you where I got a chance to work with the developers. It was totally a new learning experience, and definitely unexpected.
As I mentioned earlier, I have been working with developers to test bug fixes and systems for the very initial test release. Typically, our team managers organize us in teams for different projects, and for this particular project, I was the only tester working all the way until the release. Here’s the most surprising part - since there was a whole team working, the developers were dynamically assisting, in fact, working with me throughout the testing activities.
Developers Faced Dilemmas with Me!!
Through working with a tester, I noticed that the developers got a bit of further understanding of how test cases are handled in a test environment. Furthermore, they realized the importance of testing scope and fixing above testing. While working with them, I came to know that coding, installation, and confirmation aren’t any less of trouble besides testing.
What I get to know is, developers generally work with a pre-configured tool or software. They save themselves from the system installation distress as well as the manual configuration to save time and effort. This witty strategy helps them measure time constraints better while working on a specific functioning code. But, doing the development chores, they are least focused on the user experience aspect. And that’s where the turmoil began...
What Developers realized…
Gradually, after setting the beta test environments, the overtime it took shocked them, while the installation procedure seemed more difficult than usual.
Furthermore, though they developed the framework for the initial product configuration, it looked more burdensome and less intuitive to me.
The teamwork made us recognize where the problem was and how crucial it is to make a quick product release. A lot of learning it was…
Developers Learned to T
ake Risks!
After developers finished their installation and configuration processes, it was time to start some serious testing. We, as a team, focused on testing the defects that looked more severe and required deliberate calculations. We had to carefully scrutinize these defects to estimate the end results generated by the system accordingly. At that time, testing required to be specifically detailed.
No matter the defects were well-written, the developers shortly discovered that reporting defects were less important than fixing the defects. They came to know what’s more important.
Developers triggered their intuition…
Developers learned that testing is intuitive and risky because not every change made fixed the problem, or any change made emerged another problem, or a change could unveil a defect that was covered initially. Deciding if an issue is “fixed” or if it entails a new defect can be quite brittle. I taught developers the language of testers to understand a defect; “Take Risks and Accept Challenges.”
At this development phase, when every test sprint was accomplished and the test releases were impending, every single decision and change identified a new risk or issue, thus impeding the product release.
Decision-making…
Here, we needed to assist the product manager in making the right decisions about the imminent risk. In the testing scope, we had already decided that changing the code is less risky than shipping a product with inaccurate results and defects. Testing is all about customer experience and that’s what I made the developers realize.
It is better to fix some instead of fixing no defects at all!
Yes, Developers can test!!
I found that the developers were pretty fascinated with testing and they had their own unique way of fixing and risking the defects.
They recognized that doing ad-hoc fixing is not the right solution to solve the problem. They also learned to discuss the risks of fixing a particular defect with a comprehensive detail.
It was literally an electrifying experience for me, one must intermingle with experts from other domains and expertise to learn and grow better. Do you have interesting insights to share about your own adventures in the development world?
