How I broke free from script testing

I became a tester without any training. I was doing testing as part of “Making sure what we deploy to live is working” as a sub section of my day, job and I loved it. I decided that subsection should be my job and I applied to become a tester without ticking most of the boxes in the job description.

At that time testing as a job was not popular in my country. So naturally, I used the online guidelines. They were talking about documented test plan before the development, doing testing development phase, make sure test scripts created and followed as it is.

My main task was to create test scripts in my first job as a tester. I felt bored as all I did was going through a web site and write test scripts. When I found issues, they went to a backlog where they will looked at later. No date given. Nevertheless, they were live issues. Some issues can cause customers not fulfil their journey. I suggested that we should start testing with what we have developed than waiting for the last minute. My thoughts are very unpopular because the tech lead/team manager did not like me coming up with new ways of working also not adhere to the process they are committed. They also commented on my lack of experience as a tester. I left the place in 3 months, as I was not enjoying my work.

I started questioning my decision on changing to a tester. I felt lost. In my next job, I started asking questions from a developer mind-set. Fortunately, there were right questions to ask and that helped the team to think. I created test scripts and shared with the developers but kept some scenarios for myself. I guess I wanted those failed scenarios. I wanted to make sure I clear myself as a person who finds the cleverest issues. Be the cleaver one. It paid off. While a new section develop, I just wondered in the application. Came up with situations that are clearly not behave as wanted or a missing requirement.  Not everyone impressed as my issues was delaying the project. However, I was so satisfied with my job. Company closed due to financial troubles and I was on job-hunting again.

Meanwhile I did ISEB beginners course. It helped me to understand some concepts and open few doors to experiment.

Next job required script writing as well. Nevertheless, I slowly moved away from it as the script writing and updating them so much of my time. Slowly I negotiated with the PM and used the scripts as a guideline. As a basic test to provide some documentation that, he needed. One thing I realised is some testers in the team did not know the application well enough to explain it to someone else. They used to follow the scripts and they did not know anything outside the scripts. I did not like the fact. I wanted to wonder around the application and learn about it. How it works and affect with different inputs. I learned so much about the application and found issues in the same time. I was able to explain the application and discuss the functionality with others without a problem.

I practiced the same in my all other jobs after that. People were not happy about it first but I gave them results. Therefore, I was able to walk away from scripts slowly. When there is UAT I had to create scripts as we wanted the people who do the testing to follow exact steps. No room for users to wonder around and find issues. My objection to this dismissed in all projects that needed a UAT.

In current job, when I first started I needed to write teat scenarios for each story. Of course, I did not like it but did not raise my concerns as I was more adjust to the country, people and their practices. Later with my confidence grow I stood up to my beliefs. Wrote a line or two of what I test to make sure I remember what I have covered. I have commented on this several times but I did not change as my manager wanted. She was a project manager and not have any experience on testing. She made sure she read about testing online and make sure I followed the same. However, she slowly gave up following me up with what she read and I got things my way.

Later I read that what I was doing was a flavour of Exploratory testing and I was right to get away from scripts and scenarios. I read the reasons behind the decisions. Nevertheless, I know I am still not doing the Exploratory testing on the right way. Which I am trying.

Lesson learnt was to follow your heart, show results and slowly break away from things that take away your time for documentation and reporting.

Think differently when working with distributed teams

Distributed teams. We all working with distributed teams. Whether it’s in different countries, different cities in the same country, different floors in the same building, and different teams in the same floor or working from home. All count as distributed.

What issues do we face? There is a lot! However, when we start to discuss the issues, we always see the negatives and we talk about issues caused by the other side.

What we can do to correct this? We go hands on the air and say they should do this and that. Yet, we never think what might they think? What we can do to help? What behavioural, thinking and communication changes we can adopt?

These discussed in a Testbash workshop where Steve (@sjwatsonuk) and I attended. We recreated the workshop in our company as a pilot. Due to its success, we did it again to a different set of people and it got all positive feedback. Positive feedback for the workshop is brilliant. How positive the people feel at the end of the workshop matters. However, how much they practice the learnings is a question. Which we hardly get any feedback.

I am fortunate that most of my team was in the pilot program. From the next day onwards, they started to discuss how they could do things different. Now they are thinking differently. Take actions to include the nearshore team more in team discussions. They see why this is important. The nearshore team ran few retrospectives from their end and as well as conducted few stand-up sessions. Progress…

