We hear about organizations dealing with change for applications and hardware that are in data centers or in server farms in remote locations, but how about making changes to equipment that resides outside of Earth orbit... or on another planet entirely! Barbara Streiffert gets to deal with that reality as part of the Jet Propulsion Laboratory. She deals with testing of the Mars Rover, among other initiatives. Talk about a risk averse environment!
So much of this talk was specific to information shown on video. She showed us details about the Dawn Spacecraft and Ion Propulsion... wow, talk about a unique test experience! How cool would it be to work on systems that control Ion Engines! For those not familiar with what an Ion Thruster is, instead of heating the gas up, xenon is introduced into the gas chamber, and the ionization that results causes thrust (that's what I heard, I will not vouch that I got that right ;) ). Fortunately, this talk was part of webCAST, so everyone can see the videos and details.
The Dawn spacecraft flyover of Ceres is being shown, and my inner third grader is totally spazzing out right now :).
Wednesday, August 5, 2015
The Art and Science of Questioning - Live at #$CAST2015
It's fun being a facilitator, in that you get to actively participate in the discussion, and it also gets you up and moving. today I'll be spending most of my time facilitating the webCAST room, so if you see a bald guy in a white AST polo running around, yep, that is me :).
Jess Ingrasselino (@jess_ingrass) works with Bit.ly and worked as a music teacher prior to her tech career. I think that having that background is probably awesome for her being involved in programming and testing. She explained how she went from being a music teacher to quality assurance engineer, and that the processes are actually very similar. When a violinist or violist wants to start playing the Brandenburg Concerto, they don't start with the full piece. They start with the first note, or the first theme, and then they grow from there. There is a focus on building the knowledge and experience with performance and practice. Software testing does much the same thing; we start small with basic concepts, and we practice and apply them.
Testers ask questions, but not just any questions. They need to be targeted and specific, such that they may better understand and learn the product, and focus on other aspects of the product. I'm fond of the definition of testing that I use, which is "Ask the product a question, and based on the answer you receive, ask additional and more interesting questions."
Jess makes a case that borrowing from social science, and understanding the methods used in "qualitative research" makes it possible for us to ask compelling questions The methods Jess will use for this come from Robert Stakes. One of the areas to focus on is "multiple interpretation". What happens when different people with different permissions logged into the system? What is shared? What is unique to certain permissions?
One of the things that is vexing about asking questions is that we can fall into the trap of asking questions that are self-serving. We can easily craft questions that will provide answers that support our own beliefs or biases. We need to be aware of the unintentional ways that we word things or couch questions. Instead of asking "what issues are you having with development?", ask "can you describe for me your interactions with the functional teams in the organization?". Yeah, that seems like a squishy way of asking questions, but it allows the person being questioned to provide an answer free of initial or expected negativity. Instead of asking them to tell us what is wrong, we ask them what they do. In the process, they may more freely describe what is going wrong.
Another compelling answer to questions is silence. Yep. I've seen this many times, and silence means many things. It can mean "I'm thinking" or it can mean "I'm waiting to see if you will walk back that answer before I open my mouth." gauge the silence and don't be afraid to meet the silence with silence. It can often be used as a negotiating tactics. The marks are usually people who cannot get through the quiet and will start saying something, anything, to break the silence. Often, people who negotiate find that they settle for far less than they would if they were more focused on maintaining the silence.
Testers are, or should be, fundamentally curious. Even with that, asking questions is a skill, and it's one that can be developed. I see that studying up on qualitative research is in my future :).
Jess Ingrasselino (@jess_ingrass) works with Bit.ly and worked as a music teacher prior to her tech career. I think that having that background is probably awesome for her being involved in programming and testing. She explained how she went from being a music teacher to quality assurance engineer, and that the processes are actually very similar. When a violinist or violist wants to start playing the Brandenburg Concerto, they don't start with the full piece. They start with the first note, or the first theme, and then they grow from there. There is a focus on building the knowledge and experience with performance and practice. Software testing does much the same thing; we start small with basic concepts, and we practice and apply them.
Testers ask questions, but not just any questions. They need to be targeted and specific, such that they may better understand and learn the product, and focus on other aspects of the product. I'm fond of the definition of testing that I use, which is "Ask the product a question, and based on the answer you receive, ask additional and more interesting questions."
Jess makes a case that borrowing from social science, and understanding the methods used in "qualitative research" makes it possible for us to ask compelling questions The methods Jess will use for this come from Robert Stakes. One of the areas to focus on is "multiple interpretation". What happens when different people with different permissions logged into the system? What is shared? What is unique to certain permissions?
One of the things that is vexing about asking questions is that we can fall into the trap of asking questions that are self-serving. We can easily craft questions that will provide answers that support our own beliefs or biases. We need to be aware of the unintentional ways that we word things or couch questions. Instead of asking "what issues are you having with development?", ask "can you describe for me your interactions with the functional teams in the organization?". Yeah, that seems like a squishy way of asking questions, but it allows the person being questioned to provide an answer free of initial or expected negativity. Instead of asking them to tell us what is wrong, we ask them what they do. In the process, they may more freely describe what is going wrong.
Another compelling answer to questions is silence. Yep. I've seen this many times, and silence means many things. It can mean "I'm thinking" or it can mean "I'm waiting to see if you will walk back that answer before I open my mouth." gauge the silence and don't be afraid to meet the silence with silence. It can often be used as a negotiating tactics. The marks are usually people who cannot get through the quiet and will start saying something, anything, to break the silence. Often, people who negotiate find that they settle for far less than they would if they were more focused on maintaining the silence.
Testers are, or should be, fundamentally curious. Even with that, asking questions is a skill, and it's one that can be developed. I see that studying up on qualitative research is in my future :).
The Future Is Here - Live at #CAST2015
It's Wednesday, and to be honest, the events of the past several days have become a blur. I've been in Grand Rapids since Friday, and I've been moving non-stop since I've been here. Test Retreat, conference setup, facilitator meetings, elections, logistics, rooms, venue preparations... it's easy to lose track of where we are and why we are here. I joked a few days back that I and the rest of the board and conference committee were busy doing all we could "to make all your wildest conference dreams come true". I'm not sure how we've delivered on that, but from the tweets I have seen, and the comments directed to me thus far, I think we're doing pretty good on that front :).
I was excited to see that Ajay Balamurugadas was chosen to be Wednesday's Keynote speaker. Ajay was one of the first software testers I had the pleasure to interact with when I chose to plug into the broader software testing community. Many testers were saying things and spouting ideas, but Ajay was rolling up his sleeves, doing stuff in real time, and sharing his results, both good and bad. Ajay introduced me to Weekend Testing, and then encouraged me to bring it to the USA. He stayed up late for his time to shadow me and offer suggestions for the first few sessions we did, and then he let me fly on my own. He has participated with many of our Weekend Testing sessions, including a session with flawk, which is a company my friend Matt Coalson has been building the past few years. Matt's literal words to me about the session was "Dude, that guy, Ajay? Wow, he's the real deal!" Ajay has put the time and the energy in to prove, time and again, that yes, he is indeed the real deal!
Ajay did something pretty bold for a keynote speaker. he put up a mind map of his talk and the details titled "Should I listen to Ajay?" In a nutshell, he says that he will be covering Learning opportunities, a trend in who tests, testing education, testing & other fields, Standards and schools, and his own thoughts. He then said he invited those with more important things to do to leave, and he would be totally OK with that. Notice I'm still typing ;). Right now, this is the most important thing I can be doing :).
Ajay starts with a quote from Aldous Huxley... "try to learn something about everything, and everything about something". In a nutshell, to borrow from Alan Page (and yes, others say it too, but Alan is famous for talking about this on the AB Testing Podcast) "be a generalizing specialist as well as a specializing generalist". Be T-Shaped, a jack of al trades who makes a priority of getting genuinely geeky with a few areas that you enjoy and feel are valuable. Don't just be a software tester, actually learn about software testing. Some ideas are going to be better than others, but dig in and try ideas out. Learn as much as you can, even if it's to decide what you will discard and what you will keep. Why do we so often welcome new testers with test cases? Do we not trust them to be able to test, or do we just insist on them doing what we tell them of front, with hopes that their creativity will appear later? If they are given prescriptive test cases, and told to execute them, don't be surprisedif that hoped for creativity does not appear.
there are several organizations taht exist to help teach software testers, some obvious and some less so. Ministry of testing, Weekend Testing, BBST Testing Courses, Udemy, Coursera, Test Insane's Mind Map collection, the Software Testing World Cup... there's *lots* of places we can learn and try out new ideas.
Ajay said something pretty cool (attribution missed, will fill in later).. "If you would like to double your income, triple your learning!" we each need to take the opportunities we have, and we need to apply them. I personally believe that my blog exists for this purpose. Sometimes I have let several days go fallow without writing because I feel I don't have anything unique to share. However, I have had such a rush these past few days writing summaries and interpretations of each of the sessions I've been involved in since Saturday. Before August, my largest number of blog posts for any given month was nine, and sometimes I felt like I struggled to get those out. Right now, I'm writing the eighteenth blog post for August, all of which inspired by my being here in Grand Rapids, with the activities I've been participating in. If all goes well, I may have four more to offer by the end of today. Seriously, that's twenty-two blog posts in five days! What's interesting is that, as I've written so many, I'm feeling energized, and I want to keep that energy going. That's the power of diving into your learning, and creating in the process. I want to see what it takes to keep it going.
Ajay has asked why you need a title to be a leader? The truth is, you don't. You can lead right now, and you can be an example and a guide to others. You do not need to ask permission, you just need to act with conviction and determination. Figure out the things you can do without having to ask permission, and dig in. If a process is slow, try another one. In parallel, if you must, or totally replace the old efforts with a new approach if you can do so. People may feel frustrated if you go and do something without asking, but they will likely keep what you are doing if you deliver a better result than what they were getting before.
What do you say when someone says "I'd like to become a software tester, what do I need to know?". Do we tell them the truth, that it can be exceptionally hard, and that there is so much to learn? Do we tell them that there's a lot of things they can get involved with? Do we encourage their curiosity, and get them engaged where they are? Personally, I think we can do a lot of good by starting with where people are and showing them the fun and experience software testing can be. Granted, it's not always fun, but there's plenty of opportunities to explore and be curious. De-emphasize the mechanics of testing, encourage the curiosity. Software testing classes are developing. I'm biased, but I'm pretty fond of the BBST courses and what they offer. Still, there's a need for more, and we have an opportunity to help make that happen. It will take time, of course, but there is a need for excellent software testing training. Let's do what we can to foster and develop it.
My thanks to Ajay and his devotion to our craft. He's a role model that I believe any software tester would do well to emulate, myself included. At this point I need to get ready for Open Season and help facilitate questions and answers. Thanks for playing along with me today, I'll be back in a bit :).
I was excited to see that Ajay Balamurugadas was chosen to be Wednesday's Keynote speaker. Ajay was one of the first software testers I had the pleasure to interact with when I chose to plug into the broader software testing community. Many testers were saying things and spouting ideas, but Ajay was rolling up his sleeves, doing stuff in real time, and sharing his results, both good and bad. Ajay introduced me to Weekend Testing, and then encouraged me to bring it to the USA. He stayed up late for his time to shadow me and offer suggestions for the first few sessions we did, and then he let me fly on my own. He has participated with many of our Weekend Testing sessions, including a session with flawk, which is a company my friend Matt Coalson has been building the past few years. Matt's literal words to me about the session was "Dude, that guy, Ajay? Wow, he's the real deal!" Ajay has put the time and the energy in to prove, time and again, that yes, he is indeed the real deal!
Ajay did something pretty bold for a keynote speaker. he put up a mind map of his talk and the details titled "Should I listen to Ajay?" In a nutshell, he says that he will be covering Learning opportunities, a trend in who tests, testing education, testing & other fields, Standards and schools, and his own thoughts. He then said he invited those with more important things to do to leave, and he would be totally OK with that. Notice I'm still typing ;). Right now, this is the most important thing I can be doing :).
Ajay starts with a quote from Aldous Huxley... "try to learn something about everything, and everything about something". In a nutshell, to borrow from Alan Page (and yes, others say it too, but Alan is famous for talking about this on the AB Testing Podcast) "be a generalizing specialist as well as a specializing generalist". Be T-Shaped, a jack of al trades who makes a priority of getting genuinely geeky with a few areas that you enjoy and feel are valuable. Don't just be a software tester, actually learn about software testing. Some ideas are going to be better than others, but dig in and try ideas out. Learn as much as you can, even if it's to decide what you will discard and what you will keep. Why do we so often welcome new testers with test cases? Do we not trust them to be able to test, or do we just insist on them doing what we tell them of front, with hopes that their creativity will appear later? If they are given prescriptive test cases, and told to execute them, don't be surprisedif that hoped for creativity does not appear.
there are several organizations taht exist to help teach software testers, some obvious and some less so. Ministry of testing, Weekend Testing, BBST Testing Courses, Udemy, Coursera, Test Insane's Mind Map collection, the Software Testing World Cup... there's *lots* of places we can learn and try out new ideas.
Ajay said something pretty cool (attribution missed, will fill in later).. "If you would like to double your income, triple your learning!" we each need to take the opportunities we have, and we need to apply them. I personally believe that my blog exists for this purpose. Sometimes I have let several days go fallow without writing because I feel I don't have anything unique to share. However, I have had such a rush these past few days writing summaries and interpretations of each of the sessions I've been involved in since Saturday. Before August, my largest number of blog posts for any given month was nine, and sometimes I felt like I struggled to get those out. Right now, I'm writing the eighteenth blog post for August, all of which inspired by my being here in Grand Rapids, with the activities I've been participating in. If all goes well, I may have four more to offer by the end of today. Seriously, that's twenty-two blog posts in five days! What's interesting is that, as I've written so many, I'm feeling energized, and I want to keep that energy going. That's the power of diving into your learning, and creating in the process. I want to see what it takes to keep it going.
Ajay has asked why you need a title to be a leader? The truth is, you don't. You can lead right now, and you can be an example and a guide to others. You do not need to ask permission, you just need to act with conviction and determination. Figure out the things you can do without having to ask permission, and dig in. If a process is slow, try another one. In parallel, if you must, or totally replace the old efforts with a new approach if you can do so. People may feel frustrated if you go and do something without asking, but they will likely keep what you are doing if you deliver a better result than what they were getting before.
What do you say when someone says "I'd like to become a software tester, what do I need to know?". Do we tell them the truth, that it can be exceptionally hard, and that there is so much to learn? Do we tell them that there's a lot of things they can get involved with? Do we encourage their curiosity, and get them engaged where they are? Personally, I think we can do a lot of good by starting with where people are and showing them the fun and experience software testing can be. Granted, it's not always fun, but there's plenty of opportunities to explore and be curious. De-emphasize the mechanics of testing, encourage the curiosity. Software testing classes are developing. I'm biased, but I'm pretty fond of the BBST courses and what they offer. Still, there's a need for more, and we have an opportunity to help make that happen. It will take time, of course, but there is a need for excellent software testing training. Let's do what we can to foster and develop it.
My thanks to Ajay and his devotion to our craft. He's a role model that I believe any software tester would do well to emulate, myself included. At this point I need to get ready for Open Season and help facilitate questions and answers. Thanks for playing along with me today, I'll be back in a bit :).
Early Morning Musings - Live from #CAST2015
For those not familiar with the concept of Lean Coffee, a group gathers together (coffee optional), proposes a set of topics, organizes the topics to see if there are synergies, votes on the topics to set the order of discussion, and then goes into discussion of each item for an initial five minutes. If there is still energy for the topic after the first five minutes, we can vote to continue the discussion or stop it and move on to another topic.
Today's attendees are/were:
Perze Ababa, Carol Brands, James Fogarty, Albert Gareev, Dwayne Green, Matt Heusser, Allen, Johnson, Michael Larsen, Jeff MacBane, Justin Rohrman, Carl Shaulis
Topics that made the stack:
Testing Eduction, What's Missing?
Thoughts thrown out by the group: Accessibility, Test Tooling, Mobile and Embedded, Emerging Technologies, Social, Local, Geographically Tied Applications, Testing Sttrategy
Of all of these ideas, the testing strategy seemed to get the most traction. Everyone seems to think they know what it is, but it's a struggle to articulate it. Regulatory compliance could be a relevant area. What about shadowing a company(s) and see what they are doing with their new testers, especially those who are just starting out? What are their needs? What do they want to learn? What do those companies want to have them learn? Consider it an anthropology experiment. Action was to encourage the attendees to see which companies would be game to be part of the study (anonymized).
How Can We Grow Software Testers Through our Local Meetup Groups?
Getting topics of interest is always a challenge. How do we focus on areas that are interesting and relevant without being too much the same as what they deal with a work. Albert has been hosting a Resume Club at his Toronto Testers Meetup, and that's been a successful focus. Gaps in experience can help drive those discussions. Lean Coffee format itself can be used in meetups, and the topics discussed can help develop new topics that appear to be of interest to the community. Encourage games and social interaction, we don't necessarily have to focus on talks and discussion. ST Grant program can also be used for this. We offer grant funds for meetup support, but we also have the option of flying in people to meetups to help facilitate events as well (Michael did this in Calgary back in 2012 for the POST peer conference). If monthly meetup is too difficult, commit to quarterly and work to recruit speakers in the in between time. If the critical mass gets large enough, schedule more meetings. Have a round robin discussion from a talk that's already been presented and recorded. Make workshops based on topics of interest.
Writing Code For Testers Via Web Based Apps
Matt discussed this around a web app that aims to help teach people to program (as part of a Book to Teach People How to Code in Java). In a way, this is a two part problem. On one hand, there's the interface to engage and inform the user to get involved and learn how to code. The second is the meta-elements that can determine if the suer has completed the objective and can suggest what to do. Both require testing, but both have different emphases (the ability for an application to determine if "code is correct" can be challenging, and there is always TiM TOWTDI to consider (There Is More Than One Way To Do It).
Good discussions, good ideas to work with, and so many more possible things we didn't even get to consider. Lock and learn for me is that it might be cool to run an anthropology experiment with other companies to see what they want to have their testers learn.
Time for breakfast, see you all in a bit :).
Today's attendees are/were:
Perze Ababa, Carol Brands, James Fogarty, Albert Gareev, Dwayne Green, Matt Heusser, Allen, Johnson, Michael Larsen, Jeff MacBane, Justin Rohrman, Carl Shaulis
Topics that made the stack:
Testing Eduction, What's Missing?
Thoughts thrown out by the group: Accessibility, Test Tooling, Mobile and Embedded, Emerging Technologies, Social, Local, Geographically Tied Applications, Testing Sttrategy
Of all of these ideas, the testing strategy seemed to get the most traction. Everyone seems to think they know what it is, but it's a struggle to articulate it. Regulatory compliance could be a relevant area. What about shadowing a company(s) and see what they are doing with their new testers, especially those who are just starting out? What are their needs? What do they want to learn? What do those companies want to have them learn? Consider it an anthropology experiment. Action was to encourage the attendees to see which companies would be game to be part of the study (anonymized).
How Can We Grow Software Testers Through our Local Meetup Groups?
Getting topics of interest is always a challenge. How do we focus on areas that are interesting and relevant without being too much the same as what they deal with a work. Albert has been hosting a Resume Club at his Toronto Testers Meetup, and that's been a successful focus. Gaps in experience can help drive those discussions. Lean Coffee format itself can be used in meetups, and the topics discussed can help develop new topics that appear to be of interest to the community. Encourage games and social interaction, we don't necessarily have to focus on talks and discussion. ST Grant program can also be used for this. We offer grant funds for meetup support, but we also have the option of flying in people to meetups to help facilitate events as well (Michael did this in Calgary back in 2012 for the POST peer conference). If monthly meetup is too difficult, commit to quarterly and work to recruit speakers in the in between time. If the critical mass gets large enough, schedule more meetings. Have a round robin discussion from a talk that's already been presented and recorded. Make workshops based on topics of interest.
Writing Code For Testers Via Web Based Apps
Matt discussed this around a web app that aims to help teach people to program (as part of a Book to Teach People How to Code in Java). In a way, this is a two part problem. On one hand, there's the interface to engage and inform the user to get involved and learn how to code. The second is the meta-elements that can determine if the suer has completed the objective and can suggest what to do. Both require testing, but both have different emphases (the ability for an application to determine if "code is correct" can be challenging, and there is always TiM TOWTDI to consider (There Is More Than One Way To Do It).
Good discussions, good ideas to work with, and so many more possible things we didn't even get to consider. Lock and learn for me is that it might be cool to run an anthropology experiment with other companies to see what they want to have their testers learn.
Time for breakfast, see you all in a bit :).
Tuesday, August 4, 2015
Leaping into Context - Live from #CAST2015
Erik Brickarp gets the nod for my last session today. After facilitating three talks, it feels nice to just sit and listen :).
Erik's talk focuses on "A leap towards Context-Driven Testing". When chaos and discord start raining down on our efforts, sometimes the best break through comes with a break with. In 2012, he joined a new team at a big multinational telecom company. That team had a big, clunky, old school system for both documentation and loads of test cases (probably based on ISO-9001, and oh do I remember those days :p ). What's worse, the teeam was expected to keep using these approaches. To Erik's credit, he decided to see if he could find a way out of that agreement.
The team decided they needed to look at the product differently. Rather than just focus on features and functions, he also decided to look at ways that the project could be tested. In the process of trying to consider what the test approach had to be, they moved from multiple spreadsheets to web pages that could allow collaboration. By using colors in tables (as they used previously in cells) they were able to quickly communicate information by color and by comment (reminds me of Dhanesekhar's tutorial yesterday ;)).
By stepping away from iron-clad rules and instead focusing on guidelines, they were able to make their testing process work more efficiently. Of course, with changes and modifications, this welcomes criticism. The criticism was not based on the actual work, but they were upset that the junior team member went behind the back of the organization to "change the rules". Fortunately, due to the fact that the work was solid and the information being provided was effective, informative and actionable, they let them continue. In the following weeks, they managed to make the test teams deliverables slimmer and more meaningful, faster to create and easier to maintain. By using a wiki, they were able to make the information searchable, reports listable, and easy to find.
Erik admits that the approach he used was unprofessional, but he was fortunate in the fact that the effort was effective. As a lesson learned, he said that he could have approached this with better communication and could have made these changes without going behind their backs. Nevertheless, they did, and so they have a much more fun story to tell. The takeaway here is that there is a lot of things we can do to improve our test process that don't specifically require corporate sanction. It also shows that we can indeed make changes that could be dramatic and not introduce a ton of risk. Support is important, and making sure the team supports your efforts can help testers (or any team) make transitions, whether they be dramatic or somewhat less so.
Additionally, if you have a hope to change from one paradigm to another, it helps a great deal to understand what you are changing to and how you communicate those changes. Additionally, make sure you keep track of what you are doing. Keeping track doesn't mean having to adopt a heavy system, but you do have to keep track. Exploratory testing doesn't mean "random and do anything". It means finding new things, purposefully looking for new areas, and making a map of what you find. When in doubt, take notes. After all that, make sure to take some time to reflect. Think about what is most important, what is less important, and what I should be doing next. Changing the world is important, and if you feel the need to do so, you might want to take a page from Erik's book. I'll leave it to you to decide if it makes sense to do it in full stealth mode or with your company's approval. the latter is more professional, but the former might be a lot more fun ;).
Erik's talk focuses on "A leap towards Context-Driven Testing". When chaos and discord start raining down on our efforts, sometimes the best break through comes with a break with. In 2012, he joined a new team at a big multinational telecom company. That team had a big, clunky, old school system for both documentation and loads of test cases (probably based on ISO-9001, and oh do I remember those days :p ). What's worse, the teeam was expected to keep using these approaches. To Erik's credit, he decided to see if he could find a way out of that agreement.
The team decided they needed to look at the product differently. Rather than just focus on features and functions, he also decided to look at ways that the project could be tested. In the process of trying to consider what the test approach had to be, they moved from multiple spreadsheets to web pages that could allow collaboration. By using colors in tables (as they used previously in cells) they were able to quickly communicate information by color and by comment (reminds me of Dhanesekhar's tutorial yesterday ;)).
By stepping away from iron-clad rules and instead focusing on guidelines, they were able to make their testing process work more efficiently. Of course, with changes and modifications, this welcomes criticism. The criticism was not based on the actual work, but they were upset that the junior team member went behind the back of the organization to "change the rules". Fortunately, due to the fact that the work was solid and the information being provided was effective, informative and actionable, they let them continue. In the following weeks, they managed to make the test teams deliverables slimmer and more meaningful, faster to create and easier to maintain. By using a wiki, they were able to make the information searchable, reports listable, and easy to find.
Erik admits that the approach he used was unprofessional, but he was fortunate in the fact that the effort was effective. As a lesson learned, he said that he could have approached this with better communication and could have made these changes without going behind their backs. Nevertheless, they did, and so they have a much more fun story to tell. The takeaway here is that there is a lot of things we can do to improve our test process that don't specifically require corporate sanction. It also shows that we can indeed make changes that could be dramatic and not introduce a ton of risk. Support is important, and making sure the team supports your efforts can help testers (or any team) make transitions, whether they be dramatic or somewhat less so.
Additionally, if you have a hope to change from one paradigm to another, it helps a great deal to understand what you are changing to and how you communicate those changes. Additionally, make sure you keep track of what you are doing. Keeping track doesn't mean having to adopt a heavy system, but you do have to keep track. Exploratory testing doesn't mean "random and do anything". It means finding new things, purposefully looking for new areas, and making a map of what you find. When in doubt, take notes. After all that, make sure to take some time to reflect. Think about what is most important, what is less important, and what I should be doing next. Changing the world is important, and if you feel the need to do so, you might want to take a page from Erik's book. I'll leave it to you to decide if it makes sense to do it in full stealth mode or with your company's approval. the latter is more professional, but the former might be a lot more fun ;).
Get Your Gandalf On For #a11y Testing - Live at #CAST2015
We spent the first part of the session framing the problem and encouraging the attendees to discuss the issues, now we are unleashing the hounds and letting them hear what a site sounds like as seen by a screen reader. To be brave, we submitted the AST web site to the #a11y treatment. Needless to say, we have some work to do to behave better with screen readers, but it made for a great way to discuss the challenges.
We have two angles we use to approach the acccessibility question. The first is to frame questions we can ask and principles we can discuss at the initial design phase. The ten principles I like to use come from Jeremy Sydik's book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms (Pragmatic Publishing, 2007)":
Albert encourages testers to embrace "PaSaRaN". the word "pasaran" in Spanish means "They Shall Pass". If you say "no pasaran" you are effectively saying "you shall not pass"... and now my cheesy title should make a little sense ;).
PaSaRaN is a method of testing if a Page allows for Accessible Scanning, Accessible Reading
and Accessible Navigation.
It's entirely possible that you can go through your testing career and never get involved in an Accessibility project, but it's a very good bet that issues surrounding Accessibility will affect you at some point in your life, whether it be in a secondary or primary aspect. If you would like to evaluate products for Accessibility, PaSaRaN is a clever short-hand. If you find yourself getting into site design or web development, I'd like to encourage you to consider the ten principles and be HUMBLE in your designing and coding. Also, if you would like to talk about any of the stuff that we covered directly in the workshop, please feel free to contact either Albert or me and we'll be happy to answer any questions.
We have two angles we use to approach the acccessibility question. The first is to frame questions we can ask and principles we can discuss at the initial design phase. The ten principles I like to use come from Jeremy Sydik's book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms (Pragmatic Publishing, 2007)":
- Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
- Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
- Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
- Provide good text alternatives for any non-text content.
- Use widely available technologies to reach your audience.
- Use clear language to communicate your message.
- Make your sites usable, searchable, and navigable.
- Design your content for semantic meaning and maintain separation between content and presentation.
- Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
- As you encounter new web technologies, apply these same principles when making them accessible.
From there, when we consider the design issues we want to discuss, if we want to be ready to discuss the requirements and do early testing on initial designs, we can use a heuristic called HUMBLE:
Humanize: be empathetic, understand the emotional components.
Unlearn: step away from your default [device-specific] habits. Be able to switch into different habit modes.
Model: use personas that help you see, hear and feel the issues. Consider behaviors, pace, mental state and system state.
Build: knowledge, testing heuristics, core testing skills, testing infrastructure, credibility.
Learn: what are the barriers? How do users Perceive, Understand and Operate?
Experiment: put yourself into literal situations. Collaborate with designers and programmers, provide feedback
Both the design principles and the HUMBLE heuristic are useful early in the process of discussing Inclusive Design and overall Accessibility coding. What can we do when we are testing an existing feature, and we are evaluating it for Accessibility? We are working on a feature that is Dev Complete and has been delivered for testing. Do we have some suggestions for that situation? As a matter of fact, yes :).
Albert encourages testers to embrace "PaSaRaN". the word "pasaran" in Spanish means "They Shall Pass". If you say "no pasaran" you are effectively saying "you shall not pass"... and now my cheesy title should make a little sense ;).
PaSaRaN is a method of testing if a Page allows for Accessible Scanning, Accessible Reading
and Accessible Navigation.
It's entirely possible that you can go through your testing career and never get involved in an Accessibility project, but it's a very good bet that issues surrounding Accessibility will affect you at some point in your life, whether it be in a secondary or primary aspect. If you would like to evaluate products for Accessibility, PaSaRaN is a clever short-hand. If you find yourself getting into site design or web development, I'd like to encourage you to consider the ten principles and be HUMBLE in your designing and coding. Also, if you would like to talk about any of the stuff that we covered directly in the workshop, please feel free to contact either Albert or me and we'll be happy to answer any questions.
Finding Your #a11y in Accessibility - Live from #CAST2015
Albert Gareev and I have been working on the material for this presentation for a long time, so I am excited to be facilitating this workshop session. Albert is making his debut as a speaker at CAST, and more important, this conference has been the first time we have met each other in person. We've collaborated online for five years, so to finally get to work together on this material as relates to accessibility means a lot to both of us. The fact that we have a group of people interested in participating with us is icing on the cake :).
Accessibility is not just for people with "special needs". Accessibility comes into play for everyone at some point. In the presentation, we presented an example of a person with several "physical impairments" and asked the group to tell us what this person looked like. We had some interesting discussions, and then we revealed the trap, a picture of a young lady looking at her cell phone while walking across the street. After a few chuckles and an explanation, we introduced the idea of "secondary disability" or the fact that there are certain environments where a person has a special need, where in their regular environments they might not. Over time, if we are lucky to live long enough every one of us will deal with a special need that falls into the Accessibility realm. If we have impressed on the group that Accessibility is more than just for people with specific disabilities, I will consider that a huge success.
Albert and I both agree that putting a heuristic out there for people to use, while helpful, is much more potent when it is seen in action. A few months ago, I had the chance to give an accessibility talk at STP-CON in San Diego, and as part of my presentation, I asked the participants to fire up a screen reader on their systems and navigate to one of their favorite pages. As the screen reader started to do its job, the reactions were both amusing, and very telling. They "saw" how difficult it was for non-sighted users to "listen" to the information on the screen. They were drowned by the rapid fire speech that was trying to articulate what was on the page. this was one example and one condition. There are many other areas that accessibility covers as well (non-sighted, limited-sight, no-hearing, limited-hearing, limited movement, limited cognitive ability, etc.).
Accessibility is a difficult requirement to test for, in the sense that context has to be taken into consideration. Most of the time, we have to pick and choose which Accessible features we will use and who we will address. Is it enough to make a screen reader work with the product? Do we need to also had closed captioning for hearing-impaired? Do we have a way to make shortcuts for limited movement? Are we looking to address all of them at once, or are we willing to take them on one at a time.
We're taking a break now, so this seems like a good time to push this out. I'l come back with part two of our workshop in a bit.
Accessibility is not just for people with "special needs". Accessibility comes into play for everyone at some point. In the presentation, we presented an example of a person with several "physical impairments" and asked the group to tell us what this person looked like. We had some interesting discussions, and then we revealed the trap, a picture of a young lady looking at her cell phone while walking across the street. After a few chuckles and an explanation, we introduced the idea of "secondary disability" or the fact that there are certain environments where a person has a special need, where in their regular environments they might not. Over time, if we are lucky to live long enough every one of us will deal with a special need that falls into the Accessibility realm. If we have impressed on the group that Accessibility is more than just for people with specific disabilities, I will consider that a huge success.
Albert and I both agree that putting a heuristic out there for people to use, while helpful, is much more potent when it is seen in action. A few months ago, I had the chance to give an accessibility talk at STP-CON in San Diego, and as part of my presentation, I asked the participants to fire up a screen reader on their systems and navigate to one of their favorite pages. As the screen reader started to do its job, the reactions were both amusing, and very telling. They "saw" how difficult it was for non-sighted users to "listen" to the information on the screen. They were drowned by the rapid fire speech that was trying to articulate what was on the page. this was one example and one condition. There are many other areas that accessibility covers as well (non-sighted, limited-sight, no-hearing, limited-hearing, limited movement, limited cognitive ability, etc.).
Accessibility is a difficult requirement to test for, in the sense that context has to be taken into consideration. Most of the time, we have to pick and choose which Accessible features we will use and who we will address. Is it enough to make a screen reader work with the product? Do we need to also had closed captioning for hearing-impaired? Do we have a way to make shortcuts for limited movement? Are we looking to address all of them at once, or are we willing to take them on one at a time.
We're taking a break now, so this seems like a good time to push this out. I'l come back with part two of our workshop in a bit.
Can I Lean on My Context at My Startup? - Live at #CAST2015
Eric Reis wrote an interesting book called "The Lean Startup" back in 2011, and it's become quite the buzzword du jour. Thomas Vaniotis has decided that he wants to get beyond the buzzwords and actually discuss Lean Startup and make the case that Lean Startup is all about testing.
Thomas recently made the shift from Technical Tester to Product Manager, working with a "Lean Startup" and he states categorically that he is doing as much testing as ever, if not more so. Thomas uses Eric Reis' definition of a startup, which is "a human institution designed to create a product or service within an environment with extreme uncertainty". "Lean" is the idea that we want to focus on the essential value, and remove the waste from the system wherever possible. Put the two concepts together, and you get "Lean Startup". This means that organizations that embrace this are going to look rather different from one another. It also means that what is considered value and what is considered waste will be different in each organization. Testers, this means that context matters a LOT!
Waste can vary. Overproduction is a real issue in a literal product factory, but it's also visible in software for features that are not used or have no value. Code needs to be maintained, tests need to be run, refactoring needs to take these empty features into account, and other features that may be more important are not made because the time is being spent working on stuff that is not relevant. Idle machines are a reality in factories, and backlogs in moving features forward is every bit as bad. I see this when we have a number of stories in DevComplete but with no testers with open cycles to work on them. What happens? They sit there until they can be picked up and addressed. Over time, this lag can be significant; getting a feature from PM proposal to shipped can take days, but some times it can take months or even years. In all, identifying waste takes some time and talent to recognize, and it can be a real struggle to eradicate it once it builds up.
There's waste in programming, there's waste in design, there's waste in testing,and there's waste in release. It just happens. the goal is not to eliminate it, but it is important to look to see where waste occurs and see what can be minimized. Testing is part of of the waste production and waste prevention culture. It's a solid part of what we do as testers, not just to find problems but to also find inefficiencies that we can work on. How do we do that? We can do that with Validated Learning, which means we subject failure to scrutiny, which in turn opens us up to failure. It's possible our investigation may disprove our hypothesis. Our experiment may show that we are wrong in our assumptions, but learning that also helps us expose and remove waste, even if the waste we remove is faulty assumptions of our own.
One of the ways we can help drive the learning is with a "Minimum Viable Product". This is an ideal method for applying what is called the "Build-Measure-Learn" loop. By building the smallest possible product, we can learn if our ideas our sound, if our product meets the need and if the data we receive supports the notion that we are on the right track. testers do this all the time, even with something that's not a MVP. New ideas are spun out from each cycle of this process. If this looks a lot like exploratory testing, indeed, it is :).
Thomas used a number of interesting examples (Zappos, Dropbox, etc.) and how they made their minimum viral product. For Dropbox, it was a video explaining why they had a solution for something most people hadn't figured out was even a problem. Additionally, Dropbox did it in a way that everyone could understand... it's a folder. That's it! For most people, that's all they need to know or deal with, and it's proven to be wildly successful. Food on the Table designed their system around initially a single customer. By working specifically with that one customer, they discovered what they needed to do to refine and create the system that would ultimately develop, and with each new family they added, they refined it even more, including automating a lot of the processes.
When we make MVP's, we need to measure the effectiveness of our efforts. In short, we need actionable metrics. What is the data telling us about our product, and are we accurately measuring something that is relevant? Does our vanity influence this choice of metrics? It certainly can. Case in point, I love seeing the hits on my blog each day. Yes, I pay attention. The problem is, hits alone tells me very little. It may mean people come to see my page, through some means, but does it mean they read the whole post? Does it mean they liked what they read? Does it mean they shared the link with someone else? Hit count won't tell me any of that, but it sure sounds good to say "hey, I received thousands of hits when I posted this". that's a vanity metric. It feels good, but it doesn't really tell me much, and it certainly doesn't guide me to action.
Once you have data that tells you that something isn't working, you need to change. The term for this is "pivot", and pivoting is much harder with large and bulky products. MVP's are easier to pivot with. Additionally, pivoting isn't just doing something different, but it's helping people see a pain point that they don't know about and you are ready to address. In this case, testing can help the organization not just confirm quality, but also see avenues to pivot into as well.
Lean Startups are often associated with Continuous Delivery. The reasoning is that, if we can deploy more frequently, releases themselves become much smaller and more manageable. When an organization gets to pushing multiple times in a day, releases can literally be a single story or a single bug fix. The turnaround time, instead of being counted in days or weeks, could be counted in hours, or even minutes. This approach doesn't minimize testing, it exposes it as even more relevant and necessary.
While MVP's are a starting point, the fact is, the product needs to mature and quality needs to continually improve. By using the Lean approach, that process becomes easier to manage, because the experiments are smaller and the turnaround time to getting a broken build fixed becomes easier with smaller incremental changes. Regardless, some experiments fail, and the line needs to be stopped at times. Be ready for that.
Time to put on my facilitator hat. Thanks, Thomas for a great talk, and now let's see what the audience has to say :).
Thomas recently made the shift from Technical Tester to Product Manager, working with a "Lean Startup" and he states categorically that he is doing as much testing as ever, if not more so. Thomas uses Eric Reis' definition of a startup, which is "a human institution designed to create a product or service within an environment with extreme uncertainty". "Lean" is the idea that we want to focus on the essential value, and remove the waste from the system wherever possible. Put the two concepts together, and you get "Lean Startup". This means that organizations that embrace this are going to look rather different from one another. It also means that what is considered value and what is considered waste will be different in each organization. Testers, this means that context matters a LOT!
Waste can vary. Overproduction is a real issue in a literal product factory, but it's also visible in software for features that are not used or have no value. Code needs to be maintained, tests need to be run, refactoring needs to take these empty features into account, and other features that may be more important are not made because the time is being spent working on stuff that is not relevant. Idle machines are a reality in factories, and backlogs in moving features forward is every bit as bad. I see this when we have a number of stories in DevComplete but with no testers with open cycles to work on them. What happens? They sit there until they can be picked up and addressed. Over time, this lag can be significant; getting a feature from PM proposal to shipped can take days, but some times it can take months or even years. In all, identifying waste takes some time and talent to recognize, and it can be a real struggle to eradicate it once it builds up.
There's waste in programming, there's waste in design, there's waste in testing,and there's waste in release. It just happens. the goal is not to eliminate it, but it is important to look to see where waste occurs and see what can be minimized. Testing is part of of the waste production and waste prevention culture. It's a solid part of what we do as testers, not just to find problems but to also find inefficiencies that we can work on. How do we do that? We can do that with Validated Learning, which means we subject failure to scrutiny, which in turn opens us up to failure. It's possible our investigation may disprove our hypothesis. Our experiment may show that we are wrong in our assumptions, but learning that also helps us expose and remove waste, even if the waste we remove is faulty assumptions of our own.
One of the ways we can help drive the learning is with a "Minimum Viable Product". This is an ideal method for applying what is called the "Build-Measure-Learn" loop. By building the smallest possible product, we can learn if our ideas our sound, if our product meets the need and if the data we receive supports the notion that we are on the right track. testers do this all the time, even with something that's not a MVP. New ideas are spun out from each cycle of this process. If this looks a lot like exploratory testing, indeed, it is :).
Thomas used a number of interesting examples (Zappos, Dropbox, etc.) and how they made their minimum viral product. For Dropbox, it was a video explaining why they had a solution for something most people hadn't figured out was even a problem. Additionally, Dropbox did it in a way that everyone could understand... it's a folder. That's it! For most people, that's all they need to know or deal with, and it's proven to be wildly successful. Food on the Table designed their system around initially a single customer. By working specifically with that one customer, they discovered what they needed to do to refine and create the system that would ultimately develop, and with each new family they added, they refined it even more, including automating a lot of the processes.
When we make MVP's, we need to measure the effectiveness of our efforts. In short, we need actionable metrics. What is the data telling us about our product, and are we accurately measuring something that is relevant? Does our vanity influence this choice of metrics? It certainly can. Case in point, I love seeing the hits on my blog each day. Yes, I pay attention. The problem is, hits alone tells me very little. It may mean people come to see my page, through some means, but does it mean they read the whole post? Does it mean they liked what they read? Does it mean they shared the link with someone else? Hit count won't tell me any of that, but it sure sounds good to say "hey, I received thousands of hits when I posted this". that's a vanity metric. It feels good, but it doesn't really tell me much, and it certainly doesn't guide me to action.
Once you have data that tells you that something isn't working, you need to change. The term for this is "pivot", and pivoting is much harder with large and bulky products. MVP's are easier to pivot with. Additionally, pivoting isn't just doing something different, but it's helping people see a pain point that they don't know about and you are ready to address. In this case, testing can help the organization not just confirm quality, but also see avenues to pivot into as well.
Lean Startups are often associated with Continuous Delivery. The reasoning is that, if we can deploy more frequently, releases themselves become much smaller and more manageable. When an organization gets to pushing multiple times in a day, releases can literally be a single story or a single bug fix. The turnaround time, instead of being counted in days or weeks, could be counted in hours, or even minutes. This approach doesn't minimize testing, it exposes it as even more relevant and necessary.
While MVP's are a starting point, the fact is, the product needs to mature and quality needs to continually improve. By using the Lean approach, that process becomes easier to manage, because the experiments are smaller and the turnaround time to getting a broken build fixed becomes easier with smaller incremental changes. Regardless, some experiments fail, and the line needs to be stopped at times. Be ready for that.
Time to put on my facilitator hat. Thanks, Thomas for a great talk, and now let's see what the audience has to say :).
Let's Move it Forward - Live from #CAST2015
Today the rubber meets the road. Day one of the full CAST 2015 conference is underway. We have had breakfast, we have introduced the program, and we have announced the election running. To that end, I want to remind all AST members that you have until 7:00 p.m. Eastern time TODAY to cast your vote for next year's Board of Directors.
Last year Karen Johnson and I had a discussion at CAST in New York where we commented on the fact that there was an "echo chamber" developing in the software testing world, and that it seemed that the voices we most needed to hear from we were not hearing from. She and I discussed the idea that the industry seems to value "rock stars", to which I laughed that those who use that term haven't known very many rock stars in real life (I have, and truth be told, they are not necessarily the most reliable people on the planet, but they are often fun to be around and listen to ;) ). Karen has been a solid voice in the testing world, and I was excited to see that she was the opening keynote for CAST 2015.
One of the great things about going to conferences for the first time is that the reaction we most often have is "Oh, wow, I'm not alone!" Getting that confirmation that first time can be huge, and it helps make it possible to frame our place in the world of software testing. Karen has been in the software testing world for 30 years, and like many of us, didn't have any intention of being a tester when she started out. She planned to be a journalist (which I think is really cool because I often look at software testing and journalism to be very kindred careers). Karen shared a lot of highlights from her career, and when flashed across the screen, made clear that she's had and continues to have a remarkable career! I recommend checking out the webCAST video of her keynote when it posts.
The theme of CAST 2015 is "Moving Testing Forward", and that indicates that in many ways, testing is seen as not moving forward. Software development has changed radically these past twenty five years (that's my time frame, since I started really thinking about it when I stated working in IT in 1991). Many of the development techniques have changed, but the way that software has been tested, at least in a number of organizations I have been in, has changed very little. It's easy for testers to feel "stuck" at various points, and when we try to make those forward steps, we often receive push back, and at times that pushback comes from our own colleagues. I had a similar experience in 2009, after nearly twenty years of software testing. I felt like I was doing the same things the same ways, and there was very little I felt I had to show for it beyond what I learned the first few years. Yes I had twenty years experience, but it felt like I had two years experience repeated ten times.
Stepping forward takes courage, it takes a willingness to know who you are and what you are good at. It also means you have to be ready to accept that there are things you are not good at, and often, that's the hardest part. However, it's important to realize that the things you are not good at can be improved, and the things you are good at can be boosted even more by focusing a bit on what you don't feel you are good at. Karen and I look to be on the same page here, and while we realize that there are so many things in the world we will never be amazing at, we can always improve our odds by working on the things we are good at. We can't do that exclusively, and yes, some things that are distasteful or uncomfortable come with the territory. Deal with them, but don't obsess on it.
Another valuable point comes in with who we work for. Karen recommends strongly to do all you can to not work for people you do not respect. If you work for someone you do not respect, your entire relationship will be off kilter. You will know it, and they will know it. When you don't respect who you work for, your best work rarely comes out. When you respect who you work for, it's not uncommon to walk through fire for those people. I've had a few of those experiences, most recently with my dearly departed Director of Quality Assurance, Ken Pier. I can truly say I would walk through fire for him, and I strive today to be worthy of the respect he had for me as well.
There will be office politics. Do not believe you can escape it. You can't. It's part of the culture, and to borrow a recent quote from @DocOnDev... "your office does not have a culture, your office IS a culture". Cultures are dynamic, they are lived, and they are managed, for god or ill, and every one of us is part of that reality whether we like it or not. We cannot choose to not deal with people unless we literally work for ourselves only. I don't have that reality, and I'm guessing you don't either ;).
Karen mentioned that there was a value to having a manager/boss that you worked with instead of for. If you can develop a relationship that is closer to that of a peer, you can make amazing strides. true, you do work "for" someone in the literal sense that they sign your reviews and approve your bonuses and pay raises, but outside of that, it is much easier and more enjoyable to work with people rather than under people. As I said before, one of the great experiences of my career was working with Ken Pier, because he emphasized the working with. He was my director, but he hated being a manager. He wanted to be a doer, and when it came to the work of our team, he shouldered as much work as the rest of us, and often more. He wasn't an office manager or a bureaucrat, he was in the trenches with us, every day, and that make working with him both easy and enjoyable.
Along with managers, we have co-workers. Other testers, programmers, project managers, along with a myriad of other people. An important question to ask is "would I want to work with this person again at another company? If I had to change jobs and companies tomorrow, who would I want to bring with me? Who would I want to leave behind?" those people you identify as those you want to take with you, cultivate relationships with them, not in the sleazy "networking" way, but really get to know them and foster a relationship with them. Let them do the same with you.
Many people think that moving testing forward is about technical prowess only, but in truth it also requires people living and experiencing life. It might seem strange to think of work/life balance as a way to move testing forward, but it is important to keep moving and learning and evaluating to keep from becoming stagnant. the fact is, our living and interacting is what lets us actually excel. There's a phrase that I remember hearing about juggling several balls, and that all of the balls are rubber except for one, and that ball is made of glass. What do you do? The point of the story is that the glass ball must never be dropped. The other part of the story is that the glass ball is never the same thing. At a given time, the glass ball may be family. It may be work. It may be health. It may be leisure. The point is, everything will be bounced and dropped at various times, but we need to be alert and aware at what point in time the glass ball's label has changed, and what it has changed to.
Outside of work, there's many opportunities to learn and interact. Conferences are an obvious one, but there are many other ways to get involved in the community at large. Meetups, message boards, weekend testing, organization involvement, even participating in conversations on Twitter all help to foster that sense of community, but for it to matter, we need to engage. I have often said there are many who are consumers, but few who are active producers. It takes some courage to become an active producer, but the great thing is, we all can, and we can all start right where we are and move forward from there.
OK, I'm going to go help handle open season at this point, so I'll be back with you in another post in a bit. Thanks for following along :).
Last year Karen Johnson and I had a discussion at CAST in New York where we commented on the fact that there was an "echo chamber" developing in the software testing world, and that it seemed that the voices we most needed to hear from we were not hearing from. She and I discussed the idea that the industry seems to value "rock stars", to which I laughed that those who use that term haven't known very many rock stars in real life (I have, and truth be told, they are not necessarily the most reliable people on the planet, but they are often fun to be around and listen to ;) ). Karen has been a solid voice in the testing world, and I was excited to see that she was the opening keynote for CAST 2015.
One of the great things about going to conferences for the first time is that the reaction we most often have is "Oh, wow, I'm not alone!" Getting that confirmation that first time can be huge, and it helps make it possible to frame our place in the world of software testing. Karen has been in the software testing world for 30 years, and like many of us, didn't have any intention of being a tester when she started out. She planned to be a journalist (which I think is really cool because I often look at software testing and journalism to be very kindred careers). Karen shared a lot of highlights from her career, and when flashed across the screen, made clear that she's had and continues to have a remarkable career! I recommend checking out the webCAST video of her keynote when it posts.
The theme of CAST 2015 is "Moving Testing Forward", and that indicates that in many ways, testing is seen as not moving forward. Software development has changed radically these past twenty five years (that's my time frame, since I started really thinking about it when I stated working in IT in 1991). Many of the development techniques have changed, but the way that software has been tested, at least in a number of organizations I have been in, has changed very little. It's easy for testers to feel "stuck" at various points, and when we try to make those forward steps, we often receive push back, and at times that pushback comes from our own colleagues. I had a similar experience in 2009, after nearly twenty years of software testing. I felt like I was doing the same things the same ways, and there was very little I felt I had to show for it beyond what I learned the first few years. Yes I had twenty years experience, but it felt like I had two years experience repeated ten times.
Stepping forward takes courage, it takes a willingness to know who you are and what you are good at. It also means you have to be ready to accept that there are things you are not good at, and often, that's the hardest part. However, it's important to realize that the things you are not good at can be improved, and the things you are good at can be boosted even more by focusing a bit on what you don't feel you are good at. Karen and I look to be on the same page here, and while we realize that there are so many things in the world we will never be amazing at, we can always improve our odds by working on the things we are good at. We can't do that exclusively, and yes, some things that are distasteful or uncomfortable come with the territory. Deal with them, but don't obsess on it.
Another valuable point comes in with who we work for. Karen recommends strongly to do all you can to not work for people you do not respect. If you work for someone you do not respect, your entire relationship will be off kilter. You will know it, and they will know it. When you don't respect who you work for, your best work rarely comes out. When you respect who you work for, it's not uncommon to walk through fire for those people. I've had a few of those experiences, most recently with my dearly departed Director of Quality Assurance, Ken Pier. I can truly say I would walk through fire for him, and I strive today to be worthy of the respect he had for me as well.
There will be office politics. Do not believe you can escape it. You can't. It's part of the culture, and to borrow a recent quote from @DocOnDev... "your office does not have a culture, your office IS a culture". Cultures are dynamic, they are lived, and they are managed, for god or ill, and every one of us is part of that reality whether we like it or not. We cannot choose to not deal with people unless we literally work for ourselves only. I don't have that reality, and I'm guessing you don't either ;).
Karen mentioned that there was a value to having a manager/boss that you worked with instead of for. If you can develop a relationship that is closer to that of a peer, you can make amazing strides. true, you do work "for" someone in the literal sense that they sign your reviews and approve your bonuses and pay raises, but outside of that, it is much easier and more enjoyable to work with people rather than under people. As I said before, one of the great experiences of my career was working with Ken Pier, because he emphasized the working with. He was my director, but he hated being a manager. He wanted to be a doer, and when it came to the work of our team, he shouldered as much work as the rest of us, and often more. He wasn't an office manager or a bureaucrat, he was in the trenches with us, every day, and that make working with him both easy and enjoyable.
Along with managers, we have co-workers. Other testers, programmers, project managers, along with a myriad of other people. An important question to ask is "would I want to work with this person again at another company? If I had to change jobs and companies tomorrow, who would I want to bring with me? Who would I want to leave behind?" those people you identify as those you want to take with you, cultivate relationships with them, not in the sleazy "networking" way, but really get to know them and foster a relationship with them. Let them do the same with you.
Many people think that moving testing forward is about technical prowess only, but in truth it also requires people living and experiencing life. It might seem strange to think of work/life balance as a way to move testing forward, but it is important to keep moving and learning and evaluating to keep from becoming stagnant. the fact is, our living and interacting is what lets us actually excel. There's a phrase that I remember hearing about juggling several balls, and that all of the balls are rubber except for one, and that ball is made of glass. What do you do? The point of the story is that the glass ball must never be dropped. The other part of the story is that the glass ball is never the same thing. At a given time, the glass ball may be family. It may be work. It may be health. It may be leisure. The point is, everything will be bounced and dropped at various times, but we need to be alert and aware at what point in time the glass ball's label has changed, and what it has changed to.
Outside of work, there's many opportunities to learn and interact. Conferences are an obvious one, but there are many other ways to get involved in the community at large. Meetups, message boards, weekend testing, organization involvement, even participating in conversations on Twitter all help to foster that sense of community, but for it to matter, we need to engage. I have often said there are many who are consumers, but few who are active producers. It takes some courage to become an active producer, but the great thing is, we all can, and we can all start right where we are and move forward from there.
OK, I'm going to go help handle open season at this point, so I'll be back with you in another post in a bit. Thanks for following along :).
Monday, August 3, 2015
Why CAST? - Reflection from #CAST2015
The first Conference for the Association for Software Testing (CAST) was held in 2006. This year, we are holding the tenth CAST in Grand Rapids, Michigan. Three more years and we can claim to have raised a teenager :).
I discovered AST in 2010. By the time I had joined and learned what CAST was, I was unable to arrange to attend that year. I did, however, commit to attending CAST being held in Seattle in 2011. Part of that was made possible because James Bach specifically invited me to attend, to demonstrate a real world Weekend Testing event as a workshop. Additionally, I took the opportunity to offer a short talk as part of the "Emerging Topics” track, titled “Beyond Being Prepared: What Can Boy Scouts Teach Testers?”.
What I found most interesting about CAST, as compared to other conferences, was what appeared to me to be the complete lack of commercial involvement. I was tired of conferences and webinars where sessions were mostly about “here, buy this tool, and all your problems will be solved”. Instead, I was treated to real world situations, with speakers who are actual day to day, in the trenches software testers. The material was memorable, but more to the point, it was actionable. I could actually use what I learned. Since this first experience, I have participated in each CAST to date (Seattle in 2011, San Jose in 2012, Madison in 2013, New York in 2014 and now Grand Rapids in 2015).
Additionally, I appreciate an emphasis on having new speakers take part in CAST. Last year, I had the pleasure of presenting a talk with a brand new speaker, Harrison Lovell, about “Coyote Teaching”, which was about mentorship. This year, I had the chance to see many new speakers get selected, and I am pleased to say that AST working with Speak Easy helped many new speakers prepare and present at CAST. It’s this willingness and openness to new voices that, I believe, sets CAST apart from other conferences.
As the President of AST, I understand the effort it takes to present a conference, encourage people to attend, recruit speakers to present, and ultimately produce a program that is second to none. Today was our tutorial day, and from the conversations I've had so far, I firmly believe we are well on our way to making that a reality for this tenth CAST. For all of you who took the time to travel and carve out your schedule to be here, either to participate in the audiences or to deliver messages as speakers, workshop presenters, facilitators or volunteers, you have my gratitude. For those who were not able to attend in person, remember, you can still join us by watching webCAST with us.
Here's to the next few days, I think they will be marvelous :)!
I discovered AST in 2010. By the time I had joined and learned what CAST was, I was unable to arrange to attend that year. I did, however, commit to attending CAST being held in Seattle in 2011. Part of that was made possible because James Bach specifically invited me to attend, to demonstrate a real world Weekend Testing event as a workshop. Additionally, I took the opportunity to offer a short talk as part of the "Emerging Topics” track, titled “Beyond Being Prepared: What Can Boy Scouts Teach Testers?”.
What I found most interesting about CAST, as compared to other conferences, was what appeared to me to be the complete lack of commercial involvement. I was tired of conferences and webinars where sessions were mostly about “here, buy this tool, and all your problems will be solved”. Instead, I was treated to real world situations, with speakers who are actual day to day, in the trenches software testers. The material was memorable, but more to the point, it was actionable. I could actually use what I learned. Since this first experience, I have participated in each CAST to date (Seattle in 2011, San Jose in 2012, Madison in 2013, New York in 2014 and now Grand Rapids in 2015).
Additionally, I appreciate an emphasis on having new speakers take part in CAST. Last year, I had the pleasure of presenting a talk with a brand new speaker, Harrison Lovell, about “Coyote Teaching”, which was about mentorship. This year, I had the chance to see many new speakers get selected, and I am pleased to say that AST working with Speak Easy helped many new speakers prepare and present at CAST. It’s this willingness and openness to new voices that, I believe, sets CAST apart from other conferences.
As the President of AST, I understand the effort it takes to present a conference, encourage people to attend, recruit speakers to present, and ultimately produce a program that is second to none. Today was our tutorial day, and from the conversations I've had so far, I firmly believe we are well on our way to making that a reality for this tenth CAST. For all of you who took the time to travel and carve out your schedule to be here, either to participate in the audiences or to deliver messages as speakers, workshop presenters, facilitators or volunteers, you have my gratitude. For those who were not able to attend in person, remember, you can still join us by watching webCAST with us.
Here's to the next few days, I think they will be marvelous :)!
Subscribe to:
Posts (Atom)