A year ago, Daan and I were sitting in our most favorite pub in ‘s-Hertogenbosch. As usual and besides many other things, we were talking about some challenges we faced at work, for example: how to improve on our review process, how to get team members engaged and get them in learning mode again. Stuff that most managers will recognize and that we can fill many a conversation with. I am not sure if it was because of the beers or that one of us simply had a bright idea. But, at one moment we started to compare XP to Management. In the past, the both of us had already made the link between pair management and pair programming. We like to keep each other sharp and improve on each other’s ideas, as developers do when pairing. We came to the conclusion that many of the other XP Practices were also highly applicable to management. Since then, we have been consciously using various principles taken from XP and have applied them in our-day-to-day management job.
As a manager, you sometimes tend to forget to look at the world that is closest to you. Sure you read management books, blogs, view LinkedIn updates or you get lost on TED. But we realized that we can learn and adopt a lot from other groups, like for example the developers, testers and agile practitioners that are near to us. When we discussed further about XP Practices and management, we realized we could easily use those practices to help us try find creative, new solutions for management problems based on good patterns already out there. Since then, incorporating XP practices in our management mindset has grown our toolbox with some nifty power tools. OK, open door warning: we are very much aware that there are many worlds out there that you can learn skills and best practices from: how to run a music band, how to be a good sports coach, how to run a logistics company, how to run a military operation, how to train yourself for a marathon, the examples are numerous. It is just that the world of development is so comfortably close to us and it is easy for us to understand it and learn from it.
So in this long-read blog, we will share our ideas about how XP practices can also be applied to management. But, let’s first take one step back and quickly revisit what those XP Practices actually were again:
So, looking back at last year, we actively used some of these XP Practices to help us find solutions for a number of problems we encountered. Let’s walk through these problems and take a look at how XP helped us.
In most organizations, you are still reviewed by one manager and if you are lucky that person asks feedback from colleagues around you. In the end the review is, as it is stated by most HR policies, a meeting where the manager gives their opinion about how the employee performed last year. This manager, however, is also very busy during the year. He or she maybe needs to manage some projects, help implement a new HR system, manage budgets, talk to stakeholders, etc. In most cases it is very hard for the manager to know what a team member is doing on a daily basis. The manager will then try to compensate by asking 360 feedback, but after a couple of years this feedback mechanism no longer provides new insights. In our organization it was fortunately, not that extreme but we had some of the challenges we just described.
Looking at the XP Practices, we concluded that reviews should be related to the practices Whole Team, Collective Ownership and Small Releases. A review should be done by the whole team or at least everyone who can give input should be able to do so. Furthermore, multiple managers should be able to give input to the performance of employees at least when they interacted with that person. So next to our existing review mechanism, we implemented 360 dinners and Kudo cards to solve the problem, or to make it less of an issue.
A 360 dinner is not eating in a tower with a 360 view of a city… For a 360 dinner, you invite the whole team for dinner and you tell them in advance that before, during or after dinner, the entire team will evaluate each other’s performance. All participants will do so at the dinner table, face-to-face. Note that many people find this scary as hell. Therefore you, as a manager, will volunteer to be the first one to be evaluated. Really invite people to give feedback good or bad, it shows courage and respect. It helps to loosen up the atmosphere so that people know what to expect (and how to behave) when it is their turn to receive feedback. Feedback can concern things that people appreciate (keep), things that people do not like (stop) or things that people feel you are not doing (start). So bring a pen and paper and make notes on what people tell you, remain a listener, and this is very important: really thank every person who gives you honest, valuable, and constructive feedback. Because sometimes it is not easy to be honest. You need to reward that. Read more about the 360 dinner here. A 360 dinner will give an entire group of people working on a shared end result an opportunity to provide feedback to each other so as to inspect and adapt. By having all participants give and receive there is collective ownership. Note that we have been part of 360 dinners where compliments were given to people where the compliment had remained implicit for years, because people thought it was obvious that others were doing a fine job.
Kudo Cards are small gestures of gratitude. We found out what Kudo Cards are through Jurgen Appelo as described on the Management 3.0 website and in his book Management 3.0 Workout. Kudo Cards are a written and public recognition of a colleague for something he or she has contributed to the team. A Kudo is not just given from the top down but can be peer-to-peer, cross department and cross organization. Anyone, or the whole team, can publicly recognize someone else’s work. Over time, people can be given multiple kudo cards for various reasons. It is a way to break down hierarchical limitations and to encourage everyone to offer instant feedback and to publicly show appreciation. You can read more about how to implement Kudo cards here. Using Kudo cards, we gave everyone the opportunity to give small pieces of feedback to everyone and to do it time and again. The feedback is positive, but we believe a review should in general have a positive approach. As a manager you can read the Kudo cards and find out where to go for information about the performance of an employee. Also, managers are able to provide feedback to other employees by using Kudo cards. Again it has been noteworthy that certain people in our organization gave a good Kudo card to others where we did not know that there even was a work relation between the two.
You are reading this blog. That almost implies that you are interested in developing yourself: you want to be updated so you can perhaps learn from it. We hope you read some interesting things in this blog. If so, you maybe share this blog with a colleague, “Hey, Jim, I read this interesting blog, you should also read it.” He will say yes and will probably never read it because he has other things to do that are more important for him. This is a problem that happens in many organizations: people are just too busy with projects, deadlines, implementations, escalations, and other important stuff. They forget that they also need to invest in themselves, because when they wake up from their daily grind, they may learn that the world around them changed while they were busy with their day-to-day tasks. Take the Windows desktop developer who finds all other products in their company went web or the exploratory tester who finds all other testers really engaged in Selenium. You need to keep learning and you need to be able to answer the question: “What did you do to become a better professional?“. We have seen this problem at multiple companies where we worked.
Again, we looked at the XP Practices to come up with ideas or to reflect ideas we already had. We linked Pair Programming and Small Releases to this challenge.
We don’t know about you, but we feel that learning together with your direct team members is much more effective and fun. So we had to come up with an approach where people can learn together. With this we don’t mean sitting next to each other in a classroom for a whole week on a technology or product that you will only be using in a couple of months’ time when you will have forgotten all about it, but really learning together and getting hands on with the stuff at hand. The other practice that we feel is applicable is small releases. We think it is way more motivating to learn about new things in small chunks. Ralph has been participating in an online training these last weeks, Fundamentals of Business Process Management, a very interesting topic. The training, however, takes two months and requires several hours per week. You could argue that Ralph lacks discipline because the training is turning out to be a bit of a struggle, but then again would it not be easier when the training would just be a few weeks, with a deliverable every two weeks?
Taking these two practices in account we concluded that Exploration Days could maybe help us. In basics, a group of people gets self-organized and takes 24 hours to explore something, no further strings attached. So no hackathon where the goal is to create a usable deliverable otherwise you failed. Note that there are many names for events like these. Exploration Days are meant as an invitation to your employees to learn and develop themselves by running experiments and exploring new ideas. The goal is to get employees to learn as much as possible and perhaps even to come up with new ideas and insights. Experts agree that the purpose of hackathons and other forms of exploration days should be to experiment with ideas, not to ship things. Organizations must now learn to run such experiments regularly, because those that learn fastest are the ones best able to survive. You can read more about how to organize an Exploration Day here. Our takeaway from one of the exploration days is not to be too formal: let the people get organized themselves and come up with ideas perhaps a couple of hours before it starts. For example we now know of an active Selenium users group that formed out of an Exploration Days experiment to investigate the usefulness of Selenium in a certain product.
We encountered several times that management, and that certainly also applies to us, made decisions and that we thought that it was crystal clear why these decisions were made. Time and again we found out that it was unclear to the people around us why these decisions were made and on what grounds. We know that professionals are sometimes just really engaged in their scrum team and are not that aware of the world around them. We feel, however, that it is the big-time role of the messenger to change the format in which news is delivered about decisions that were made. Now, in some cases different managers make different decisions or they communicate in different ways or the people listening are just lacking a piece of background information. Looking again at the XP Practices we picked Test-Driven Development and Coding Standards.
So test-driven development: When you create your test first, before you write your code, it will find be much easier and faster to create the actual code. The combined time it takes to create a unit test and to create code that makes the unit test pass is considered to be about the same as just coding it up straight away. But, if you already have the unit tests you don’t need to create them after the code. This saves you some time now and lots of time later on. Now let’s compare a management decision with this test-driven development principle. Think about how you will establish that a decision has the desired effect. Well to really establish this, you need to have facts, or data. And to do so you need to have facts about the before and after. This means that you need to collect data so your decision can be evidence based. This will allow you to verify whether your solution has an effect. Since you have smart people working around you, having this data will then also help you to explain about why you are going to make a decision and it can be easily shared with the team.
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” — Jim Barksdale, former Netscape CEO
The other practice that immediately applies, in our opinion, is coding standards. Remember we just said that different managers make different decisions and they often communicate in different ways? Coding standards keep the code consistent and easy for the entire team to read and refactor. People deserve consistent answers when they ask questions to their managers: respectful, truthful and transparent information. People in IT are usually very smart people and they will know when your info, well to put it boldly, sucks… Additionally, it does not mean that you want to describe every situation and/or question in a policy which will turn into the world’s most sovereign sedative. That would only create an organization with lots of bureaucracy, a place where no one wants to be, let alone work. We believe that you should have some high-level policies for some topics, actively share the commander’s intent, and then give the managers the freedom and responsibility to deviate when he or she would like from this standard. After all, what fun would French grammar be without its irregularities and exceptions. In our opinion, one ring to rule them all only happens in fairy tales.
We had a discussion with some team members about the costs of flying to our other development center. The Dutch crew did not particularly enjoy that they had to go Schiphol, a long drive, fly with KLM, have high parking costs, etc. They claimed that flying with WizzAir from Eindhoven would be much cheaper, less travel time, cheap parking costs and a cheaper flight. It turned into a recurring discussion until we decided to create the test. Note that we should have made this test upfront and we should have shared it with the team already, we know, we’re not perfect… So we set down to think about which costs we should calculate for the company for a visit from an employee to a remote location. After drawing up this full list we filled it with the actual costs: parking, extra costs for luggage (you know where cheap airlines make their money), etc. etc. and divided that by the actual time spent with the development crew at the other development center. KLM flies daily, where WizzAir only flies a few times a week. The entire calculation then clearly showed that flying with KLM, via Schiphol, was way cheaper when you look at the hours spent with the team, than the WizzAir option. We shared this calculation with everyone and there hasn’t been any discussion since. Still, life would have been easier if we would have shared this knowledge upfront with the team. So now, we try to make these calculations or tests in advance.
Team members at all sites were complaining, at the coffee machine (as it happens in NL 🙂 ), about the fact that John was allowed to work from home and Perry not. John reported to manager Elton and Perry to manager Katy. There was an old, huge, corporate working-from-home policy. It was old, too long, boring, overcomplicated and no one used it because you needed a law education to understand it. We as managers decided to make a much more readable and usable working-from-home policy. We used this blog of Rich Armstrong as our example. A very readable document that makes it clear for everyone and still gives room to the manager to deviate. Since adopting this new coding standard we only ask, will you meet all requirements and we have not had any issues since.
For fun, search for the phrase Change management books on Google and you will get 114.000.000 hits. Yes it is an open door, but change is hard, very hard. People just don’t like change. We all know that changing things is hard and sometimes very necessary. So again turning to our coat rack with XP Practices, which one could we use? There are three practices that helped us: Release Often, Simple Design and Whole Team.
We firmly believe that you should always make a lot of small changes to be able to deal with a big change. Do not try to come up with a masterplan to change everything in one big bang, please don’t. Make small changes, constantly. Small changes that in the end lead to the big change you would like to have. Hey it is just like an agile project, so probably you will find out that the big change you wanted in the first place is something you did not really want :). Small changes are much easier to manage, to test, to deal with, but also to revert. There is no shame in trying a small change and reverting it when it does not work.
A team or department is not a computer. You cannot write a program that will exactly change the department as you want to change it. It just doesn’t work like that, a team or department is a living organism, a community. It is hard to predict, even close to impossible, how it will behave when you start changing it. So, we believe that the best approach is to have many simple and easy changes. As in XP: Always do the simplest thing that could possibly work (and then still you will sometimes be surprised). So keep it simple and do it constantly. We firmly believe in 1% improvement per day. If you improve 1% a day, you improve 167% in 100 days! Additionally, always try to involve the whole team. Who are you to think that you are smarter than a whole department or a crowd of smart people? Involve your team, make them help you, get buy-in, get your facts straight, and make them realize the change you would like to happen.
In one of our projects, we had an external consultant do a quick scan on our testing processes. As expected we found loads of possible improvements in our testing process. The result of the quick scan was a report with many recommendations. We decided on a staged and finely sliced implementation of the recommendations. Every development team focused on one improvement first, a small step. Every four to six weeks we then discussed their progress. As soon as the team had completed an improvement, we shared the improvement with the other teams, making it easier for them to adapt and if necessary adopt the best practice from them. One quick 1% fix was to have a team start using a mind map template to describe how to test certain fixes. A second small change then was to implement a peer mind map review in their workflow. The new system has been running ever since and other teams have adopted and changed or tuned the mind map template.
Another example is that we had a team that was a bit reluctant in attending retrospectives. In their opinion, it was a waste of time and they could no longer see the added value. Their team lead always ended up as the one doing most of the talking during the retro (and also taking home most of the next actions). We thought about what to do… this was definitely not a Whole Team experience. We simply decided not to make the retrospective mandatory anymore. For some Scrum Masters or Agile Coaches 3,8 bridges too far. We also asked the Scrum Master of the team not to focus on big plans to solve all problems of the world anymore. What then happened did surprise us, the first retrospective just a few team members attended. However, they had a very constructive meeting, the ROI of the meeting was perceived as high. The next retrospective more team members attended, still not mandatory! After a few retrospectives almost the whole team attended again, and the actions now were small improvement instead of large complaints outside of their circle of influence. The team lead did not attend anymore, it was no longer necessary. The team took ownership of the meeting and the actions, step by step.
“I think Team 1 is performing better than Team 2” or “Why does team X never deliver what they forecast?” Almost all leads or managers will have heard these statements from a higher-ranking manager, including us. The performance of a team is as good as the last user story they delivered. So how could we provide insight in how teams are doing and where do they need help to improve? Providing context is essential in metrics. Telling a manager that team Red is not performing is OK. That person should then also should be informed what the team could be helped with, how things were in the past and what is being focused on right now.
We concluded that we needed some metrics (we don’t use the word
KPI’s anymore, it gives us shivers nowadays). When thinking about metrics and XP Practices we made the following links:
Taking those practices in consideration, we looked at several metrics. In the end we decide to use the Improvement Scoreboard, the approach described by Anders Ivarsson and Henrik Kniberg in the paper Scaling Agile @ Spotify. Every Scrum Master fills in a scorecard every three months and the team has to decide on the score itself. It is their scoreboard. This already resulted in very interesting discussions within the team. Developer Julia is happy with the Product Owner and developer Andra really believes the Product Owner should improve. Discussion is good, it gets the communication in a team going and it is a different way of getting to inspect and adapt that you would normally have the retro for. It is also the same approach as with Planning Poker, if there are different values on the table, the team members have to share their opinions and as a team they learn. Next to the current score, you will see the score of the last time. This gives the team, manager and any other stakeholder, insight in how things are and how they are developing.
The most important thing to keep in mind when talking about metrics though: it is just a tool get to a discussion going. We do not believe you can only make decisions based on metrics or decide which way to go based on metrics. A metric is just a tiny fact. You can even call it a small rumor, and as with all rumors you need to gather more information to find out what the real facts are. Please note that we believe in evidence based decisions and for that you need statistics, metrics or data, just be careful. Having the XP principles has helped us many times in gathering data: Summit 2015: The Results.
As we discussed before, change is hard. Do you recognize the situation where you finally implemented Scrum in your team(s)? It took some years but Scrum is finally common practice within your department. You did it! Started bottom up, your vice president was a bit hesitant in the beginning, but you managed to convince him. Again, congratulations. The business, however, starts to complain: they need to prioritize their requirements every two weeks, they have to wait a week to get a burning customer demand or the deal will not pull through, they just need a couple of days from your guru developer for an internal side project, err now…, they have to calculate the business value of a user story instead of having their proven gut feeling as true. You explain the concept of backlog, sustainable pace, not disrupting the team, but it doesn’t help.
We had a similar problem with some development teams who were not really open to start using Scrum. They wanted to keep the whoever-shouts-loudest-will-get-his-feature-first-because-we-always-did-it-that-way framework. We decided that we had to use a metaphor to explain Scrum, to the team and their shouting stakeholders, and let them all experience Scrum. The metaphor should be as simple as possible. Explaining to a group that software development is an empirical process in which you have to apply the circle of Deming as much as possible was not the best approach to explain Scrum.
This was clearly related to the Metaphor practice, explain something using a figure of speech in order to imply a resemblance.So we set up a workshop, a Lego Scrum Workshop. The goal was to have a group experience what Scrum is, in a fun and relaxed way. In this workshop we explained some basic concepts and in three small sprints we let them experience what it is to do Scrum. Instead of building software, the group uses Lego to build a city, a metaphor that everyone can relate to. The team really liked it and based on the workshop they said: “OK, we are in. Let’s give it a try”.
We used the metaphor in another project as well. It was a product where users could make a reservation in a facility management application, the back end would synchronize the facility reservations with Exchange. The small development team of two developers built a prototype and also the first version. The next step was to grow the team with some developers, but also testers and a business analyst. However, the two developers had a lot of implicit knowledge. They didn’t create any documentation… not good but hey we have all been there (and will be there again 🙂 ). We could ask the two developers to write down everything what they learned so far… and then the new team members could read the documentation…. well even if I write this down it sounds a bit inefficient. We tried another approach: we role played the software. The business analyst was the end user, one developer was the client, another developer was the Exchange server, etc. The business analyst asked the first developer: “Can I have an overview of all my reservations”. “Sure, let me see… who do I need to ask this?”. So he asked the Exchange server: “Can you give me an overview of the reservations? “. “Stop”, said the tester, what about security? The “game” continued for a couple of hours and in the end all team members had a proper overview of the system and the intricacies that came with it. We still didn’t have any documentation but at least we shared the knowledge, using the team members themselves as metaphors for the system.
Congratulations and a big thank you, you made it to the end! Now, what can be your take away from this blog? We hope we gave you some ideas on how to solve some of the challenges you encounter during work. Sure we gave some pragmatic solutions. We also told you about some truths that are out there in XP. Most importantly, we tried making clear that you can use an existing framework to help you overcome a challenge. So try to look at things from a completely different angle, and use a framework to make sure that you are thinking about all facets.
In the end, there is nothing new to what we described here. What was new to us in that bar was to actively start using all these concepts and principles when tackling the next management issue we would face, instead of implicitly trying to deal with all angles.
If you have questions, remarks, ideas, notions, please contact us, just leave a comment, reach out to us or join us in our next session at our favourite bar.
Daan van Osch is Director of Software Engineering at RES Software. He is the manager of some 30+ people in three different locations. Daan is responsible for sustaining engineering at RES: maintenance and fixes of released products for customers experiencing issues. Throughout his career, from starting as a software translator, then techwriter, to software tester, test lead on to scrum master and development manager, and now to member of the RES Engineering management team, Daan has found that this experience is really close to offering what IT professionals need for management. Always with the customer in mind, he is a pragmatic manager and a firm believer in making a 1% change every day in his team, department and company. Keep it small and simple, make a plan and let’s get things done for the customer. Most of all, Daan has a drive to help people experience a safe, fun and challenging work environment where they can grow to become people that are energized by their job.
Ralph van Roosmalen believes people make all the difference in every project. The skills of people, how they work together and how they feel. Scrum, Kanban, eXtreme Programming, Management 3.0, these are just tools or frameworks that exist to help people. He has been working in IT since 1997. He had different roles: developer, tester, Scrum Master, Agile coach, lead, manager to VP. What he always liked most, however, was working with people to improve the processes and the environments they work in. He is an active member of the Agile community and shares his insights and knowledge by speaking at conferences and writing blog posts. He is specialized in recruitment, building (distributed) agile software teams and Management 3.0.
I checked out my new laptop bag last week and found an interesting card my bag.
This card raised a few questions…
First of all, who is inspector 46… are there 82 inspectors working at the laptop bag factory, does every inspector has his own card, did inspector 46 really inspect my bag? I did some Googling… but inspector 46 is not very know on the internet.. he or she has a facebook page.
Secondly, would (s)he sometimes inspect bags without pride…? Would (s)he still add this card or does (s)he also have other cards?
Thirdly, what did (s)he inspect? Did only inspect the outside, the inside, did (s)he perform a stress test on my bag?
And last, would this be something for testers and/or developers to add to their software…
Imagine, the first time you open an application, it displays the message “This application has been tested with pride by tester 23”, or when you open a menu item “This application has been tested and developed with pride by software development team Zulu”.
Why not? I believe most software development teams don’t get the credits they deserve. They only get the complaints and issue/bug reports from customers. How often did you contacted the help desk to give them compliment about with a new feature (and asked explicit to also compliment the development team) or contacted the development team directly to give them some compliments? How often do you see a development team on stage to get the applause of customers?
It’s not in our nature to thank people. It’s easy to complain. We, Dutch people certainly, are the masters in complaining.
I would like to ask you: Next time you work with software that you really like, or does exactly what you would like to do it (=Quality), send a mail or contact the development team and thank them explicit!
Or we could end up with all kind of messages in the application where development teams state how pride they are!
UPDATE: This blog was also published as an article in Testting Experience, read the article here.
I sent a presentation with the topic Things a Tester can learn from a Programmer to the organization of Agile Testing Days 2011 in Berlin. Unfortunately, they did not select my session. However, I still would like to share the things a tester can learn from a programmer with you.
There is often a healthy rivalry between testers and programmers. Programmers never read the specifications, never test their own software, it always works on their machines. Testers, always are nagging about details, act as if they are the customer, and bother programmers the whole day with their questions.
I used to be a programmer and I’m currently responsible for test management in a development organization. (No Mr. Programmer, this is not a degradation 😉 ) I discovered that it has some advantages as a tester when you were a programmer. I would like to share those advantages with you, maybe you recognize some of them or maybe it inspires you to think about some of the advantages and try to implement them in your organization.
Most programmers do code reviews on their code. It is a very good practice and I think almost required when you do no pair programming. Goal is to improve the quality of the code and increase the knowledge a certain area.
As tester you should also implement reviews, review your test cases with programmers, customers and requirement engineers. Additionally, also automated test scripts should be reviewed.
When you organize code reviews, don’t focus only on what the code does. For example, one person is the scribe, one person looks if the code complies with the guide lines, one person looks if the code is understandably, etc. The normal approach used by formal inspections.
If there is one thing that programmers are good in, it is programming and organizing a software project. (Or at least most of the programmers). Depending on your background as tester, you have to admit that programmers have more knowledge about programming as you. Brett Pettichord wrote several papers on test automation.
Test Automation == programming!
Use the knowledge of your programmers when you start with test automation. Ask one or more programmers to become part of the team/project group who will start with the test automation. This has two advantages, first they become also committed to the project and secondly you are able to use their knowledge about software projects.
When you set up test automation you should for example think about:
If it looks good then it is good
This section contains (some) prejudices, I already apologize on forehand.
Programmers don’t care too much about the details. They focus on the main requirements and don’t spend too much time on all the exceptions. As a tester it your job to think about all the exceptions.
Some times (I know I’m walking thin ice) a testers focus too much on the details and exceptions. Most software should be good enough, most software doesn’t have to be perfect!
Gerald Weinberg description of quality is: “value of a product”, extended by James Bach and/or Michael Bolton to quality is: “value of a product to someone who matters”. With this description, it is possible to deliver a product that contains bugs in exceptional cases/some areas. If the user never uses those areas, he is not interested in spending too much time on testing those areas.
Be careful as tester to spend too much time on testing certain areas. Act as a programmer sometimes and don’t spend too much time on testing in all cases.
(Ok, start flaming me about all assumptions I made….)
One of the good practices of Extreme Programming is Pair Programming. Pair Programming is code created by two people working together at a single computer. Pair Programming has many advantages, and believe me, it’s not inefficient.
As tester you could work in pair in two areas,
I’m already applying my next section, be lazy… 😉 Everything about test dojo’s is already here.
A good habit of a good programmer is, laziness. He hates repetitive tasks and always tries to automate boring and/or repetitive tasks with macros, scripts or (custom made) tools.
I often see testers who do a lot of repetitive tasks, for example install a new version of the software every morning, scan log files for errors, create complex reports with standard reports, etc. Why not start up your machine at 6.00am and start automatically an AutoIT script to start the installation, create a tool to scan your logs automatically or create some SQL statement to export the data to Excel?
Be creative and ask support of your programmers to automate your boring daily routines.
Every programmer know the Gang of Four and the book they wrote, Design Patterns.
A pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. My definition of a pattern is: a predefined described solution for a problem that occurs often.
Programmers use design patterns very often, a pattern that is often used is a singleton.
Why not create test patterns for tests that you have to test frequently? It’s not about features you have to test every release. It is about problems that you frequently face, and that can be solved by the same approach every time. Read some information on this blog about software test patterns.
How to write good comments
As programmer I wrote and read a lot of comments in the code. Some example of comments (in pseudo code) you often see are:
//If a < 1 then calculate a new value for X
if a<1 then calculateX;
//If an exception occurs during calculating of new date we raise an exception
raise E.Msg(“Calculation new date has failed”);
Tell me, what is the value of this kind of comments? This is the so called how-we-do-it comments, adding no value. Every programmer can read the statements above, it has no value to describe the statement again in the comments.
A good programmer writes why-do-we-do-this comments. For example in the above code, he describes why a should be less than 1 and why he raises an exception.
As tester always try to write why-do-we-do-this comments, in your test scripts and in your automated test scripts. How you test, that is clear, describe why you are testing the software.
Let’s end this blog with a conclusion…
I know I used a lot of prejudices and assumed also a lot…. but try to ignore the prejudices and all assumptions and see if there is something you can learn from the programmers.
Did I miss anything, or did I exaggerate too much… please leave a comment for me.
I have some tools installed on my machine that I use regularly and make my life easy. Maybe you already know some of those tools, maybe not… any way I write this blog to share them with you. Here are the tools, in random order:
In our development process we expect teams to do all testing necessary to deliver quality software. One of the disadvantages of our approach is that all product backlog (PBL) items are tested by testers (or if necessary and possible programmers or requirement engineers) from the team who also builds the software. In most cases this is not a problem. However, sometimes it could really improve the quality when others testers (or programmers, requirement engineers and/or technical writers) from other teams test the software.