I believe if we think open-mindedly, we can collaborate successfully. Distributed teams created to deliver more work with a high quality while maintaining the costs or reduce cost. Everyone is part of  the project success. Build trust not pointing fingers, build communication openness on both sides so no one feel left out, build environments where everyone can ask questions and give answers to make the product better. Give constructive feedback and encourage it to come from every team member disregarding the location. Learn about their culture and try to help them to connect with you. Specially, praise each other when do well.

Have you ever worked from home? Was it easy to connect with your team virtually even you know them? Can you find people when you need an answer? Have you deliberately picked up work that you can do without the need of anyone else when you planning to work from home? If you are getting frustrated with your team when you work from home for one day, how your other teams might feel when they have to go through it everyday?

I am working with Abby (@a_bangser) who is one of the original presenters of the workshop, to deliver the same workshop in Helsinki for European Testing Conference. An exciting opportunity to help more people build empathy towards each other.

Remember, we all distributed to each other and small change of thinking can make a big difference.

Sometimes its good to ignore the rules 

Yes. Sometimes it is okay to ignore rules, think from a different point of view. This may cause you issues and criticism and temporary failures but as long as you have a plan, it should be all right.

This is my journey on implementing a regression test suite in current project, how I solved different hurdles. I have broken many rules but now I believe it is a success.

When I join, the project there was acceptance tests embedded to the code. So as the unit tests, feature tests and integration tests. Those acceptance tests not cover user journey but more of a single function. All different tests are based on one code base. Acceptance tests were running in TeamCity as well.

I spoke to the team and then start adding tests to the acceptance tests because I felt it is not enough. However, it was making the code build too slow and maintenance get out of control. Why? It was one code base. When acceptance tests fail, the tests were either ignored or made to pass. Tracking them was difficult.

Therefore, it was a failure. I was discouraged and almost given up!

Then I asked the team how they feel about me creating a separate test suite. Seniors objected because it will make a duplicate code, unnecessary maintenance etc. I felt disappointed and discouraged again. I maintained an Excel sheet as a check list for different functionalities but wasn’t happy. Testing had become a long process when it come to build pick and deployments.

Few months later, I started creating the test suite without telling anyone. I copied some of the functions from the main code base that I can use and build up on it. It came out as exactly I planned. I started using it for checking the releases. So far, all happening in my local machine. Then I showed it to the team saying this is what I have done. I even used the test suite against live environments, which had not happened before.

Only few impressed. Same arguments came. I mentioned this is only maintained by me so it should not be any overhead to rest of the team. It will be in the common repository but I do not want the development team to update it because I would like to have a control of what goes in and out!  Did they agree? No. They were telling about what happen if they change the modules that I have copied. My tests are independent from their code base. I just ignored all their concerns for their displease.

Some helped me setup the build in TeamCity and the team started to see results. Build picking and deployment times reduced. Issues caught up front in areas that was not thought of… Stage 1 succeeded.

I wanted to discuss the tests and its coverage with the business but the tests are very technical. Therefore, I wanted to do BDD format. However, all the documents I read and all the courses/workshops I went to told that BDD is a way of communication and it should start from the business and the teams talking to each other. I agree yes.

However, our team was doing most of these things. We are having open discussions with the Product owner. The business analysts are writing the stories in a Given, Then, When fashion .Doing changes from top to bottom will be troublesome. Many people do not want to change how they work unless there is a perfect valid reason.

Therefore, with a help of a contract tester we changed the existing test suite to use SpecFlow. Introduced BDD to the Regression tests and converted all tests. Detailed SpecFlow reporting and tests running in multi-thread mode the reduce overall time impressed the team. They now backing us with having a separate test suit.

When mobile tests needs to be done, it was easy for us. We expanded the tests to different devices to different break points with ease.

Then I showed the test suite to the product owner. Taken him through few scenarios.He was clearly impressed on what we have achieved. Now I am working with some editors to understand what scenarios I might be missing from their point of view. Involving the business with testing was great.

Now I am working with the business analysts to see how we can work together with the BDD scenarios. Whether I need to change the language that I used in the feature files or they need to change theirs or whether we can meet half way. We are going to try it on a small functionality change so there will not be less impact.

There is long way to go but I am happy the way I have made an impact without playing by the common rules.

