What type of a presenter are you? 

I have seen different type of presenters. From teachers to public speakers. Some were interesting and some were not. When I think more, the reason I found some sessions are interesting was not because of the content. The personality of the presenter, how they engaged with the audience, the level of detail they go into and their enthusiasm of the subject had a bigger impact.

I have experienced following styles.

  • Detailed presentation slides and short and precise explanations
  • Short and simple slides and explains the ideas in detail
  • Detailed slides and detailed explanations
  • Short and simple slides with quick and short explanations

My favourites are the type one and two. I personally try to adopt my presentations in the same manner as well.

So why I am not in favour for the rest?

When I sit down for a presentation, I would like to hear how the presenter interpret the subject matter. Slides should be a guidance or a summary of what needs to be said.

In my opinion, if there the slides are too detailed, they become reference material and people can read them on their own time. The need to listen to the presenter is minimal. There is always a chance that the audience spend time reading the slides and not paying attention to the presenter.Well everything is on the slide deck so where’s the need to listen to the same?

If the slides are short and if the presenter rushed through the slides or given minimal explanation and use higher level of technical jargons, then the audience will be lost as they might not have the subject knowledge as the presenter or follow the presenters thought process.

That’s why I think the first two styles are balanced.

When we are doing a presentation or a talk, one of the main idea is to share our thoughts with the audience. To succeed on this presenter should keep the audience engaged. Adopt to the situation and the audience does matter. Why? In that way the audience will get the maximum benefit of the presentation.

So, you are in middle of a talk and you see people dozing off. Or take their mobile phones out. what would you do? I am scared of those situations.  For me, that indicates the presentation is not going well.

You can turn these situations if you are mindful of the audience. When you are preparing for a talk you have to think how get the audience engaged with you. Sometimes the most least likely subject can be an interesting one if you prepare. Prepare yourself for unexpected situations. If you see people dozing off or not interested over what you say, you should have a plan B to change the situation. Group activities and games are some popular choices.

So, what have I learnt from reading and listening to other presenters?

  • Try to make the slide deck interesting and different.
  • Add small tasks for the audience if possible. Little exercises to explain simple rules
  • Do add humour. Warning: if you are not good at making jokes do not attempt this!!
  • Ask questions and help them to relate these to real life situations if possible. Sometimes people do not understand the theory until it is tied in to a practical example
  • Change the tone of your voice. If you sound the same tone throughout the presentation, that definitely put your audience to a meditation mode. Your voice should go up and down. Smile when you talk. That makes your voice friendly and easy. Assert facts with a stern voice. Record your talk and listen beforehand. Listen to talks you liked. Apart from the content what else you liked.

What if you are in duo presentation? Different personalities and different experiences can make the talk interesting. Or not. How can you make the talk a success?

  • Make sure you explain your style of presentation
  • Make sure you understand your partners style of presentation
  • Talk about how your styles can be joined
  • Prepare the presentation together and share slides
  • If you are changing the slides, make sure your partner knows about the change. No surprises
  • Share slides between the two and time each slide
  • Practice the presentation together at least once before
  • Listen to your partner and their ideas
  • While the presentation, show the audience that you two are together in this presentation and share the same ideas.
    • Look at each other
    • Give other their turn
    • Don’t repeat the same thing your partner explained
    • Acknowledge each other and their ideas

Most of all, remember you are in a pair presentation. If you are used to do talks alone, you have to make an extra effort to make the presentation a successful.

Remember, you have an audience because they are interested. Make sure they get the maximum out of it.

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.

The good and the bad

There are things in life you can express in few sentences than writing a detailed blog post. So here goes,

 

  • Never use the promotion as a trigger to get things done.

There was once my manager always says that if you want to get that promotion you have to do this, or remembers your promotion is depend on this every time I fall behind tasks. Was I motivated? I hated my promotion and wish I will never get in to the promotion process. When I get the promotion, I was not very excited about it.

 

  • Sarcasm is not the best to use in  an interview

On my first developer role interview, I was ask about a coding principal, which I did not know. I wanted to do well and I learned about it after the interview. When they called me for my second interview, I told the person who interviewed me that I know the answer to that question and I looked it up. He looked at me and told me “ha! YOU got to know THAT now?”… I felt humiliated. I thought he would praise me for my enthusiasm on learning what I don’t know. Something he should have done.

 

  • As a manager, you are responsible to help and motivate the staff. Not to sulk with them.

