In a previous post (opens in a new tab), I declared a Testing Platform and an intent to review it one year hence. Since that post, I completed one project and started another. In my new project, I am working with new people and on a different platform.
In a somewhat agile fashion, I offer my retrospective on what has gone well, and where I might improve. My perspective is from my role as Test Lead.
During the first part of the year, we loosely pursued a testing purpose in our tests. With the start of a new phase of the project and the addition of more testers, I request the tester describe an information objective for their assigned story cards. Not every tester on my team has attended BBST Foundations so I mentor them in this concept.
I believe this helps frame the testing effort however we’re just a few iterations into the phase. I don’t have enough information to determine if my team has seen benefit from describing a testing objective so I plan to be diligent.
I started using more automated unit tests for my home programming projects and experimented with creating an MVC-based website. I feel the exposure to both of these technologies keeps my programming and testing skills sharp. They provide a perspective I can use in testing and a foundation for interacting with developers.
As a Test Lead, thinking is still very valuable. I frequently offer thoughts and impressions on implementation ideas, on testability, on maintenance, or on people. In my experience, a Test Lead is part of the core team guiding the project, and should offer a testing perspective on many project aspects.
Lastly, I benefit from participating in this community. Both blogs and books offer perspectives, ideas, and experience that I find useful. I think I can do better in offering the same, and encourage other testers to participate as well.
Early in the project, I established good credibility with the core project team. I engaged them in conversations about their experience and background, project objectives, and testing.
I find that conversations about testing are more of continuous journey to help others understand testing value. Just when I think everyone is on the same page, the testing team suffers some small, unintended slight, and my journey begins again.
Everyone agrees that testing is required, but they soon forget the conversation. While this is often frustrating, perseverance without arrogance, I believe, helps the testing team and the project.
To date, I must say my project team is one of the more considerate of testing, understanding of its benefits, and engaging in quality as a team sport than I usually experience.
Over the course of the project, I provided alternative opinions to bring clarity to a few requirements however, assisting with the direction of our project was the most rewarding. I suggested a path of more learning which could result in a shorter final testing cycle. A faster delivery often appeals to project managers however I believe a few of my tenets in this platform assisted in his decision to use my suggestion.
Early in the first phase of our project, I did a poor job of communication. I made assumptions about a few tasks, actions, and ideas. I failed to realize that I was working with new people. They did not understand me as well as those on my previous project (where we had worked together for two years). I made a post-it note to ask myself if I am making an assumption which assisted in clarifying my emails and preparing for conversations. I learned that I should not get to comfortable in language, words, and conversations for these may be as context-driven as my next test.
My conversations advocating testability have grown into collaborations on how to make products testable. Additionally, I encourage my testers to discuss testability with developers, and our design reviews include a review on testability. In my opinion, succeeding in improving testability one project at a time is good; when my testers join new projects, I hope they spread the word.
In a new project I find that, in addition to introducing the idea of testability, I must also convey my thoughts on what testability means to me. While it may sound like a simple concept, offering your thoughts to testers or developers will generate a good conversation, and everyone lands on a working definition for the project.
My experiment in estimates includes factors that impact testing work: environment stability and availability, developer testing, defect density, and product familiarity. I use these to adjust a base estimate (e.g., a large defect density increases the estimate) and then apply a confidence factor. I also set the expectation that I would change my estimate as I learn more about the products and project.
Again, I don’t have enough iterations to draw conclusions on this approach.
I’ve been experimenting with wireless technology for some embedded development, and researching motors and controllers for some ideas around robotics. While each has unique challenges in testing, neither is associated with the testing I perform for my employer. However, I often find the defocus valuable and, serendipitously, occasionally useful.
During the first phase of my current project, I found no opportunity to use automated testing. The implementation was not complex so I could not justify the cost.
In our second phase, the implementation is more complex and has a few opportunities for automation. Specifically, I expect to extend a tester’s reach by providing them the ability to explore product behaviors with a greater diversity of data combinations, and an opportunity to review more data in a shorter amount of time.
While the feedback I receive on collaboration has been good, I was elated to hear that our business sponsor would like to know more about what we test and how we test. I look forward to sharing more than a report or a defect. I hope to share testing stories and help them understand the impact to the products we create.
How was testing for you in the last year?