Therefore, I think it is good to break rules now and then. Well it worked for me so far.

London Tester Gathering Workshops ’16

I had a chance to join by LTGW in June 2016. I took my time in writing this blog because I wanted to see what I would remember after sometime. I normally blog as soon as I come out from a conference but this time I thought to wait and see.

LTGW is different to other conferences because it is only contain workshops. Many interesting workshops. Personally I had went through the list of workshops several times, made my mind, changed it, went through again, changed it to original and changed again. That probably explain how interesting the list of workshops were.

Tony’s (@tonybruce77) power of asking questions workshop was a highlight. Asking questions is easy but asking the right question is difficult. One of key point I remember is that we should ask questions not only for self-benefit but for the benefit of others as well.

Yes true. Many times, I have asked questions where they benefit me but sometimes I have asked questions to make sure the person who explains the situation had thought about them too. Many occasions I have seen people build up conversations based on the question I have asked. I have not thought that the conversations that build, ideas that triggered and areas that discovered are results of a simple question. Sometime your question can be the answer. It is always better to ask the question than being scared of it.

Then I went to another session on Mentoring by Tony and Dan (@DanAshby04). We had discussed about what is Mentoring, Coaching, Teaching and Leadership. In a summary,

Mentoring is about to grow others skills, Listening to others and share experience, provide continuous help on need basis, guiding, encouraging and help

Coaching is about transfer of skills, problem driven, not on going, maximise skills, and have an end goal

Teaching is a structured program, delivered one direction, share Information, inspire, and evolve

Leadership is about being responsible, Delegation, Representation, Accountable, Inspire, Motivate and Organise.

It was nice to see the difference of each sections as sometimes mentoring and coaching described in the same manner.

Both above workshops filled with interesting videos and fun exercises.

I was in two other sessions thinking I should have gone to a different workshop one workshop was too basic for me and the other one did not make any impact on me.

Other than that, it was a great.  Thanks Tony for the free ticket! It was an amazing experience.

LeanCoffee style online meetup : Experience report

My first LeanCofee experience was with TestBash in 2015. It was before the conference start and I was very excited about the concept because it gives everyone a voice.

I wanted to introduce this to my company but was not able to do it for a while because I was looking for ways to do it online as most teams we have are distributed.

Leancoffeetable tool was introduced to me by the weekend testing group. It is not the most advance tool but it does the job. I trailed it by myself several times before introducing it to wider group.

We have a QA chapter in the company and I wanted to introduce LeanCoffee to them just because only few people raise their ideas. The rest are not actively participate because either they are not interested or they do not know how to contribute. However, I believe everyone have their unique experience which worth sharing.

The introduction went well and people wanted to try it out. So we dedicated a one QA chapter session for LeanCofee.

First, we thought we will do the leancoffee with four small groups and then feedback to the chapter but we had issues with number of people who wanted to join the chapter itself. So finally a one big LeanCofee session online, facilitated by me.

We got participants from differently businesses across company and from different geographical locations. In a normal day in the chapter, someone will do a demo or a presentation about a new tool or practice so this time it was time to share. We heard voices we have not heard before. Current issues the testers face in their own projects and want to know how others will react. What to do? Seeking information that we thought everyone is aware but not.

Meanwhile the discussions I have created a mind map for each point as well. This shared later as the meeting notes / summary.

Topics discussed,

  • Can developers help with testing in scrum?
  • How to get developers to do more unit testing?
  • How to plan testing when there is no documentation?
  • How to encourage testing community to engage more in RBI?
  • What value QA chapter add?

1.5hrs passed quickly. There were number of issues we have not addressed due to timing constraints. Nevertheless, we achieved a lot.

Feedback was fantastic. For me, it was a great experience. People share their ideas and experience to others who need help is what a chapter should be. That is what we achieved.

Most of all they want to do the chapter in a LeanCofee style from now and that I call as success…!

Recreate Building Quality in With Distributed Teams

After attending an exciting and educational workshop in Brighton (read more), Steve (@sjwatsonuk) and I decided that, we should recreate the workshop for our colleagues in Reed Business. I am very grateful to Lisa (@lisacrispin) and Abby (@a_bangser) who not only helped us with sharing all materials but with plenty of encouragement as well.

Since we are a big organisation with many different projects, we thought to stick to the projects that we are in as the pilot. We also included members from a team who deals with internal clients as well. The presentation tweaked but the rest of the workshop was as it was originally.