I really do not like writing performance review documents. I am not good at marketing myself or talk about things that I have done. A manager who I reported always read what I have written and say okay. No positive/negative from his point of view or tell me to improve my input. Because he did not like performance reviews as well. I lost my faith performance review process and saw it as a HR formality. Performance review is to celebrate the good performers and help the others to shine. Managers can make or break good people. Performance review is a crucial point.

 

  • Talk to people outside your team

I was a lone tester for many projects. Sometimes I questioned whether my job is worthwhile doing so. Felt monotonous and low self-esteem. I tried to fight the demons by my own and did not know from whom I should as support from. I started to expand my network. I started to meet people who share the same career as me. Who are proud to be a tester. Now I am co-hosting meetings to help those lone testers and gather the tester’s community. A safe environment to ask questions and learn. It is wonderful to see how others get advantage of it.

 

  • Learn how to read people by their body language

As a tester, I need to talk to different people. Different personalities, different power levels. There were many times I changed my tone, the description and what I say to the person while I am in the conversation according to the body language that I can understand. I am no body language expert but I can tell whether they are in a rush, interested on what I have to say, or totally in another dimension frustrated or upset. This had helped me to know when to go on details and when to retreat in a way. Therefore, I believe it is important to read the body language of the other person/s while in a conversation and change the conversation accordingly.

 

  • Share the success with wider group not only with your manager

There was a time I fully depended on my manager to spread across my success. When I success on something or come up with a new idea I only shared with my manager or a person I trusted. Simply because I was not confident enough to get questions or praise for it. Then I realise no one knew my contribution to the team. Sometimes the people shared my ideas as their own who I shared with, as I am not raising my voice. I started with low confidence but determination. People did not taken me seriously but I am happy with where I am today.

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…!

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:What is testing?

Updated with a link to Richard’s post.

Mark Winteringham (@2bittester) and Dan Ashby (@DanAshby04) had come to this wonderful idea of sharing their experience and knowledge with testers who are new and experienced. This is also a good playground for the experienced to gain mentoring skills.

I went in as a student as I think I still need to learn a lot and I was right.

Mark, Dan and Tony Bruce (@tonybruce77) discussed about what is testing. Everyone’s input went on to the board.

1

If the list is not readable the items as follow,
•    Asserting expectations
•    Ensuring quality
•    Assuring quality
•    Understanding objectives
•    Making sure it works
•    Finding / preventing bugs
•    Discovering software behavior
•    Test scripts
•    Avoiding blame
•    Analyse risks
•    Making sure product meets objectives
•    Reporting
•    Meeting requirements
•    Gatekeeping

We discussed few items from the board such as,
•    Assuring quality
Question was how we can assure quality. It is a vague task depend on the person, environment and various other facts. Quality is a responsibility of the whole team. If someone gives list of things that needs to be attain to assure the quality, still there be issues as things change.

•    Gatekeeping
Can tester be Gatekeepers? If we say No, the product release be stopped or the management decide to go ahead? If so, why they need a gatekeeper? To fingerprint if something goes wrong. All testers can do is to point the risks and let the management to take the decision.

•    Test scripts
Test scripts / Test cases can be manual or automated. Testing done only using the test scripts/cases. No. Why do we need test scripts? Mostly for the repeating tasks that can followed systematically sounds like automation. Test scripts changes with the functionality changes manual or automate. Maintenance is necessary and it is costly. If you need someone to learn the system test scripts not the right way to follow. Encourage them to do exploratory testing.

Then Mark explained how he would explain testing. He explained how testing is always stay between Expectations and Actual product whereas testers we should try to keep the gap minimal.
Unfortunately, I could not take a picture of his diagram. Sorry Mark.
Dan explained testing with the diagram below.

2

Information is in focus. Information can be about product design, product idea, requirements, processors etc. Information is the centre of all of it.

Testing is uncovering more information via exploration or investigation. Uncovering information be done by asking questions, explore requirements, explore designs, and join in with discussions. The information that are uncover will inform new test ideas to explore.

Information enable many checking activities and regression checks one of them. When new features introduce to ensure the existing is not broken.  Checks done in a script format that can followed either by a person or by an automated process. The output from checks inform the broken tests as well as it can inform what not tested as well. If we have passing checks that can prove that the information are behaving as it required.

Tony explained how information be used for decision making.

3

Information gathering will lead to experiments, learning and explorations. Results of that can be collated. This collated information helps the software intelligent. With the software intelligent the business intelligence can be supported which lead to decision making.

