​During my ET/SBTM workshops, I have been often asked if it is possible to perform Session Based Testing in typical Agile/DevOps environments.
 
I think if tester knows how to perform SBT (especially with different session types), there should be no trouble in doing it regardless of the development methodology their team follows. (If you are unaware of typical session types in SBTM, then I recommend you to checkout this informative series by my friend Simon ‘Peter’ Schrijver.) However, I understand that probably, the fast paced way of working through sprints, shipping small chunks of software regularly, keeps everyone mainly focused around achieving the sprint goal. And for testers, this often means focusing only on ‘acceptance criteria’ and moving on to the next ticket, which is waiting to be tested and deployed.  And that might force some testers to just forget every awesome technique they know and run behind getting “the stuff done”.
 
If you are a tester (sorry, Agile Tester) stuck in such situation and feel bad about it, then this post is for you. For a while, I too was stuck in similar situation. Not that I was not getting to perform ET in SBTM way, but I constantly felt something was missing and that there was still more I could do. A couple of important things were getting skipped off my typical sessions, and all I could do was procrastinate them. And that was bad, very bad! (yeh)
 
When I was done with feeling guilty about it, here is what I did (and I strongly recommend you too try it out). I created some more session types for myself some of which I perform twice a week and some I perform daily. And they have been helping me greatly so far. Well, what are they?

 
1. Critical Thinking Session 

I know, a good tester should think critically at every possible occasion. But there is no harm if you dedicate a special slot for it. How often do agile testers spend time on reading through backlog and preparing their notes in advance so that they know what to ask, know what extra information they would need for certain ticket or prepare a risk list associated with some ticket, to make everyone aware of it before it’s too late?
 
A dedicated ‘Critical Thinking’ session aims to solve this problem.  Schedule at-least two of such sessions, one before beginning of new sprint and one before your feedback/refining sessions so that you spend enough time for ‘critically thinking’ about stuff that would be soon on your plate. The sooner you prepare yourself with it, the better you will be able to shape your further sessions around actual testing of those items.
 
Medium sessions of roughly 60 minutes works great for me. Sometimes a short session of 45 mins is enough. The more you practice with Critical Thinking sessions and the more time you spend with applications you test, I guess you will eventually need lesser time for CT sessions.
 
In case you are wondering what I really mean by “Critically Thinking” about backlog items then please checkout “Mary Had A Little Lamb” heuristic by Jerry Weinberg or “Huh?Really?So?” by James Bach.
 
 
2. Monitoring Session 

Monitoring production logs especially after deployments has benefits of its own.  And if tester does it regularly then there is a lot they can discover through those logs.
 
If as a tester, you are not yet doing production deployments then I suggest you start doing it and make sure to check production logs (or logs on other environments for that matter). If for some reason, you do not own deployments then try to spend at-least one short session for monitoring your application’s production logs, every day. That’s what I mean by “Monitoring session”.
 
Because of such dedicated monitoring sessions, I have come across some illusive bugs that were hard to catch on testing environment. Production logs are also very interesting means to learn about different ways in which you can test your application against disfavored use or extreme use (refer HTSM by James Bach – SFDIPOT – Operations). Not only that, it can also help you identify some illusive integration level bugs which might not be caught easily otherwise.
 
Monitoring sessions can also help you identify technical bugs, errors or warnings, which might not be directly affecting the end user but still warrant attention and fixing. It’s hard to identify such issues in regular functional testing which usually has big scope of its own.
 
 
3. Bug-visit Session 

This session is about visiting the bugs in backlog and going through them carefully. Sometimes, over the period of time, some bugs become irrelevant or can also become important to be fixed on priority. Revisiting those bugs helps take appropriate action on time.
 
If there are bugs logged by other teams or customer care team for example, then they can also serve as a great ‘test ideas’ that can be extended to other features of application. Information gathered through such bug-visit sessions can help you create your own risk-list or project specific heuristic (I have explained that in detail with HEEENA).
 
So, that’s about three additional session types I have created for myself to do even more effective SBTM in agile environment. I am finding them very useful and hope you too will benefit from them.

Feel free to get in touch if you have any questions or would like to discuss it further.
 
Happy Testing!
 
​Header image credit - blog.xebia.fr 

