The opening keynote today is being given by Dawn Haynes, who confessed that this is the first time, outside of a Lightning Talk, that she has ever spoken at CAST. Most of us, however, know Dawn very well, because she has been there, behind the scene, at almost every CAST since its inception.Dawn is focusing her keynote on personalizing retrospectives. Dawn is not a fan of best practices. She's not one that says she can really learn any way but experientially, so there's a great deal of this in her talk. Part of the focus of retrospectives is to give advice moving forward, to compare successes, and to recognize and review failures.
Dawn was discussing the Big Dig that took place in Boston, and some of the stories that were shared with Dawn from the perspective of one of the top program managers, and how what was meant to be a relatively straightforward project and how it spiraled out of control and grew to be one of the biggest and longest urban projects in modern history.
She described some of the ups and downs of her competition (and video footage from an old VHS tape, for those who remember what those are ;) ). She said that she was both "mortified but intrigued" by how everything turned out. The good, the bad and the "ugly" of the event was on display. The interesting thing was being a participant gave one perspective, and those of us watching the video had a different perspective. I thought she did great. As an "adult competitor" in a sport (in my case, snowboarding) I can totally appreciate how these perspectives can be impacted.
Introspection is an important component when it comes to learning and understanding where we have been and where we want to go. Reflection is difficult when you have failed, or think you have failed. When we judge, we tend to miss great opportunities to consider other interesting aspects and avenues. Judge less, explore more.
Dawn described some of the challenges she faced as she first became a tester, and discovering some of the ways she learned that she could be... problematic. As she grew into her testing roles, she sought out people who could help her see where she could improve, where she might be abrasive, and how she might overcome some of those aspects in her personality and approach. In the process she learned a lot, improved a lot and decided that she had more to give. In the process, she decided to start teaching. Since she learned so much from so many others, she decided that she wanted to and needed to give back. for those familiar with Dawn, you know that she gives back in spades! She left us with one simple question... What will you do? Will you write? Will you train? Will you mentor? Will you coach? Will you speak? Will you inspire? Whatever you do, just get out there and do it. Live... with no regrets. Give... with no regrets. Two thumbs up, Dawn! That was awesome!
---
Sabina walked us through the education initiatives she went through while studying for a CS degree, and the fateful decision via an internship that made her decide to make software testing her primary focus and goal going forward.
As she was working with other testers, she also felt the frustration of working with a group of testers that were not enthusiastic, not engaged, and just going through the motions. Very antithetical to the testing community that she had been hearing and learning about, so she decided to reach out and learn more about her options in the broader community, specifically in the local area of Kitchener-Waterloo (shout out to Selena Delesie and Paul Carvalho, I'm sure you were influential in this :) ). Through this, she came in contact with Rob Bowyer, and decided that she wanted to seek out a mentor, and as he was a recent hire, she felt she could trust him, and he encouraged her to attend CAST. The rest they say, is history :).
Rob's story was a little different. He came into the testing world in the late 90s, from a background in personal computer nerdery while studying English in University. He figured that technical writing would be his gig, but without credentials, how would he be able to do that. By getting some experience, he found himself gravitating to testing jobs and found himself interviewing for QA position. His desire to tweak was greater than his desire to write. His "mentor" introduced him to Cem Kaner's "Testing Computer Software". He worked a variety of different jobs over the years, ultimately bringing him to his current gig. He considered certification, but the cost and the, in his opinion, dubious quaifications of the cert options, he looked elsewhere, and decided to approach a community level of involvement and qualification (one that as an instructor in Miagi-do I can totally appreciate :) ).
There's lots of management literature, and there's lots of leadership literature, but much of what is out there is very "by the numbers". as anyone who has spent any time as a tester can attest, this is a business where "by the numbers" just doesn't work. Leadership needs to be personal, it needs to be servant leadership, and it needs to be strongly mentoring focused. Rob makes the case that mentoring doesn't need to be hierarchical; it also needs to be a relationship where we don't give them the answer, but help guide them to the answer.
Sabina threw a grenade at Rob and asked if he'd even seen her fail, and I liked Rob's answer; "I didn't necessarily see you fail, I let you make decisions that I might not have agreed with, but watched what you learned from those decisions and witnessed where you went forward from there."
An example that Rob mentioned was when Sabina started mentoring "co-ops" (similar to work internships for college students). Rob has occasionally given prescriptive advice, but tried to limit the way that he presented it. Sabina shared an experience where she had a co-op who was not interested in testing AT ALL. He'd actualy fall asleep at his desk (she'd bring him bak to attention by shooting him with a Nerf dart... Oh Sabina, I LOVE your style ;) ). Those are frustrating, and sometimes, you just have to move on or let people go and be mentored by others, or find what they really want to be doing. Sabina said that, in mentoring, if there is an issue, address it immediately, don't let it sit or fester. Break bad news early. It never gets better later.
Learning styles differ, an we don't get the opportunity to determine how someone we mentor learns. as a positive mentor, it's on us to adapt to the way that they learn best, not having them adapt to the way that we prefer to teach. Also, as mentors, we often have to let go of our original roles and focus so that we can better mentor others. We also have blind spots in ourselves that we need to become aware of to help us better mentor others. To do this, it also helps to have someone spend some time working with us to help us see in ourselves areas we might not be aware of. I've certainly appreciated the two way model where someone I am mentoring for one area or aspect acts as my mentor for another area.
Good attributes of mentors care broad and varied. I mentioned a friend of mine from way back at the beginning of my career who was an excellent mentor, and that his carefree attitude was hugely influential for me. Developing a continuous relationship is vital, and having an interest beyond just the job is important. The ability to be non-judgmental is critical. We need to step back and let testers discover many things for themselves, and to do that, we sometimes have to let opinions and our own judgments take a back seat. Good mentors also try to push limits and help those they are mentoring grow and take on new challenges.
Sabina did great in her first track talk, and I'm hoping to see future presentations with her (Rob did great as well, but you can tell, this is not a new experience for him :) ).
---
Some teams are directly tied to development, some are treated as part of IT, and other arrangements are not uncommon. Manuel suggested that a potential better alignment would be to have testers and test teams associated with the product group, not the technology team. What would this benefit? One potential benefit is that the product group is more focused on the customer needs and requirements, being closer to the ground with them. So the first thought being shared is "align the Org Chart" for the best fit for the organization and the organizations goals.
The second consideration is to focus on customer experience. The better customer experience we can provide, the overall better product we will produce, both from a technical and a design level. User experience has been, in my estimation, one of the most vital elements for testing, and leaving it for last or to not give it proper weight is a mistake.
The third area we should be focusing on is to analyze product risks. When the risks are placed up front, and considered at each level for the stakeholders, we can get s clearer indiction of which risks are the biggest, and from there, we can really prioritize what matters in conjunctions with a weighted understanding from each group.
The fourth is timing. When we focus too much on sprints or release dates, but often the bigger challenge is getting all moving parts together at the appropriate time, and having our estimates be less accurate or, perhaps, totally wrong. By identifying what needs to happen in the necessary time period, we can make prioritization decisions and determine what needs to be tested critically and what may not get much exposure at all.
Fifth is to be a positive voice. Yes, it's true, testers are often the bearers of bad news, but I think a lot of that is bad marketing and an unfair focus. Testers have long been placed into the role of being the ones who were the guardians of the gate, who gleefully said "hah, I found this bug!" For many, that's not just dis-spiriting, it's also annoying. For me, I personally prefer being able to focus on the positive aspects that we have tested and why I feel god about it, as well as the issues that we should consider fixing and why. In short, don't whine :).
Sixth is Lead Automation, as in software testers should take the lead and drive the test automation effort. I think this is a good opportunity, but again, a caveat, it's a good opportunity if there is a strong programmer in the group, and if the automation makes sense for the context. The testing group can do a huge service to the company and the executives by helping define where the automation really should be used. Also, we need to be clear that automation will not solve all problems, and automation performed "checks" can be helpful in covering areas to allow us to look at situations that could be more interesting.
The final idea is.... (drum roll)... Engage Early! The earlier we as testers can get involved, the sooner we can get into the particulars and find important issues. It also gives testers a chance to look at and consider potential pitfalls, traps, conflicts, blockers and understanding how to frame the testing story. Getting in early also gives us the most leverage to work with the programmers to make testing and testability possible.
Ultimately, we have an issue with credibility. If there is a contentious relationship, it comes down to credibility and trust. If there's low trust and low credibility, it's going to be a challenging relationship. If we can help build and maintain credibility and trust, by being involved in the process from the beginning, and being more visible through the whole project, we will have a much better opportunity to show our value all through the life cycle of software development.
---
Hmmm, so wait, there wasn't an update for the last talk session... what gives? Well, what gives is that someone came up to me to ask about getting involved in the SummerQAmp initiative and what they could do to be helpful.
We did come back in to see the top vote getters for the Lightning Talks last night, and it was fun to see the participants who took the most votes and thus were given the opportunity to present in the main ballroom and on the web stream. Those winners?
 |