The teams were well mixed up and distributed over different floors (we were not able to book the rooms in the same floor). We took the liberty to mix and match people and that they work with majority of people that they do not know than the number of people they know.

We got two excellent and exciting helpers as well. Saima Poorghobad and Michael Lopez (@lopezma) was continue to support us by showing thing that we have not noticed. Fantastic!

All started well on the workshop. Steve and I had a plan but not rehearsed a thing. Therefore, we thought we would improvise as things go. We got people to talk. They came up with the issues that they face with working with distributed teams. Everyone was facing the same issues such as communication, culture, language etc. The examples we gave related to each business. We also mentioned the internal teams that support different projects that have a different level of distributed team challenge, which normally overlooked.

Then two teams sent away to different rooms with their tools. Straight away communication issues bubbled up. Lync was not working properly. Sound quality not there, video not working.

In the team I looked after as the Product Owner (PO), rushed to get in to work without even looking at the schedule. They wanted to get things done. Therefore, the inception and planning sessions were almost wasted. Many assumptions made. They did not ask me the right questions in the beginning until I clearly said I am not happy with the work they done. Offshore was asking what my favourite colour was than asking the right questions. Then they all started asking what my requirement is for each individual piece of work than one person dedicated for that – because of not planning the session and not assigning roles. Offshore team tried to gather the requirement with the work that they assigned but it was harder. Therefore, Lots of frustration! Time pressure! People running up and down! It was chaos!

In the retroactive it was highlighted that product owner did not have any bandwidth to answer all questions. I hinted saying I would be happy if one person talk to me than all. It was fascinating how teams forget the basic roles under pressure.

Another thing I observed was that the offshore team were trying their best to get the attention from the onsite team but they all busy either talking to me or colouring away. The offshore contact had to talk very loud several times and to shout to get the attention. Also later, I have to know that they were there with less or no work for most of the second sprint.

Everyone came back together and discussed the issues that each team faced. Offshore teams were frustrated and was very vocal about the whole thing. Then we decided to give additional 5 minutes to the teams to decide how they want to do the next sprint from the challenges they have/had. That was something Steve and I came up at the time so the people can learn the importance of planning and communication.

There were team members who wanted to talk to me and gather requirements while the planning, share information and retrospective sessions. This shows how people want to get on with their work than making sure they work as a team and achieve a common objective. Alternatively, let the others do the communication while these individuals busy with the ball rolling. Either way it was not helping the team.

The third sprint was a success. Steve and I took 2 minutes holiday and done a change of mind on a requirement. Teams did not seems to mind it at all. The requirements gathered for most of the work so they were caring out the work. How great is that!

Later we talked about the culture differences a bit more. I talked with my personal experience. As I speak about how other side of the table might be thinking I saw some eyebrow raises, nodes, note taking, and look of surprise. I might have invoked some thinking and awareness.

At the end, there was real light bulb moments in most people on how to do things differently. We asked what they would do differently and things like make sure communication issues (technical, non-technical) resolve sooner than later, involve product owner with offshore discussions, gather / clarify requirements early, make sure the offshore see the bigger picture and be more understanding are some of the things came out.

Well, all workshops we have people who think it is a waste of time, as they know the subject better. We had couple of them and they had given us negative feedback. One response was that, that person already knew these challenges and nothing new. Well in my point of view, everyone knows the issues but how they react to solve the problems is the key.

Two negative feedback against 21 from 23 participants. I take that as success!

 

Next, we have to collate the feedback and present to a wider group and who knows we might be able to take another group of people the same journey and help them to build quality with their distributed teams…

We learned a lot how this could improve. Such as dedicate someone else to coordinate the timing, bit more descriptive in the inception, bit more organised with the rules and do some adjustments to the schedule.

You still reading? Great… Few more lines…

Finally would like to thank Steve for encouraging me to do this workshop and made me believe that I can talk in front of many people without making myself a fool. Great co-host to work with. In addition, Saima and Michael was so helpful and given us fantastic feedback. Could not ask for more enthusiastic helpers than them. We were very lucky.

In summary, it was a great experience for us and as for the participants. Looking forward to recreate the workshop and of course looking forward to learn more.

If you like to read Steve’s experience you can find it here.

Is networking important?