​Before some of you start freaking out, let me make this clear - no, it’s not the pot some of you might be thinking of :)       It’s an abbreviation of “Problem on Table”, an activity we have recently started doing at XING AG for its testers.
 
As facilitator, I have experienced the benefits of POT method of problem sharing (and solving). I was first introduced with the idea at ITB tester meet-ups I participated in Pune/Mumbai and in order to facilitate such exchange for testers at XING, we decided to give it a try with some twist. And guess what? It worked really well!
 
How does it work?
 
The key idea of POT session is that testers come together and share their testing problems.  This is done in order to get support from fellow testers who might have faced similar problems before or you find more testers facing similar problems and then work together to solve them.
 
The format of POT sessions I did in past used to turn out chaotic soon, because of lack of moderator control over discussions, too many topics being discussed at a time etc.  And that sometimes used to confuse the problem presenter instead of getting solutions to the problems they shared.
 

 Presenting "POT – the Lean Coffee style"

To make the exchange less chaotic and inclusive for everyone, we decided to do it in Lean Coffee way. And boy, it did wonders!
  
If you are aware of Lean Coffee and now POT then it should be rather easy to guess the format.
 
Set-up notes for facilitators:

1. Find nice café (or any place for that matter) where people can sit back, relax and discuss things freely (optional, but works great).
2. Create three columns on wall or table with To Discuss, In Discussion and Discussed (or just To Do, In Progress and Done should be good).
3. Keep enough post-its and pens/markers handy

 
Here are some simple rules we followed that worked great for us:

1. Group size of not more than 5-6 (including facilitator) on one table
2. Each participant in the group gets to write one card around testing problem they need help with, in not more than 3 minutes
3. Facilitator to stick all post-its in To be Discussed column to begin with
4. Each members gets 2 minutes to explain their card/problem in brief
5. Group then does dot-voting on topics after which facilitator re-organizes the cards from highest voted to lower ones. 
6. Then like typical Lean Coffee session, group discusses the topics one by one in time boxed manner and voting each time if they would like to discuss the topic further or move on to next one.
7. I strongly recommend that facilitator (or someone else in group) makes sure to take notes of solutions discussed
8. When there are more than 5-6 testers wanting to participate, I recommend that you make multiple groups and then share your notes latter on or you reshuffle the groups for next sessions.

 
And that’s it. You are ready roll!
 
Our first POT- Lean Coffee style session went on for two hours with five minutes break in between and I am super glad that we had some much cool stuff to discuss and everyone had some or the other idea to solve their respective problems.  That’s the power of teamwork, isn’t it?
 
The key takeaways from our first session:
 
In two hours of highly engaging discussions, below are some problems we discussed and the solutions we felt could help solve those. I strongly feel that many testers would face those challenges regardless of the organizations they work for and hence I am sharing the solutions we discussed, hoping that others with similar problems might find them helpful.
 
Problem 1: What happens when Tester goes on vacation?
 
A classic problem many Agile teams face in my opinion. So, when tester (who is generally only one person doing testing in team) goes on vacation or falls sick, the team usually suffers and tends to rely on automated tests or performs minimal testing which often results into big problem. What a tester can do to solve it? Or if I may say, what teams can do to solve this problem? Here are some ideas that have worked with some of us:

• Make team understand that Quality is team’s responsibility and needs to be baked in at each stage of development instead of relying on some Quality inspector to inform about problems towards end of it. But that’s easier said than done, right? Worry not. There are ways to do that.  Try WIP limits in your sprints may be? When tester is already stuck with some tickets and when rest of the team can not proceed because of WIP limit, it compels others to help tester in finishing his job so that WIP licenses could be freed for further work. May be rest of the team won’t be able to test as meticulously and productively as one skilled tester would, this will still make them used to the process, philosophy and mind-set. And when tester is on vacation or falls sick all of sudden, team will have something useful to do instead of panicking or freezing in headlights.
• Other cool way to on-board non-testers to work as tester in emergency would be to try ‘pair testing’ sessions with programmers one by one or to do ‘mob testing’ sessions as a team. Each of them has benefits of their own. And from personal experience I see value in them.
• Some other ideas would be to create hand-over documents, test plans, test-idea mind-maps, videos and confluence pages around “How to test it” in advance.   

 
Problem 2: How to manage integration testing with different teams/apps?
 
