When I worked at the same company on sort-of-same products over 12 years ago, one of the projects we then completed was something we called WinCore. Back then the project involved combining ideas of a product line and agile to have a shared codebase from which to build all the different Windows products from, I remember frustrations around testing. Each product built from the product line had pieces of configurations that were essentially different. This usually meant that as one product was in the process of releasing, they would compromise the others needs - for the lack of immediate feedback on what they broke.
Looking at today, test automation (and build automation) has been transformative. The immediate feedback on breaking something others rely on has resulted in a very different prioritization scheme that balances the needs of the still three products we're building.
The products are sort-of-same meaning that while I last looked at them from a consumer point of view, this time I represent the corporate users. While much of the code base servers similar purposes as back then for the users, it has also been pretty much completely rewritten since, and has more things it does than it did back then. A lot of the change has happened so that testing and delivering value would flow better.
Looking at the achievement takes me back to thinking of what the 12-years younger version of me was doing as a tester, compared to the older version of me.
The 12-years younger version of me used her time differently:
- She organized meetings, and participated in many.
- She spoke with people about importance of exploratory testing with emphasis of risks in automation, how it could fail.
- She was afraid of developers and treated them as people with higher status, and carefully considered when interrupting them was a thing to do.
- She created plans and schedules, estimated and used efforts to protect the plans with metrics
- Instead of being present in meetings, she sits amongst people of other business units doing her own testing work for serendipitous 1:1 communication.
- She speaks for the importance of automation, and drives it actively and incrementally forward avoiding the risks she used to be concerned for. She still finds time to spend hands-on exploratory testing, finding things that would otherwise be missed.
- She considers fixing and delivering so important that she'll interrupt a developer if she sees anything worth reporting. She isn't that different from the developers, especially on the goals that are all common and shared.
- She drives incremental delivery in short timeframes that removes the need of plans and estimates, and creates no test metrics.