This can be going in loop. When business require information to make a decision same process happens again from the beginning.

So the original list of “what is testing” updated.

•    Checking
•    Learning
•    Business decision
•    Communication
•    Uncovering
•    Value to a person
•    Communicate about what we have not done!
4

Practical session taken place afterwards to go through http://www.drawastickman.com.

Richard Bradshaw (@Friendlytester) was kindly agreed to mentor 3 of us.
This site we have not seen before and had no knowledge. Therefore, we spent about 5 minutes exploring the site to understand its functionality. We came to following conclusions.

  • It’s a game
  • Works in mobile / different browsers
  • Have an app in app store
  • It is interactive
  • Navigation
  • Possible bug
  • Etc (Shame I didn’t take a photo of that list!!!!)

Richard was advising us to,

Richard had written a Mentor Experience Report and you can access the post from here.

I am sure I have missed some, as I was not fast enough to note them all.
At the end, all teams came together and discussed the learning. Following are some.

  • Don’t come to a conclusion without knowing enough information
  • Build a practice / discipline as a tester and do not change because of the project.
  • Note taking/ mind mapping
  • Go through social media to gather testing ideas
  • If you are not happy using the product so will your customers
  • Explore test ideas

So that’s a wrap! Until next time…

Test plan : Does it need to be a detailed document?

Recently one asked me does the test plan needs to be a lengthy document.

My immediate answer was “No”.

Because of the puzzled look, I continues.

Lengthy documents used mainly in projects that used the waterfall method. In Agile world, the documentation is minimal. Yes, Test planning is a very important and essential activity that everyone should do. However, it should not be a lengthy document where no one reads or no one have the time to maintain it or yet do not have time to create it in the first place. It should capture the essential functionality that effected. We can use mind maps or a simple Excel table.

Then I saw a smile…

I am a big fan of test plans. In my current gig there is one big product, there are feature implementations, and extensions that happen every year to cater new business potentials and to retain customers. We are in continuous delivery mode where releases happen every week. Yes, short turn around and very happy customer base. When the new features prioritised and up for discussion (requirement gathering or design or estimate) there is a high possibility that these features will not implement in next few weeks. Some could be in months because suddenly work priority changed. (This project structure and agile concepts usage may not agree with you but it works… It works for the project at least. So we will skip all the questions around it) .How do I keep my thoughts over the design/requirements and possible break points?

I do the test planning right after the discussions. It will cover various things such as the local the impact be, what areas will be effected from the implementation, what areas I think will effect with the changes, high level workflow  or user journey, rules that being discussed, what customer base should be effected and not etc. This will be a mind map or a simple table.

When the functionality is up for development, then these test plans help me to gather my thoughts. What my thinking was. I was practicing this for many feature implementations and it always helpful. Because these notes are simple and to the point they are useful to everyone who are involved with that piece of work. I even used few of these artifacts to look back at any time if someone come to me and ask “Hey do you know what we have done in x feature by any chance?”

I may not use the conventional test plans. However, the planning I do works very well for my current project and me. This not only help me to collect my thoughts. I try to learn from others and implement the best practices they recommend. If it works, I continue to use it. I may do adjustments to cater to the project need. Otherwise lookout for more.
It is a continuous learning process and I hope you learn something new today or I have given a success story of a method you wanted to try.

Sample:

Feature name
Tool ABC
Region affected UK, US  Initial development will be focused only for US
Browsers Default list IE7 to IE11, Latest Firefox, Latest Chrome, Latest Safari
Changes to Landing Page Template Change Feature flagged until the MVP is implemented / Navigation template ABC
Initially the content will be only enabled for US
Landing page category show as Modules instead of Categories
Sections Landing Page Logged out view About ABC box hidden
Logged in : unentitled  view About ABC box shows. (Text will be managed via content management tool)
Logged in : entitled  view About ABC box shows. (Text will be managed via EMT)
New and updated Logged out view 10 most recent articles of all articles
Logged in : unentitled  view 10 most recent articles of all articles
Logged in  : entitled  view 10 most recent articles of all articles
Content Modules 3 content module placeholders as default for all Tools
Icon New icon should displayed along side with a new colour
Search ABC tool articles should not be searchable via Main search
Local search box should be available
Search results Should return ABC articles on results
HR Learning Center refine filter should be available
Breadcrumb Breadcrumb should display on ABC tool from landing page onward to categories and articles.
Footer ABC tool should not display under Tools section
Tools Page ABC tool should not list under a defined business category
 Menu ABC tool should not list on main menu
