Odyssey Tester
The IT industry is undergoing rapid changes. More and more development teams are putting testing, if not at the forefront, then at least at the center of the process, 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 refined research skills. But most people do not get these skills while studying in 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 “stick” in a team working on the Agile-method, or how to find them just a good job. If they have no programming experience, they are worried 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, to do everything to ensure that the team has a really good product, then you have good prospects as a tester. My advice to you is to voluntarily connect to any activity that brings new knowledge and skills, and work hard to improve your skills.
I think it is much clearer to everyone when concrete examples are given, so I will 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 may be the basis for ideas about your own professional growth.
')
Testers are people with experience in very different industries. Over the past ten years, when programmers have become interested in testing, I have met many of those who previously wrote code, and now consider themselves to be a tester. I also know a lot of testers who come 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 randomly, as, for example, happened to me!
I started with programming, and I really like writing code. Testing automation, a class closely related to programming is one of my favorite classes. And yet, testing is my passion. I really like to learn how a business develops, how everything works in it, then to contribute to its success. Technical knowledge allows me to interact perfectly with the team at the development level as well as at the business process level. Below is my personal odyssey, from early programming experience to working in Agile teams.
Like many, I came to software development by accident. I got a “Programming Coach” position at the Department of Data Processing at the University of Texas.
I was taught by programmers who themselves only recently learned. Because they remembered learning how to program themselves, they knew how to train 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 a collective programming in a perfect form.
After a couple of months of this internship, 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 faculty and other university staff, where we were taught to compile simple requests and reports — a very successful practice that saved us, programmers, from a lot of work. During the year that I was taken to study (and during which I also served as a programmer), I learned a great deal in the search for the right approach to teaching other people.
I was very surprised how much I learned from users, as well as other programmers. We, the “programmers / analysts,” sat at the table with the 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: the librarians explained to us how the filing cabinet works. Learning something new from completely different branches was the most interesting in this work. We did not know anything about testing, but planned in collaboration with users to bring the software into proper form before its publication.
I learned how to lead a programmer-analyst at this job. My own manager told me that being a leader means making others understand how my team influenced the success of the project. I learned to be an example to others. I remembered this knowledge in all subsequent workplaces, and improved it, exploring new ways to convey to 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 for a major software manufacturer, where at that time I didn’t seem to know about testing and quality control. My staff tested a lot on their own initiative, because it's better to find problems before the user finds them. One day, our manager asked if anyone wanted to go through a DB2 training session. No one knew what it was, but I volunteered. Soon, I became the main DB2 and SQL expert in the team.
After seeing the benefits of finding bugs in the software before getting to 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 were beginning 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 study them all: VAX / VMS, Wang, OS2, AS400 and eight more different Unix subspecies. Not all of this adorned my resume, but the ability to use all these platforms as a testing environment was invaluable.
Our team was also responsible for the preparation of releases. I learned about the importance of proper design and accuracy of documentation, how to organize alpha and beta testing, and even how to carry out a product release. Most of these responsibilities were at first frightening and incomprehensible. Automated tests still sometimes scare me, until now! But I was lucky to get the necessary training on external courses, with the help of tutorials, and thanks to the help of colleagues. I did not stop because of failures and tried to acquire new skills.
My skills were very popular in the market because of their breadth - testing, automation, and operating systems. And this was not my goal - I just liked to learn something new! Whether it is something technical, or, on the contrary, something from the sphere of business - I liked the adventures on a new territory for myself. Of course, in this case, all this has borne fruit. When the company was experiencing financial difficulties, it was easy for me to find a good place to continue my career.
I liked my new job, and it gave me opportunities to explore new areas. For example, in my team, I became the chief expert on PowerBuilder. I could spend several months studying the testing tool by creating an automated test complex with a GUI. The most beautiful thing was that some of my former employees also joined this company. Then I realized how small the world is - this is a very valuable lesson!
After a couple of years, at the time of the tremendous growth of the popularity of the Internet, I moved 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 wandered around the internet looking for something, with this one could test web applications.
When I looked through the list of tools, OCLC abbreviation caught my attention. I studied it when I was working on an online library catalog, because 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 teach us about 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 waterfall model. Soon there was an opportunity to try a different approach. When our startup company bought a larger company, several of our developers left to create their own project. They gave me the book “Extreme Programming with Explanations” (“Extreme Programming Explained”) and they said, “Hey, we want to try 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 friends, I was tormented by the question “what should the tester do in the XP project?”, And I entered the growing online community dedicated to agile development (then we didn’t know that the term Agile was assigned to approach). I was amazed at the warm welcome of the XP gurus and other supporters of the flexible approach. When Uncle Bob Martin came to read us a training course, he suggested that I call Ward Cunningham and ask him all my questions about testing; he gave me his phone number. The Vord spoke to me for more than an hour! If I found out that someone like Ron Jeffries or Kent Beck was coming to our city or to some conference, I made an appointment with them, and they didn’t spare my time. Brian Marik told me who to call to get more help with agile testing.
When my team and those I met at conferences, in user groups and thanks to the mailing list, found the agile testing tools that work best, 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 relationships with colleagues and the community as a whole, I was able to become a lecturer, trainer and author whose books were published. I not only became a good tester, I learned how to communicate. I began to attend conferences, learn from others, and offer my ideas at lectures and while working in sections. All because I love to learn and spent a lot of time and effort to build relationships with smart and lively-minded people.
I also realized the value of sharing. My first team of XP-developers united people around themselves and created a group of XP followers. I spoke at the very first meeting! I met so many withering people and learned so much in ten years in this group, and all I spent was just a little of my time. I really try to pay back in advance for all that help. What I got. I participate in local user groups, work as a volunteer at conferences, moderate testing newsletters, organize informal training sessions with other companies, conduct free online seminars and newsgroups 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 outdated. I really learn something new every day: I learn technical skills, I get knowledge about that. How the business works. Joint work in a team and with colleagues whom I learned from participating in groups. Conferences and even Twitter allows you to experiment with new open source software for testers and learn new programming languages. At first, scary, but the result is always gives.
For example, I hardly mastered Ruby, because I had never mastered object-oriented programming languages ​​well. I studied the literature, my colleagues helped me, and the output was a script that then saved time for more interesting tasks. I joined groups that are working on improving the proposal 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 the majority of testers who read this article, obviously, as much as I love what I do (although there are days when I do not know what to undertake and regret that I have so little knowledge). Friends from the 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. I'm not smarter than them at all, I'm just ready to learn and consider new opportunities! A small investment of your time in school and participation in community affairs is repaid a lot when it comes to career.
Here are a few sources that I would recommend to testers:
Lisa Crispin, in collaboration with Janet Gregory, wrote the Agile Testing book: 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 over ten years and is happy to share her experience through books, articles, lectures, and participation in communities around the world. You can find more information about it 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 “stick” in a team working on the Agile-method, or how to find them just a good job. If they have no programming experience, they are worried 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, to do everything to ensure that the team has a really good product, then you have good prospects as a tester. My advice to you is to voluntarily connect to any activity that brings new knowledge and skills, and work hard to improve your skills.
I think it is much clearer to everyone when concrete examples are given, so I will 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 may be the basis for ideas about your own professional growth.
')
Programmer, tester - or a domain specialist?
Testers are people with experience in very different industries. Over the past ten years, when programmers have become interested in testing, I have met many of those who previously wrote code, and now consider themselves to be a tester. I also know a lot of testers who come 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 randomly, as, for example, happened to me!
I started with programming, and I really like writing code. Testing automation, a class closely related to programming is one of my favorite classes. And yet, testing is my passion. I really like to learn how a business develops, how everything works in it, then to contribute to its success. Technical knowledge allows me to interact perfectly with the team at the development level as well as at the business process level. Below is my personal odyssey, from early programming experience to working in Agile teams.
First testing lessons
Like many, I came to software development by accident. I got a “Programming Coach” position at the Department of Data Processing at the University of Texas.
I was taught by programmers who themselves only recently learned. Because they remembered learning how to program themselves, they knew how to train 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 a collective programming in a perfect form.
After a couple of months of this internship, 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 faculty and other university staff, where we were taught to compile simple requests and reports — a very successful practice that saved us, programmers, from a lot of work. During the year that I was taken to study (and during which I also served as a programmer), I learned a great deal in the search for the right approach to teaching other people.
I was very surprised how much I learned from users, as well as other programmers. We, the “programmers / analysts,” sat at the table with the 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: the librarians explained to us how the filing cabinet works. Learning something new from completely different branches was the most interesting in this work. We did not know anything about testing, but planned in collaboration with users to bring the software into proper form before its publication.
I learned how to lead a programmer-analyst at this job. My own manager told me that being a leader means making others understand how my team influenced the success of the project. I learned to be an example to others. I remembered this knowledge in all subsequent workplaces, and improved it, exploring new ways to convey to managers and other managers the value of the work done by me and my team.
Learning through change
A couple of years later I worked in technical support for a major software manufacturer, where at that time I didn’t seem to know about testing and quality control. My staff tested a lot on their own initiative, because it's better to find problems before the user finds them. One day, our manager asked if anyone wanted to go through a DB2 training session. No one knew what it was, but I volunteered. Soon, I became the main DB2 and SQL expert in the team.
After seeing the benefits of finding bugs in the software before getting to 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 were beginning 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 study them all: VAX / VMS, Wang, OS2, AS400 and eight more different Unix subspecies. Not all of this adorned my resume, but the ability to use all these platforms as a testing environment was invaluable.
Our team was also responsible for the preparation of releases. I learned about the importance of proper design and accuracy of documentation, how to organize alpha and beta testing, and even how to carry out a product release. Most of these responsibilities were at first frightening and incomprehensible. Automated tests still sometimes scare me, until now! But I was lucky to get the necessary training on external courses, with the help of tutorials, and thanks to the help of colleagues. I did not stop because of failures and tried to acquire new skills.
My skills were very popular in the market because of their breadth - testing, automation, and operating systems. And this was not my goal - I just liked to learn something new! Whether it is something technical, or, on the contrary, something from the sphere of business - I liked the adventures on a new territory for myself. Of course, in this case, all this has borne fruit. When the company was experiencing financial difficulties, it was easy for me to find a good place to continue my career.
Connections are always opportunities.
I liked my new job, and it gave me opportunities to explore new areas. For example, in my team, I became the chief expert on PowerBuilder. I could spend several months studying the testing tool by creating an automated test complex with a GUI. The most beautiful thing was that some of my former employees also joined this company. Then I realized how small the world is - this is a very valuable lesson!
After a couple of years, at the time of the tremendous growth of the popularity of the Internet, I moved 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 wandered around the internet looking for something, with this one could test web applications.
When I looked through the list of tools, OCLC abbreviation caught my attention. I studied it when I was working on an online library catalog, because 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 teach us about 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 waterfall model. Soon there was an opportunity to try a different approach. When our startup company bought a larger company, several of our developers left to create their own project. They gave me the book “Extreme Programming with Explanations” (“Extreme Programming Explained”) and they said, “Hey, we want to try 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 friends, I was tormented by the question “what should the tester do in the XP project?”, And I entered the growing online community dedicated to agile development (then we didn’t know that the term Agile was assigned to approach). I was amazed at the warm welcome of the XP gurus and other supporters of the flexible approach. When Uncle Bob Martin came to read us a training course, he suggested that I call Ward Cunningham and ask him all my questions about testing; he gave me his phone number. The Vord spoke to me for more than an hour! If I found out that someone like Ron Jeffries or Kent Beck was coming to our city or to some conference, I made an appointment with them, and they didn’t spare my time. Brian Marik told me who to call 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 mailing list, found the agile testing tools that work best, 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 relationships with colleagues and the community as a whole, I was able to become a lecturer, trainer and author whose books were published. I not only became a good tester, I learned how to communicate. I began to attend conferences, learn from others, and offer my ideas at lectures and while working in sections. All because I love to learn and spent a lot of time and effort to build relationships with smart and lively-minded people.
I also realized the value of sharing. My first team of XP-developers united people around themselves and created a group of XP followers. I spoke at the very first meeting! I met so many withering people and learned so much in ten years in this group, and all I spent was just a little of my time. I really try to pay back in advance for all that help. What I got. I participate in local user groups, work as a volunteer at conferences, moderate testing newsletters, organize informal training sessions with other companies, conduct free online seminars and newsgroups 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.
Expansion of horizons never stops
I have been working as a tester for many years, but this profession does not become outdated. I really learn something new every day: I learn technical skills, I get knowledge about that. How the business works. Joint work in a team and with colleagues whom I learned from participating in groups. Conferences and even Twitter allows you to experiment with new open source software for testers and learn new programming languages. At first, scary, but the result is always gives.
For example, I hardly mastered Ruby, because I had never mastered object-oriented programming languages ​​well. I studied the literature, my colleagues helped me, and the output was a script that then saved time for more interesting tasks. I joined groups that are working on improving the proposal 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 the majority of testers who read this article, obviously, as much as I love what I do (although there are days when I do not know what to undertake and regret that I have so little knowledge). Friends from the 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. I'm not smarter than them at all, I'm just ready to learn and consider new opportunities! A small investment of your time in school and participation in community affairs is repaid a lot when it comes to career.
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 help 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 Agile Testing book: 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 over ten years and is happy to share her experience through books, articles, lectures, and participation in communities around the world. You can find more information about it at www.lisacrispin.com
Source: https://habr.com/ru/post/99872/
All Articles