Recently I went to a Lean-in meeting organised by my company and the topic of the day was networking. What is networking, why it might be difficult to network as a woman and what we as woman can do? We listened to a video done by Professor Herminia Ibarra from INSEAD business school and I think what I learned is both helpful for all genders equally. Therefore, here I am with the topic networking…

Why networking important? Networks allows you to generate new ideas, get information and support, and expand influence and more impact on you and your career.

According to her study, people often not focus on having a network because you depend on get things done and move ahead with the career. Most of the time people say they do not have time to network. Of course, it takes time to build and maintain a network but the real reason people not interested to have a network is it is not a top priority as part of the day job and do not know how to build the correct network.

Most people think that networking should happen between people who just click with each other in a more spontaneous way. The risk of this that you ended up networking with people just like you. Same class, same neighborhood, same hobbies. That kind of a network does not give the diversity of information that you need to advance yourself and your career.

Another aspect she described was that we tend to network with people we know for some time resulting a close network. However, mostly the people who we do not know very well or people who we do not see very often who also called as “weak ties” are the people who help with new career opportunities. It is not that the close relationships not help you but they share the same information as you compare to the weak ties.

She was talking about three kinds of networking

  • Operational – Relationships with people at work that allow you to get today’s work done
  • Personal – Relationships of your choosing, popular you like to hang out with informally
  • Strategic – Relationships that help you envision your future, sell your ideas and get the information and resources you need (most important network for career advancement)

Great strategic networks are,

  • Broad – Connected to diverse range of people
  • Connective -Lined or bridged across people and groups that would not otherwise connect
  • Dynamic- Responsive and adaptive, growing as you grow

It is challenging, particularly for woman to build and maintain an effective network. According to her study, men’s work and social work tend to overlap whereas woman’s work and social work not overlap. That overlap keep expanding when woman have kids as then the focus is shifting to the needs of the kids and their friends and families. Woman often weight the importance of attending to a networking event with go home for the kids and attend their homework.

One of the facts she mentioned was to focus on the value you bring to the network than what the network can do for you. With that, you can raise your profile among the network and grow within. Also as a woman who have different priorities in life to start small. May be one event and focus to get the maximum out of it.

Strategies for building an effective network she described as,

  • Engage in activities both inside and outside your organisation
  • Connect through people you already know
  • Focus on and develop the value you bring to your network
  • Priority and invest in few activities – favour active over passive networking

How to go in to a conference, seminar and network? Professor Herminia advice everyone to go in to these events with a curiosity. What you could learn about the people? What could they learn about me? 

At the end of the video ,it was the time to reflect, share and discuss the topic with others relating to individual experiences.

Question: What your networks currently look like? Do you have mostly “just like me” convenience networks? Do you have valuable “weak ties” in your network?

My answer: My network is currently shaping up. I am working on it. Most of the connections I have are  “just like me” “weak ties” mix. {This is where you go “Eh?”. } Well I have connections with lots of testers (just like me) but I am not seeing them very often or talk (weak ties) because they are all over the world. I am sure some of these connections are very strong which helps my own development.

Obviously I have more to achieve. But so far i am happy about my progress. 

Question: What challenges have you faced when cultivating your networks? How might you address these challenges?

My answer: My language, my cultural differences, the fact I did not knew anyone in the UK were few of the challenges I faced.  Blogging, tweeting, contributing to discussions were some of the things I think I have done right. Ah! being confident of me, my knowledge and my experience is also helped.

So, what are you waiting for?

Think what you would like to gain from the network, think what you can give to the network, think of whom you would like to network with and plan. Then review and do the adjustments. Make sure your network grow to a strategic  network and make sure it grow with you.

Simply, Just start!

SWTC: Oracles and Heuristics

This is my take on Oracles and Heuristics that was discussed on the 3rd SWTC session.

What is a heuristic? It can be a,

  • Pattern ( That you identified from your experience)
  • Different view
  • Example
  • Way of thinking
  • Trigger
  • Past lesson guidance
  • Lab experiment
  • Method of solving a problem – fallible
  • Mental mode

 

How to test data using heuristics?

  • CRUD (Create, Read, Update, Delete)
  • Migration
  • Goldilocks
    • Too big
    • Too small
    • Just right
  • 0, 1 or many
  • STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege)
  • ETL ( Extract, Transform, Load)
  • Follow data

