Today, I was planning on preparing a bit more into future sessions of ApprovalTest exploration. I had scheduled a pair testing session with a wonderful lady from UK, and I just wanted to get my environment set up.
Before, I had been exploring the C# version, and today I wanted to work on the Java version. My reasons were two fold: 1) I wanted to be able to work on my Mac as the camera on my work Windows won't work 2) I wanted a first feel of consistency between the C# and Java versions.
I download the package from GitHub and import the project, and run the unit tests to make notes of my first observations (would like to say bugs). This really should be available from the Eclipse Marketplace or whatever equivalent the other IDEs have
- The unit tests are red - not passing for 5 tests out of 341 total.
- The machine-specific tests are not easy to recognize as such and make the suite fail
- No user manual that would guide a new user to do this...
- Same unit tests duplicated over different locations in the project
- Unnecessary old notations in the code
- Clean up the code to use the 4-notation consistently
The after exploration discussion is what puzzles me the most. The developer again labels the things I'm doing and pointing out as product owner stuff, when this is what exploratory testing has always been for me. And on the other hand, I've yet to experience a product owner that would actually go hands on enough to do stuff empirically. He points out that while he never realized you could ask *this* from your testers, it's likely that there's other developers who have no idea what their testers could help them with. Exploratory testers seem to understand (learn to understand) the vision, and understand (learn to understand) the user.
We also talk about my ideas of how I want to spend time on exploring the rich ecosystem, and how he's never really paid much attention to it outside end user feedback.
He concludes there seems to be three things working in my favor:
- Skill and discipline in organizing thoughts
- Beginner mindset
- Look of the code as a product; devs look at it as code; product owners look at product as product.