Beautiful Testing, with a wide variety of fascinating chapters contributed by leading software professionals, is available. Not only will it inspire you and your team to improve your testing and your product, but all royalties go to a good cause. I’m honored to have written a chapter. Please see the page on my site for more details and a free copy of my chapter – to whet your appetite for the rest of the book!
Some takeaways from the Software Teaming 2024 conference
April 12, 2024
I have enjoyed a lot of ensemble / mob programming, aka teaming, over the years. As a diverse group, including people with different deep skills,
2 comments on “Beautiful Testing!”
Hi Lisa,
I have been reading and following many blogs related to testing, agile practices etc. Being a Tester myself for last 6 years I was introduced to Agile testing in my current new role as Test Lead and the transition from Waterfall methodologies to Agile was really a challenge for me. Even after almost 2 years at my current role I was not able to reap the proper benefits of Agile testing. There might be many reasons behind it like developers-testers ratio (we have around 20 odd developers and 3 testers), me being a novice to agile practices etc, though I managed to setup Automation scripts (using tool Ranorex) in C# and also setup Continuous Integration Environment for our nightly builds. But there is so much to test and automate and moreover new stuff gets added all the time that it was getting cumbersome for me to prioritize testing tasks. I managed to read your chapter “Beautiful Testing As the Cornerstone of Business Success” in Beautiful Testing and I think I have found the panacea to our problems. The way you have explained how you started with Scrum and how well you progressed so far with it is absolutely brilliant. I think the major contributor to your success is that all the team members are in the same boat. Though I would really like to know how did you managed to go about building unit and component tests? Was it done by the developers or was it done by the testers? There would be many questions which would definitely crop up once I start to implement some of the concepts I have read. Hope you will assist me by answering them.
Thanks & Regards,
Deven B.
Hi Deven,
It sounds like you’ve made good progress, especially given such a large development team. Congrats!
I’m so glad you found the story of how my team has made this journey helpful. Of course there’s no panacea for anything, but each team can find its way.
I just went to a talk by Jeff Patton last night in which he pointed out that the “it’s not my problem, the hole is on their side of the boat” process-based defense really doesn’t work. We all have to keep the boat floating or we sink togeter.
Unit and component tests are the solid base of our “test automation pyramid” supporting the whole test automation strategy. They are done by the programmers, because they are really about achieving a good design and architecture, not really about testing. It doesn’t make sense for testers to write unit tests – you would miss out on 90% of the value of unit tests.
While the programmers learned how to do test-driven development at the unit level, and automate unit and component tests, I (as the tester) worked on an automated suite of smoke tests through the GUI to provide some level of safety net around our legacy code. Once TDD was well-established and we had the GUI smoke test suite running in CI, we all turned our attention to automating functional tests behind the GUI with FitNesse. FitNesse gave us the added advantage of promoting communication. Programmers and testers have to talk about the functionality to write and automate the test cases.
I hope that helps.
Thanks to everyone for supporting Nothing but Nets by buying a copy of Beautiful Testing! It contains great chapters by smart testing practitioners.
— Lisa