Mnemonics – read http://www.satisfice.com/articles/sfdpo.shtml

So what is Oracles?

Its all about “how do you know what you know”

People use the “Six honest men practice”, FEWHICCUPPS , Rule of thumb, Educational guess (mostly in estimates) and also fresh eyes to explain Oracles. 

F for functionality -> from experience / people

E for Explainable

W for world -> Environment, context of the project / products.

H for History -> history of the product or about the legacy application

I for Image -. Image of the company, image of the product and it represent

C for claims -> product specifications / artifacts, sales or marketing materials, help text, client claims such as bugs

C for comparable -> products can be compared with other similar products in the market, with the legacy application

U for Users -> the people who matter and their feedback

P for Product -> functionality, styling.

P for Purpose -> Answer to the question Why?

S for Standards -> guidelines, heuristics

 

Then it was the game time. We were supposed to determine/invent the game using oracles and heuristics. We came close to the original but it was fun.

  One thing I understood is I was using most of these techniques from my experience and lessons learned but never had a name.

Onshore , offshore and me

After the Distributed team workshop I thought I should share my personal experience as an offshore resource and an onshore resource just to add some more value to the thinking around the subject.

I left Sri Lanka in 2010 and things might have changed now. Still I believe some of the experiences are still valid. I must tell that I have not experienced everything that is mentioned here as an offshore employee. However, I did see and I did listen to others.

Following are some characteristics I have noted in many companies,

  • Offshore team is normally at the third level from the customer. Example company XYZ hire company A for their development work and company A hire company B mostly offshore company to do all or part of the work
  • The leads of the project mostly communicate with the customer. As of above example it can be the Company ABC or Company A. If the team have questions that needs to go through the team leads
  • Estimations done by the project management and/or team leads and there is a high possibility that the numbers are crunched to satisfy the customer
  • Offshore team mostly work on tight deadlines where late nights in the office are common. No extra pay but food and travel can claim back.
  • Innovation, change of practices needs to approve by managers who mostly say “No” mostly due time constrains. More weight is given to the time that can be invoiced than time that can be used for innovation
  • Share knowledge with care due to job insecurities
  • Most testers trained on the job. No community and less inspiration
  • Blame culture – “Who tested this and why you did not find this issue?”
  • Communication within teams are less efficient where confusion is common due to many levels of information filtering and language barrier
  • Lack of praise on a job well done.

I was discussing this subject with one of my friend, she pointed out how testers relay on Business analysts, architects, and tech leads for information. From a cultural perspective, we tend not to ask questions and let the customer speak. I think that is due to,

  • Lack of self confidence
  • Fear of asking questions
  • Fear of being judged by others
  • Lack of confidence in speaking in English
  • Do not know how to ask questions
    • Being very technical
    • Not being specific
  • Shy by nature

After migrating to England, I sat in the other side of the table as the onsite resource. Different experience with a cultural shock!

  • Work life balance. During the first month in the office, I was not sure the time I should leave. I was trained stay late. Whether there are work or not sometimes. I was amazed to see that people leave on time. Still I felt guilty to leave at 5pm and every day I stayed until 5.30pm until my manager notice this and chase me away.
  • Encouraged to ask questions. As by nature, I ask many questions. Therefore, this is fantastic. I learnt how to ask questions without going around the bush.
  • My opinions were valued and not judged. It really boosted my confidence.
  • Information availability. The team did not depend on one person. Everyone share what they know in detail
  • I was allow to go and speak to the product owner if I need to. I was encouraged to bypass all the leads if required.
  • Estimates done by the people who actually will develop the product and they are very vocal on how much they can do and not.
  • More focused on how to do things right than finish the implementation
  • Innovation is encouraged.
  • Praise on a job well done. There were few incidents where I was overwhelm by the positive feedback and tears roll out. I used to defend myself from negativity or on things, I have not done. I had difficult managers. However, when it comes to performance review I always got a balanced feedback, which encouraged me to do well.
  • Everyone was very friendly with me even though I was from a different country and having troubles with speaking English properly.

I had the opportunity to liaise with offshore assignments; we contacted the people who develop/test directly. Some of the common characteristics I saw from onshore point of view were,

  • Business analysts take lot of time to explain the requirements to the offshore team
  • The onsite development team not happy with the offshore coding standards
  • I had to explain issues in detail before the offshore team accept them
  • Offshore team not asking questions and say yes to most of the things. Have to double check whether they understood the instructions/requirements
  • Join retrospectives but not vocal

