As part of working along with the industry, in exploring ways of advancing Software Testing, interesting conversations happen with a variety of folks with different perspectives.
When I am tired with all the noise in the social media that’s promoting fake and hype, it is consoling to talk to some real people and get to know their experiences and how they approach things. Slack’s virtual-coffee is an interesting place to exchange ideas.
Yesterday I got to talk to someone who had a very matured way of looking at things. One of the things I admired with him is his patience. While talking about coaching, he said, “If people are not ready to listen, there is no point in going ahead with educating them. They need to feel the pain of their current state of affairs, and only then they will be willing to assessing alternatives”.
We discussed about importance of testing in post-development stages. I shared my experiences of the situations which would require such an effort in addition to the unit tests and integration tests done by the developers. I highlighted the point that most of the defects happen because of interaction of situations than standalone, and standalone defects can be caught by unit testing and module testing through TDD.
We also talked about real-time scenarios testing, and he brought up Chaos Engineering as a solution. I shared with him that Chaos Engineering in a controlled, planned fashion alone is not sufficient for real-time testing, because the solution testing involves not just the negative scenarios but also planned end-to-end. He brought up some industry initiatives and added that Chaos Engineering can be done not in production but also during staging.
We talked about startups handling testing as scripted checks (because it’s cheap and college graduates and freshers can do it), and I told him that Software Testing is not just that and it involves exploring and learning the system and figuring out how the system works, although while doing this, it would be worthwhile to note down the test cases because it will be useful for eventual regression and automation.
I shared that I test as well as develop when he asked why I am interested in development-related forums. He asked how it feels to be both at the same time. I shared my personal experience that it involves donning two hats, and while as a developer I am interested in TDD and ensemble programming to better the quality of code as it is being developed, my approach towards testing would be totally different and that usually happens during the later stages of the product development in spite of the disadvantages of being late in the cycle and the back-and-forth of finding and fixing the issues, because that’s needed.
We agreed to stay in touch in LinkedIn and that he would introduce me to his meetups and initiatives which I can make use of to better my understanding as a developer. So, it was a very productive and nice virtual-coffee session!
For testing strategy consulting enquires, please setup a consultation with me. Happy Testing!