If the app your team builds is just one part of several applications working together for your one business product as a whole, it often becomes challenging to plan out and maintain hassle-free deliveries throughout. And end-to-end testing becomes even more challenging under some circumstances.
 
Different teams are likely to have different notion of quality, different development methodologies, different business plans and thus, naturally different release plans. Things become chaotic when testers are left alone to solve such problems, or when such problems are identified very late in development of some feature with rigid deadline.
 
And who else can understand such problems any better than fellow tester from other team? Do you see some solution there? We did and I believe it helps. Here are some ways to facilitate that:

• Meet testers from other teams over coffee or so and have an exchange around what feature they are changing soon and seek to understand what those changes mean to you and your test strategy. Of course announcing such things on chat-rooms or confluence pages could help, but we felt that having in-person discussions would be more effective.
• Create combined test strategy that takes into account the release plans of both teams, impact analysis of changes to be made, sharing of testing scope or perhaps building some reusable components for each other? (like helpful scripts, automated tests, test data set-up etc.)
• To facilitate the cross-functional knowledge pairing sessions with testers from other teams, or asking/offering peer review on your/their tests/automated scripts, pull requests could be helpful. All such reviews do not have to be done by programmers as it typically happens. If testers start taking part in those, we feel it would benefit everyone. 
• Some sort of mutual contract or protocol can also be established between testers from different teams who usually test the apps that have high integration dependencies. I would call it as a take-away from informal meetings or pairing sessions etc.
• Early involvement of testers in feature kick-off or product planning can also help POs or Team Leads to identify such dependencies in advance and consider those in their planning. We feel, tester should ask for such involvement if they are not involved already. POs/TLs would definitely love you for throwing light on potential problems of future.

 
Some of the other issues we discussed were around pushing for bug-fixing, fixing high-bug-tolerance problem of agile teams, common pitfalls of agile testing, what real agile testing should look like etc. One of the suggestions from our experienced tester Dirk Meißner was to hire programmers who take testing seriously and have quality mindset. I feel that’s very good approach. Precaution is always better than cure, isn’t it? 

So that was about some key things we discussed in our first POT-Lean Coffee style meet-up. And we are already excited about the next one. How about creating one in your organization and sharing your learning with us, just like I did? Let there be some coffee, some delicious cake and of course some Problems on Table. Enjoy!

​Nothing beats the pleasure of talking testing with old friends on cozy afternoon of weekend. Even better if it is long weekend and weather is awesome (I must tell you I have fallen in love with Spring in Germany). 

I met Pratik last weekend after quite some time. Apart from working together on Tea-time with Testers, Pratik and I have also worked on setting up and running Testing CoP under TCS-Cisco relationship. Pratik is now setting up Testing CoP for his new team and wanted to brainstorm around things we did in past. Instead of keeping our notes just with ourselves, I thought I would rather share them in this blog so that others can benefit too. 

Before I jump onto the outcome of our brainstorming, I would like to talk a bit about my personal experience with Testing CoP. 

After TCS, I took up an opportunity with Barclays Investment Bank (GTC lead by Keith Klain) and there I was privileged to work with awesome testing leaders like Leah Stockley , Kshitij Sathe, Shrini Kulkarni and Sudhanshu Bodoni. During my tenure at Barclays, I worked as Test Strategy CoP Lead and then Testing L&D CoP Lead under Innovo8 program. Apart from that, I was teaching RST full day workshops and running Lean Coffee style testing meetups with awesome bunch of testers in the organisation.  

All above activities that I got to perform have helped me understand testing even better and most importantly, the experience has taught me the skills and lessons for successfully leading CoP. I value those lessons a lot since CoP set-up is generally different from typical project team set-up and each of them require sort of different skills to lead. 

That said, below are some lessons learned we feel could help one working with Testing CoPs. However, I must say that they are based on personal experience and others' experience can differ. 

​
1. Start with having a clear goal in mind 