| Julie Hurst: "Why am I Standing Here? The Tale of a new Conference Speaker" |
 |
| Alessandra Moreira: "Getting Teams to Warm Up to Exploratory Testing" |
 |
| Rachel Carson: "More Powerful Pair Testing" |
 |
| Jesse Alford: "Focusing the Mind's Eye - an Optics Analogy" |
We now come to the closing keynote, and Scott Barber and Rob Sabourin are going through and describing what they have learned from the other speakers. From Jon Bach's keynote through individual talks, there are a number of cool takeaways from the talks mentioned.
Such examples of cool takeaways:
We can argue and still be civil. Argument is the application of reason against reason. Let the better reasoning win.
You do not have to fight for every bug.
Lack of Priority, not a Lack of Time.
Describing tests at a high level can be a preventative measure against unintentional blindness.
Once you start to see things and thinking about things like a tester... you start to see everything that way.
I can learn, even if I get it wrong.
Design of experiments is a more valuable method of testing than QA.
Know your mission two levels up... does my context align with my boss and their bosses mission? How can I potentially match my context to theirs and the tasks at hand?
Build bridges, dare to disagree, be willing to be wrong, build on limitations, seeing as forgetting the names of things, testers make mistakes.
True mentoring is a two way, lifetime contract predicated on trust, respect and a mutual commitment to continuous improvement.
Learn in a safe haven, model testing as part of an ecosystem, regression as a swear word, be vigilant and like a sponge, build trust with matriarchs, daily debrief even when alone, expect the unexpected and respect it.
"Don't throw Excel spreadsheets at me. Don't whine. Articulate your strategy or replace yourself" - advice from a CEO of a company to software testers.
Role of a quality leader in an Agile transition, learn by sharing stories, get the whole team on the same page wrt quality standards for the team.
The Four Schools of Software Testing... stop talking about schools, discuss culture instead.
The final slide has asked us...
What Did You Learn at CAST?
Where did you learn it?
How will you apply it?
If I had to pick any one item, by itself, it would have to be from Manuel and Dee's talk, and it is as follows... "Articulate your strategy or replace yourself". This is an encapsulating question, and it covers so much. We need to tell a better story. With all of the journalism metaphors that are floating around out there, and the emphasis on telling a compelling story, it feels like few are really tapping into this the way we should. How will I apply this? I will focus on the stories I work on at the very beginning of the process and trying to see the full "story", work towards that full story, and better articulate the vision and focus of the testing team. The tools to do that? Genuine testing skills, better writing, sharpened tools, and a desire to truly understand the needs of my customers... all my customers."
---
No comments:
Post a Comment