Tester Odyssey
- Transfer
The IT industry is undergoing rapid changes. More and more development teams put testing, if not at the forefront, then at least at the center of the process technology, and testing is becoming an influential development factor. Literally every month there are new improved frameworks and drivers for automated testing. Teams practicing automated regression testing need testers with sophisticated research skills. But most people do not get such skills while studying at universities - where then will such testers come from?
At the same time, it turns out that many experts dream of good work related to testing. Testers often ask me how to “get involved” in a team working according to the Agile method, or how they can find just a good job. If they do not have programming experience, they worry that they are not technically savvy enough to get into the Agile team. From my point of view, skills are certainly important, but attitude is the most important thing. If you are ready to learn, do everything in order to get a really good product from the team, then you have good prospects as a tester. My advice to you is to voluntarily join any activity that will bring new knowledge and skills, and work on your conscience to hone your acquired skills.
I think it’s much clearer for everyone when specific examples are given, so I’ll give a couple of stories from my own experience, from which it will be seen how my desire for knowledge turned into career growth. I think this can serve as a basis for ideas regarding your own professional growth.
Testers are people with experience in very different industries. Over the past ten years, when programmers became interested in testing, I met many who wrote code before and now consider themselves to be a tester. I also know many testers who came from business management, so their experience in doing business makes them very valuable in development. Technical writers who test the application to document it often become excellent testers. Many of us came to testing by chance, as this, for example, happened to me!
I started with programming, and I really like writing code. Test automation, a lesson closely associated with programming is one of my favorite activities. And yet, testing is my passion. I really like to study how the business is developing, how everything works in it, then to contribute to its success. Technical savvy allows me to interact perfectly with the team both at the development level and at the level of the business process. Below is my personal odyssey, from my early programming experience to working on Agile teams.
Like many, I came to software development by accident. I got a job as a “programming trainer” at the Department of Data Processing at the University of Texas.
I was taught by programmers who themselves had just recently learned. Since they remembered how they themselves learned programming, they knew how to teach others. Soon I already knew the basics of Easytrieve, Cobol and 4GL, as well as hierarchical databases. We all wrote the code exactly the same, so it was easy to help each other. In retrospect, it was collective programming in perfect form.
After a couple of months of this field trip, I was offered the position of training coordinator, and I gladly accepted the offer. I had to not only follow the training of programmers, but also train end users. We had classes for the teaching staff and other university staff, where we taught how to write simple queries and reports — a very successful practice that saved us programmers a lot of work. In the year that I was assigned to study (and during which I also performed the duties of a programmer), I learned a lot in finding the right approach to teaching other people.
I was very surprised how much I learned from users, as well as other programmers. We, “programmers / analysts,” sat down at the table with end users, talked about what they would like, and immediately created prototypes. We showed them each of the options so that in the end they got what they wanted. I joined the team that worked on the online catalog for the library: librarians explained to us how the file cabinet works. To learn something new from completely different industries was the most interesting in this work. We did not know anything about testing, but we planned, in collaboration with users, to bring the software in proper form before it was released.
At this work, an analytic programmer, I learned to lead. My own leader told me that being a leader means making other people understand how much my team has influenced the success of the project. I learned to be an example to others. I remembered this knowledge at all subsequent places of work, and improved it, exploring new ways to convey to the managers and other managers the value of the work done by me and my team.
A couple of years later I worked in technical support of a major software manufacturer, where at that time, it seemed, they did not know about testing and quality control. My employees tested a lot on their own initiative, because it is better to find problems before the user finds them. One day, our manager asked if anyone would like to receive training on working with DB2. No one knew what it was, but I volunteered. Soon, I became a top DB2 and SQL expert on the team.
Seeing the benefits of finding bugs in the software before reaching the client, the company organized the first team of testers. And I also volunteered to work there. Since I knew SQL, I had to work on projects that used Oracle and Sybase databases, which began to be in much greater demand than our product.
In this new work, I began to master the art and science of testing. I participated in a testing conference to learn more. We started experimenting with automation. Our software worked in all operating systems. So I took the opportunity to learn all of them: VAX / VMS, Wang, OS2, AS400, and eight other different Unix subtypes. Not all of this graced my resume, but the ability to use all of these platforms as a testing environment was invaluable.
Our team was also responsible for preparing the releases. I learned about the importance of proper documentation and accuracy of documentation, how to organize alpha and beta testing, and even how to conduct product release. Most of these duties were initially frightening and incomprehensible. Automated tests still scare me sometimes, still! But I was lucky to get the necessary training in external courses, and with the help of self-help books, and thanks to the help of colleagues. I did not stop due to failures and tried to acquire new skills.
My skills were very much in demand on the market because of their breadth - testing, automation, and operating systems. And this was not my goal - I just liked to learn something new! Be it something technical, or, conversely, something from the business sphere - I liked the adventures in the new territory. Of course, in this case, all this paid off. When the company was in financial difficulties, it was easy for me to find a good place to pursue a career.
I liked my new job, and it gave me the opportunity to explore new areas. For example, in my team, I became the main PowerBuilder specialist. I could spend several months studying the testing tool by creating an automated test suite with a GUI. The most beautiful thing was that some of my former employees also moved to this company. Then I realized how small the world is - this is a very valuable lesson!
After a couple of years, at a time of wild growth in popularity of the Internet, I switched to work in a web startup. I knew absolutely nothing about testing web applications, but since I had experience with a variety of automated testing tools, I surfed the Internet looking for something that could be used to test web applications.
When I looked through the list of tools, my attention was drawn to the abbreviation OCLC. I studied it when I was working on an online library catalog, since OCLC catalogs books and maintains libraries almost everywhere. By a strange coincidence, they offered a WebArt testing tool, which I decided to purchase. Its developer, Type House, came to train us in web application testing and automated testing.
Like many testers, I was always interested in the ability to release good software on time. The Internet is a much more dynamic environment than the world of database products, and I was unpleasantly surprised by our slow work on the model of a waterfall. Soon the opportunity was given to try a different approach. When a larger company bought our startup, several of our developers left to create their own project. They gave me the book Extreme Programming Explained and said, “Hey, we want to test this XP thing.” As soon as I read the book, I realized that I had to try, and begged them to take me to the project.
When I joined my buddies, the question “what to do for a tester in an XP project?” Began to torment me, and I entered a growing online community dedicated to agile development (then we did not know that the term Agile would stick to this approach). I was amazed at the warm welcome of the XP gurus and other proponents of agility. When Uncle Bob Martin came to give us a training course, he invited me to call Word Cunningham and ask him all his questions about testing; he gave me his phone number. The Word spoke to me for more than an hour! If I found out that someone like Ron Jeffries or Kent Back was coming to our city or to some conference, I made an appointment with them, and they did not spare time for me. Brian Marik told me who to contact to get more help with agile testing.
When my team and those I met at conferences, in user groups and thanks to the newsletter, found the best agile testing tools, I decided that there was nothing for other testers and their teams to reinvent the wheel. With the support of the XP community and Type House, I wrote the book Testing and Extreme Programming. Many people helped with proofreading drafts and with ideas, among them was Janet Gregory. Together with Janet, we began to organize lectures and workshops at conferences.
Extreme programming is based on the human factor, as well as career growth. Thanks to good relations with colleagues and the community as a whole, I was able to become a lecturer, trainer and author, whose books were published. Not only did I become a good tester, I learned to communicate. I began to go to conferences, learn from others, offer my ideas in lectures and while working in sections. It’s all because I love to study and have spent a lot of time and effort on establishing relationships with smart and vividly thinking people.
I also realized the value of sharing. My first team of XP developers united people around me and created a group of followers of XP. I spoke at the very first meeting! I met so many people who are in vain and learned so much in ten years in this group, and all I spent is just a little of my time. I try very hard to repay all that help in advance. What i got. I participate in local user groups, work as a volunteer at conferences, moderate testing mailings, organize informal training sessions with other companies, conduct free online seminars and teleconferences with teams that have questions about testing and agile development. And it turns out that the more I try to help people, the more I learn. This is very cool - help already contains a reward.
I have been working as a tester for many years, but this profession does not become obsolete. I really learn something new every day: I master technical skills, gain knowledge about that. How a business works. Joint work in a team and with colleagues whom I recognized through participation in groups. Conferences and even Twitter allows you to experiment with new open source software for testers and learn new programming languages. At first it’s scary, but it always gives a result.
For example, I had a hard time mastering Ruby because I never knew a lot about object-oriented programming languages. I studied the literature, my colleagues helped me, and the output was a script that later saved time for more interesting tasks. I have joined groups that work to improve the offer of testing tools, such as the Austin Workshop on Test Automation and the Agile Alliance Functional Test Tools committee. And thanks to this, I not only learn about alternative tools, but also meet many useful people.
I think that for most testers who read this article, it’s obvious how much I love what I’m doing (although there are days when I don’t know what to do and I regret that I have so little knowledge). Friends from that very first job in tech support point out the ease with which I can find a good job, while they are stuck in the field. Which has long been uninteresting to them. I’m not smarter than them, I’m just ready to learn and consider new opportunities! A small investment of one’s time in studying and participating in community affairs is paid off handsomely when it comes to careers.
Here are a few sources that I would recommend to testers:
Lisa Crispin, in collaboration with Janet Gregory, wrote the book Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), was one of the authors of Beautiful Testing (O'Reilly, 2009). She worked as a tester in agile teams for ten years and is pleased to share her experience through books, articles, lectures, and participation in communities around the world. More information about her can be found at www.lisacrispin.com
At the same time, it turns out that many experts dream of good work related to testing. Testers often ask me how to “get involved” in a team working according to the Agile method, or how they can find just a good job. If they do not have programming experience, they worry that they are not technically savvy enough to get into the Agile team. From my point of view, skills are certainly important, but attitude is the most important thing. If you are ready to learn, do everything in order to get a really good product from the team, then you have good prospects as a tester. My advice to you is to voluntarily join any activity that will bring new knowledge and skills, and work on your conscience to hone your acquired skills.
I think it’s much clearer for everyone when specific examples are given, so I’ll give a couple of stories from my own experience, from which it will be seen how my desire for knowledge turned into career growth. I think this can serve as a basis for ideas regarding your own professional growth.
Programmer, tester, or subject matter specialist?
Testers are people with experience in very different industries. Over the past ten years, when programmers became interested in testing, I met many who wrote code before and now consider themselves to be a tester. I also know many testers who came from business management, so their experience in doing business makes them very valuable in development. Technical writers who test the application to document it often become excellent testers. Many of us came to testing by chance, as this, for example, happened to me!
I started with programming, and I really like writing code. Test automation, a lesson closely associated with programming is one of my favorite activities. And yet, testing is my passion. I really like to study how the business is developing, how everything works in it, then to contribute to its success. Technical savvy allows me to interact perfectly with the team both at the development level and at the level of the business process. Below is my personal odyssey, from my early programming experience to working on Agile teams.
First testing lessons
Like many, I came to software development by accident. I got a job as a “programming trainer” at the Department of Data Processing at the University of Texas.
I was taught by programmers who themselves had just recently learned. Since they remembered how they themselves learned programming, they knew how to teach others. Soon I already knew the basics of Easytrieve, Cobol and 4GL, as well as hierarchical databases. We all wrote the code exactly the same, so it was easy to help each other. In retrospect, it was collective programming in perfect form.
After a couple of months of this field trip, I was offered the position of training coordinator, and I gladly accepted the offer. I had to not only follow the training of programmers, but also train end users. We had classes for the teaching staff and other university staff, where we taught how to write simple queries and reports — a very successful practice that saved us programmers a lot of work. In the year that I was assigned to study (and during which I also performed the duties of a programmer), I learned a lot in finding the right approach to teaching other people.
I was very surprised how much I learned from users, as well as other programmers. We, “programmers / analysts,” sat down at the table with end users, talked about what they would like, and immediately created prototypes. We showed them each of the options so that in the end they got what they wanted. I joined the team that worked on the online catalog for the library: librarians explained to us how the file cabinet works. To learn something new from completely different industries was the most interesting in this work. We did not know anything about testing, but we planned, in collaboration with users, to bring the software in proper form before it was released.
At this work, an analytic programmer, I learned to lead. My own leader told me that being a leader means making other people understand how much my team has influenced the success of the project. I learned to be an example to others. I remembered this knowledge at all subsequent places of work, and improved it, exploring new ways to convey to the managers and other managers the value of the work done by me and my team.
Learning with Change
A couple of years later I worked in technical support of a major software manufacturer, where at that time, it seemed, they did not know about testing and quality control. My employees tested a lot on their own initiative, because it is better to find problems before the user finds them. One day, our manager asked if anyone would like to receive training on working with DB2. No one knew what it was, but I volunteered. Soon, I became a top DB2 and SQL expert on the team.
Seeing the benefits of finding bugs in the software before reaching the client, the company organized the first team of testers. And I also volunteered to work there. Since I knew SQL, I had to work on projects that used Oracle and Sybase databases, which began to be in much greater demand than our product.
In this new work, I began to master the art and science of testing. I participated in a testing conference to learn more. We started experimenting with automation. Our software worked in all operating systems. So I took the opportunity to learn all of them: VAX / VMS, Wang, OS2, AS400, and eight other different Unix subtypes. Not all of this graced my resume, but the ability to use all of these platforms as a testing environment was invaluable.
Our team was also responsible for preparing the releases. I learned about the importance of proper documentation and accuracy of documentation, how to organize alpha and beta testing, and even how to conduct product release. Most of these duties were initially frightening and incomprehensible. Automated tests still scare me sometimes, still! But I was lucky to get the necessary training in external courses, and with the help of self-help books, and thanks to the help of colleagues. I did not stop due to failures and tried to acquire new skills.
My skills were very much in demand on the market because of their breadth - testing, automation, and operating systems. And this was not my goal - I just liked to learn something new! Be it something technical, or, conversely, something from the business sphere - I liked the adventures in the new territory. Of course, in this case, all this paid off. When the company was in financial difficulties, it was easy for me to find a good place to pursue a career.
Connections are always opportunities
I liked my new job, and it gave me the opportunity to explore new areas. For example, in my team, I became the main PowerBuilder specialist. I could spend several months studying the testing tool by creating an automated test suite with a GUI. The most beautiful thing was that some of my former employees also moved to this company. Then I realized how small the world is - this is a very valuable lesson!
After a couple of years, at a time of wild growth in popularity of the Internet, I switched to work in a web startup. I knew absolutely nothing about testing web applications, but since I had experience with a variety of automated testing tools, I surfed the Internet looking for something that could be used to test web applications.
When I looked through the list of tools, my attention was drawn to the abbreviation OCLC. I studied it when I was working on an online library catalog, since OCLC catalogs books and maintains libraries almost everywhere. By a strange coincidence, they offered a WebArt testing tool, which I decided to purchase. Its developer, Type House, came to train us in web application testing and automated testing.
Like many testers, I was always interested in the ability to release good software on time. The Internet is a much more dynamic environment than the world of database products, and I was unpleasantly surprised by our slow work on the model of a waterfall. Soon the opportunity was given to try a different approach. When a larger company bought our startup, several of our developers left to create their own project. They gave me the book Extreme Programming Explained and said, “Hey, we want to test this XP thing.” As soon as I read the book, I realized that I had to try, and begged them to take me to the project.
When I joined my buddies, the question “what to do for a tester in an XP project?” Began to torment me, and I entered a growing online community dedicated to agile development (then we did not know that the term Agile would stick to this approach). I was amazed at the warm welcome of the XP gurus and other proponents of agility. When Uncle Bob Martin came to give us a training course, he invited me to call Word Cunningham and ask him all his questions about testing; he gave me his phone number. The Word spoke to me for more than an hour! If I found out that someone like Ron Jeffries or Kent Back was coming to our city or to some conference, I made an appointment with them, and they did not spare time for me. Brian Marik told me who to contact to get more help with agile testing.
Helping the community creates new opportunities
When my team and those I met at conferences, in user groups and thanks to the newsletter, found the best agile testing tools, I decided that there was nothing for other testers and their teams to reinvent the wheel. With the support of the XP community and Type House, I wrote the book Testing and Extreme Programming. Many people helped with proofreading drafts and with ideas, among them was Janet Gregory. Together with Janet, we began to organize lectures and workshops at conferences.
Extreme programming is based on the human factor, as well as career growth. Thanks to good relations with colleagues and the community as a whole, I was able to become a lecturer, trainer and author, whose books were published. Not only did I become a good tester, I learned to communicate. I began to go to conferences, learn from others, offer my ideas in lectures and while working in sections. It’s all because I love to study and have spent a lot of time and effort on establishing relationships with smart and vividly thinking people.
I also realized the value of sharing. My first team of XP developers united people around me and created a group of followers of XP. I spoke at the very first meeting! I met so many people who are in vain and learned so much in ten years in this group, and all I spent is just a little of my time. I try very hard to repay all that help in advance. What i got. I participate in local user groups, work as a volunteer at conferences, moderate testing mailings, organize informal training sessions with other companies, conduct free online seminars and teleconferences with teams that have questions about testing and agile development. And it turns out that the more I try to help people, the more I learn. This is very cool - help already contains a reward.
Horizon expansion never stops
I have been working as a tester for many years, but this profession does not become obsolete. I really learn something new every day: I master technical skills, gain knowledge about that. How a business works. Joint work in a team and with colleagues whom I recognized through participation in groups. Conferences and even Twitter allows you to experiment with new open source software for testers and learn new programming languages. At first it’s scary, but it always gives a result.
For example, I had a hard time mastering Ruby because I never knew a lot about object-oriented programming languages. I studied the literature, my colleagues helped me, and the output was a script that later saved time for more interesting tasks. I have joined groups that work to improve the offer of testing tools, such as the Austin Workshop on Test Automation and the Agile Alliance Functional Test Tools committee. And thanks to this, I not only learn about alternative tools, but also meet many useful people.
Why is it important?
I think that for most testers who read this article, it’s obvious how much I love what I’m doing (although there are days when I don’t know what to do and I regret that I have so little knowledge). Friends from that very first job in tech support point out the ease with which I can find a good job, while they are stuck in the field. Which has long been uninteresting to them. I’m not smarter than them, I’m just ready to learn and consider new opportunities! A small investment of one’s time in studying and participating in community affairs is paid off handsomely when it comes to careers.
Here are a few sources that I would recommend to testers:
- Collaboration Explained: Facilitation Skills for Software Project Leaders, Jean Tabaka, Addison-Wesley 2006. These skills will serve you even if you aren't a "project leader".
- Everyday Scripting with Ruby: For Teams, Testers and You, Brian Marick, Pragmatic Bookshelf, 2007
- "Writing Maintainable Automated Tests," Dale Emery, 2009.
- Continuous Integration and Testing Conference
- “Google's '20 percent time 'in action,” Alex K.
- Exploratory testing articles and blog posts , Jonathan Kohl.
- Agile user groups
- Software Testing Club
- Weekend testers
- Articles about agile testing
about the author
Lisa Crispin, in collaboration with Janet Gregory, wrote the book Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), was one of the authors of Beautiful Testing (O'Reilly, 2009). She worked as a tester in agile teams for ten years and is pleased to share her experience through books, articles, lectures, and participation in communities around the world. More information about her can be found at www.lisacrispin.com