Working with CoPs can be tricky if you do not have a clear goal defined. The big part of it also depends on why your organisation or unit wants to start CoPs at first place. Is the purpose to stimulate communication and collaboration? Is it being done to foster innovation? Is the end goal to enhance productivity and building skill sets? Is it about creating reusable components? Or is it as broad as establishing an intellectual work/testing culture? Also keep in mind that an organisation-wide CoP goals may not clearly tell you what they mean for the individual CoP you are looking after. If you are to lead CoP you must understand the bigger goals and be able to define the goals for your own CoP that are aligned with them. At the same time, keep in mind the dynamic nature of CoPs and be open for shift in focus as community evolves. The challenging part is not to let the group get too much dragged away from original goal but keeping them motivated at the same time. There is a way to address it. Let's talk about it bit later. 

Indeed it is possible to start from no clear agenda and then letting the CoP evolve. But I personally feel the danger of running into chaos and getting into situations that are difficult to manage with that approach. Of course, you can work with other members of the CoP and come to the common conclusion of the goals for your CoP.  Again, this is not as easy as it may sound. There might be conflicting situations, differences in opinions, disagreements on action items, lack of participation, motivation issues and what not. More on that part later... 

2. Know your success criteria 

Another important part is to be able to measure the success or effectiveness of your CoP. One may argue that CoPs are meant to be informal, ever evolving and all but it is hard, rather pointless in my opinion to run CoP without any measures for success. Wenger-Trayner in their book on CoP mention that, "It may be difficult to attribute with 100% certainty the activities of a community of practice to a particular outcome. You can, however, build a good case using quantitative and qualitative data to measure different types of value created by the community and trace how members are changing their practice and improving performance as a result." And I totally agree with it.

As a Testing CoP lead or member, you may want to understand what practices testers are currently following, what are current challenges and what changes they did from inception of your CoP. That will tell you what impact your CoP is having and the value it is creating. A classic example from my experience with Barclays' CoP was that we saw testers adopting Context Driven Testing  and RST practices in their work. Switching from traditional excel based format of test case writing to mind-maps and ET charters was noteworthy.  With CoP in TCS-Cisco, we noticed more and more testers taking active part in online testing forums, writing testing blogs, participating in competitions, creating reusable components and coming up with solutions that were never discussed before. As a matter of fact, we created "Tea-time with Testers" magazine for global testing community by taking inspiration from the work we (me and Pratik) did there as CoP leads. 

3. Be the change you want to see 

From personal experience, I can say that motivating others and inspiring actions is key factor for the success of CoPs. Throwing ideas is other thing and proposing ideas with practical experience around those is a different thing. The latter is more important for CoP since "Community of Practice" is essentially about people with practical experience of what they come together for as apposed to "Community of Interest".

To be able to lead CoP or to be an effective member of it warrants you to have hands on experience of solutions you propose or ideas you pitch in. The more experience you have the better it is for you to help others. You can not just expect someone to present at a conference or write a testing article or implementing some new testing practice without you having done it yourself first.

Most importantly, people in general don't like to be told what to do (thanks Leah for this important tip) as they have intelligence, experience and opinions of their own. And that's quite natural. If you want people to buy your ideas, you better demonstrate them how you did things, what benefits you gained and how you solved problems on the way. That way, most of the open minded people would at least try your suggestions out before turning deaf to your proposals. Remember, it's about also about people, community and not only about your own personal choices. 

4. Be a People Person (and not a person liked by just few heavy-weight people)

Even though it is of Practice, in the end it is a Community and it's about people. As mentioned earlier, a lead of a CoP may often need to deal with conflicting situations that may prevent members from contributing their best . Some of the reasons for these barriers as per (Wasko & Faraj 2000) are egos and personal attacks, large overwhelming CoPs, and time constraints.  I would add petty politics and favouritism to this list. 

For running a successful and healthy CoP it is important that one connects with people very well, understands their preferences, listens and values their opinions and rejections alike. The better connected with people you are the more likely you are able to affect their participation in CoP in positive way. Mapping knowledge and identifying gaps is one key problem CoPs can solve and a 'people person' is likely to be well equipped to make it happen for they will know "who knows what" or "who can solve xyz problem" or "who can be the right person to make something happen". The best thing you can do as a lead is to give right opportunity to right person and not getting tempted to give it to someone just because you like them more. Be transparent and care for everybody's contribution, your people with love you.  