EMT User should be able to add categories to ABC via EMT
Adding article source ABC is not MVP
Article page Only subscribers will be able to view the articles
Download feature should not be available.
S3 resources If S3 resources being mapped in to the ABC articles
Article styles The default functionality should be applied
Print article The default functionality should be applied
Subscribe form Not mentioned on initial requirements.
Request a demo form Not applicable as the functionality is for US
Feedback form Not applicable as the functionality is for US
Entitlements ABC will be an individual product
Product name : ABC_product_name
Tags Standard analytics tags should be included
Article Tags No special article tags
Google site map Should not index on Google. Sitemap should have No index, No follow to the tool

What do you think testers need to do to be taken seriously

This question had raised in Lean coffee session at the TestBash. @FriendlyTester was kind enough to share th list. Thank you for that.

As soon as I saw the topic, I thought I should collect my thoughts on it. I too have faced the challenge in every company I had been and was able to overcome it as well. I believe these are common experiences of many others but here goes.

Learn the product by asking questions

I was a software developer before back in the era where we used Visual Basic , and then I thought testing is fascinating and wanted to change my career and never looked back. Ever since when I joined new companies, role of the tester was not recognized or either recognized but not taken seriously . We testers sit at the back of the room where cool kids – the developers, architects and business analysis take the lead.
I was never happy with this. I am a person who ask questions until I understand what’s going on and do not wanted to be ignored. The first few months of a new job can be the almost crazy time period for me because I question everything. Applications and documents does not reflect the tacit knowledge the team have. For them that piece of information is just another funtion. That how it work. That function behave because of this business rule. No team realise how much tacit knowledge everyone have until a new team member and question or say I do not know about that or show you a blank face with lot’s more questions. Induction sessions may contain too much information at a given session or the sessions may be not detailed enough as you want it to be. There is always something unsaid. Therefore always ask questions. Make sure you understand the application and its hidden rules.

Learn the product exploring

I want to be the person who everyone ask questions from. Every time I go to a new project I want to learn and want to know everything around if. I want to know how code looks like, how to control the application with configs, feature flags, how database tables look like. I do not want to be in a meeting room without knowing how to question the requirements or the solution, whether the discussion is on topic or off topic, why that person asked that question. I want to be the person who have almost all the answers or the person who may translate the business requirements to technical wording and vice versa. Therefore I try to learn these things by myself. I learn more when I explore. I get to see how the application works and get the detailed understanding. Explore and expand your knowledge.

Challenge yourself
Every time if someone doubt my abilities on my skills, responsibilities and credibility I always want to prove otherwise. Example, I worked on a project about statistics and I wanted to know more about database tables other than the stored procedures given. This was questioned by the technical lead and didn’t want to give me access to the database as it was an unnecessary complicated  task that I won’t understand. I somehow got the access and explore the tables and understood how data stored in different tables, relationships and this helped me to find more issues that not only helped us on delivering a quality product it increased my credibility on the project as well.

Manage your stakeholders
Understand your stakeholders and develop a good relationship with them. They help you to understand the product from a different point of view. This always helped me in discussions as it helps me to see the bigger picture. Know how all the different components comes together is an advantage. How sales, marketing, customer support use the application and about the other supporting applications sometimes are over sighted. By talking to the stakeholders and be interested on their job role always helped me to think outside the code and its rules. This knowledge always helped me in discussions.

Get involve in requirement gathering sessions
There was a time that I see the requirements first when development completed. Testers were not part of the requirement gathering sessions and almost projects did not understand the value. When I get the piece of function to be tested that I have no knowledge of before to understand the requirement and what the functionality does I ask questions. In many occasions it was understand that requirements may be missing or mis-interpreted by the time it reach the testing. By joining the initial meetings and I was able to share my understand with the rest of the team to prevent issues before the requirement reach the implementation stage.

In summary
It is always overwhelming when team members doubt you for what you are because you are new to the project and because everyone do not know you. Always your actions makes you who you are. Go the extra mile to learn more about the project and how its being used. Reasons behind the features and why it is built under the given rules and but not otherwise. Be confident on what you know and be responsible on what you do not know. Learn and feedback as soon as possible. Help others to understand the areas that others do not know. Get in to meetings and ask questions. Explain the business reasons behind the implementation. Always stand out. Your voice will be respected.