With my own experience is being a member of the onsite team is more enjoyable. I understand the product and I have direct discussions with the customers to understand the requirements and possibilities. I communicate better. Mostly I have my work life balance and I am motivated to learn more about testing.

To be fair, my onsite experience is limited to one company. I am a person who used not to expect much from the company but give all I got so I get a sense of satisfaction. Now even the small difference makes me compare my experience now and before and appreciate things ever before. Again, this is my experience and learnings and it is unique to me.

However, we are living in an era where a one team can be located in several geographical locations. There is a part to play from both onsite and offshore teams to make these assignments a success. Onsite teams needs to think about the offshore team country culture. Simple language. Describe the bigger picture. Make sure they know what their part is in the big picture than developing/testing a small jigsaw part and not forgetting the offshore. Remembering them as a part of the team. I think most onsite teams are aware and try their best. Still it is best to be mindful about it. Offshore team needs to voice up. Ask questions and be involve with the onsite team. Try to avoid information filtering by involving the team in discussions.

I am more bias to onsite teams now. I think/believe/hope offshore team experiences are far better from what I remember.

Again, this is my view on both worlds. Yours might be different…

SWTC: Testing requirements 

The last session of software testing clinic focused on how to test requirements. Session conducted by Mark (@2bittester), Dan (@DanAshby04) and Alan (@alan_parkinson).

We discussed how ambiguous requirements could be and the importance of requirements be detailed and transparent. Requirements can be interpreted differently by each individuals experience and views which can result the wrong outcome. Alan hosted a game to illustrate this.

He asked everyone to pair up and then decide who the developer is and who the product owner is. Then all who volunteer as developer sent out where they cannot hear or see the rest. Alan gave the product owners a picture, which more like modern art and a blank paper. He asked us to describe the picture for the developer where they can draw it. Yes, some tried to draw the picture as instructions or prototype but it not allowed. We had given 5 minutes to use words to describe the picture.  It was hard. The picture I got seems to be easy to describe compare to some pictures others got!

Then we were sent out with the picture and leaving the notes. Developers came in. They had 5 minutes to draw what described. Well we who were outside could see how confused they are. Then we went in and started comparing the pictures. There were laughter, complains, questions… It was loud. Perfect example to explain why your explanations to be detailed and not let any room for ambiguity or assumptions.

You can see below the original picture, detail description and then the output. Does not matter how much I have described the picture it had not thought from the other person’s point of view resulting confusion and wrong output.

 

Behaviour driven development (BDD) encourage everyone to reduce the ambiguity as it encourage communication. It is all about collaboration and conversation. There are many ways of understanding the requirements such as,

  • Asking questions
  • Drawing the solution / user journey on paper /whiteboard
  • Asking the value of the requirement
  • By generating mind maps , feature files in BDD and also acceptance criteria
  • Gather the 3 amigos for formal/informal discussions

Sometimes we do three amigo discussions without realising or enforcing. For an example when a developer have a question and they go to the business analyst to clarify. Test analyst hear the discussion and join in. Sometimes it then taken to the product owner. Alternatively, have a discussion at the watercooler. We all practice it knowingly or unknowingly.

However, always have to remember to,

  • Have the conversation
  • Capture the conversation
  • Implement the conversation

Is the acceptance criteria same as Given/When/Then? It is not! Acceptance criteria is business rules. Business rules could written in,

  • High level points
  • Given/When/Then format to explain with examples

What we must try is to understand the business rules so the implementation is valid.

Dan asked us to test the following requirement where Mark act as the product owner answering all the questions. He actually did a good job making us feel frustrated with his answers to some questions. So the requirement as follow.

req

All the questions everyone asked written in mind map format. The groups were What? Where? When? Who? Why? and How?

Then the practical session began. Ioana (@ioanasaysgo) as the mentor she had to come up with a requirement where we have to ask questions to clarify the requirement.  Questions were asked What? Where? When? Who? Why? and How? method. The discussion result generating visuals and understanding the requirement is complicated.

We also discussed about clarify assumptions, review requirements before develop and story mapping.

Session ended with Tony’s (@tonybruce77) motto.

Apart from my train got cancelled half way and resulting me go home late in the night, it was a fantastic day. Until next time…