Sometimes leads also fall into trap of keeping only heavy-weight people happy and with that pressure they expect other members to support them. This causes more bad than good and is a great recipe for stopping evolution from happening. There is very good reason why Kipling says, "walk with Kings—nor lose the common touch" . Listen to the wise men :)  

5. Care to connect with the Community outside 
 
Just knowing about people and practices within organisations is not going to help much if you want your CoP to truly create some difference. 

Be it for leading a CoP or becoming its influential member, your connect with outside community (the global community if possible) is going to empower you like nothing else. Connect with people/communities outside, see how they are solving similar problems, learn from their mistakes, see how they are making something happen, know what is their criteria for success, what resources they are using, can you borrow something from them? Can you make use of their expertise to serve your CoP's interests? Perhaps you can invite someone from outside world to conduct a workshop or deliver a guest lecture? There are endless possibilities here....all you need to do is caring about your own learning and community connect.

If you know outside people in person then even better but knowing about work done by some expert can also help you make a stronger case for your proposals. Read articles, participate in community forums/chat groups, attend conferences, join webinars..there are endless possibilities here too. If I need to give examples, my experience with Weekend Testing sessions gave me great insights for running test sessions and introducing new testing concepts. Because of our personal connect, James Bach did some guest appearances over skype for our teams and local meet-ups and that inspired testers to great extent. My voluntary experience with teaching BBST Foundations through AST connected me with several passionate testers worldwide and we still help each other with ideas when needed. 

The global testing community is the best community of practitioners I have ever seen and you will never run out of help should you ever need it, that is assured.

​6. Make it Bottom-up but also a Top-down thing  

If your intensions are good, efforts are sincere and have powerful friends in your organisation then there is nothing that can stop you from doing good. Understand what big people sponsoring CoPs want to achieve with it, especially with CoP that you work with. Ask them how you can help them solve their problems together with awesome bunch of people in your CoP. This would not only help you to align and priorities the goals for your CoP but also it will help people understand that their contribution (no matter how big or less) matters to the organisation. And this motivation is far more powerful in my experience. 

On the other hand, try to bring big people in your CoP meet-ups or important event sometimes. A small pat on back of your group will make miracles to happen, I tell you. I still remember some occasions when Keith Klain (who was GTC's Global Head then) found time from his busy schedule and spent time with our Lean Coffee group. The impact of that interaction lasted for longer period and it helped us gain better clarity of what was expected from us. Needless to mention that such interactions help you crack some hard nuts without having to behave tough on your part. Try not to burn the bridge with people because you are going to have to work with them in the end. Leave such problems for big people to handle. Their attention to your work is enough to solve some tricky conflicts.

These things appear small in nature but I recommend you to try it and you'll thank me later for this tip.   

​7. Don't make promises you can't fulfil in your capacity  

It's hard to motivate people but not entirely impossible. What matters is your ability as a lead to understand what an individual takes motivation from. 

In order to keep people engaged and motivated, leads sometimes make promises for tangible returns such as promotion, pay raise or bonus. Don't make such promises unless you can really make such decisions or influence them any way.  Instead, find out what motivates people by spending more time with them. Extend your engagement with them beyond formal meetings. Build personal connect. Seek for people who are motivated by intangible returns like reputation, self-satisfaction and self-esteem, networking opportunities aimed at interactions, learning and sharing. And try to make them visible so that others also take inspiration from them. 

8. Identify your own motivation and be true to yourself

On top of this everything, make sure to identify what motivates 'you' first. An early access to information sometimes makes people want to do things and their interest/passion usually fades up once they get what they wanted (pay raise, promotion etc.) or when they realise it's not going to happen for them.  There is nothing wrong in getting motivated with tangible returns but please also make sure that your passion does not die regardless of returns you get.

In my opinion, it's passion that makes a big difference. Keep doing your work sincerely and good things will happen to you sooner or later.   

Well, that's all I could recreate from the notes of our discussion. 

From my experience with leading CoP for over five years I can say that one needs to be jack of all trades and master of many to be successful here. Some of those skills are relatively easy to acquire but none of them can be acquired over night.  Certain things can be learned only through experience and over the period of time.  

You got to be passionate and be patient at the same time, and that has been my biggest take away whilst working with CoPs. I hope you find these tips useful in your adventures around CoPs. Don't hesitate to reach out to me if I can be of any help or would like to discuss. Good luck!