Requirements keep changing. What to do?

One of the common complaints by testers is that the requirements keep changing and they have to rework their testing efforts. I want to highlight my thoughts around the changing requirements scenario.

• Work with the team, understand why the requirements are changing and try to be involved in all the discussions
• Test smarter
• Analyze requirements better

Tips to analyze Requirements better

Product Coverage Outline - Huib Schoots

Leia Mais…

Focus on the process, not just the outcomes

We live and die by our habits.

When everything goes for a toss, we humans go back to muscle memory and what we have been doing for years. Thinking about testing, I wanted to see what those habits could be to be a sharp tester.

I tried to list out my habits and open up a discussion about your habits:

Organized Work Desk and Bag
I can close my eyes and find out my things. I know that the bottle is to my right. The charger is to the left. The book and pen are at the top right and the phone is at the bottom left. When they go into a bag, the earphones go to the first section, laptop and charger to the last section. Books, pen, mobile charger to the middle section. This helps me avoid searching for things in multiple places. The habit to note is that after using, I consciously put back the things in the same place.

Remembering and Using Shortcuts
As and when I use any application and especially if it is something that I would use often, then I note the shortcut for that feature. I immediately try out the shortcut - one to validate and two to get my muscles used to it. 
Ex: I use Mac and to format text I copied from any app, I first paste it in Spotlight and then paste to the destination app.
The order of shortcuts are
Command + C = Copy
Command + Space = Open Spotlight
Command + V = Paste
Command + A = Select All 
Command + C = Copy
Esc = To clear the text
Esc = To close Spotlight

All of these happen so quickly that you wouldn't even realise that I pressed so many keys. You might wonder how many seconds I would save by such actions. Multiply by so many applications and the number of times I would use those apps. 

Collecting Fieldstones
Any fieldstone (anything you feel is interesting and can be of help later) is collected and organised for later use. There are multiple groups in WhatsApp created for this purpose. On Twitter - they are bookmarked and they are also revisited, thanks to Bookmark of the day chrome extension. Link: https://chrome.google.com/webstore/detail/bookmarkoftheday/jldlnlkjghmljkcbdebeebbafjgdmllc

Routine websites
You want to visit certain websites daily to get information? Make a list and visit them - batch them. For me the list is Twitter, LinkedIn, Espncricinfo, Discord and Telegram. I do try to play the guess the number game daily on TTT discord.

Online Timer
I like the simple timer here: https://www.google.com/search?q=online+timer I have been using it to write blogs, articles and the timeboxed pressure is helping me get things done.

Laptop Stand
A very recent and late investment has been the laptop stand to ensure the display is at eye level
Link: https://www.amazon.in/gp/product/B08R78CSZ5

Modeling any application
The first task is to keep the book and pen handy for any quick notes. I model any application by trying to use it in a systematic manner. Sometimes, the output is a feature map, sometimes it is an excel sheet or just notes in a notebook. What matters is the thought process and not necessarily the end result. Later, I polish the deliverable in a way that it is presentable.

Test Data
Most of the times, the fieldstones come handy here or the groups of testers who help me. Either a tool is used to generate the data or the risk is highlighted. One of the other activities that is associated with test data generation is understanding of the domain. For example, Blood Pressure of a human can have numbers field but it doesn't mean that it can take any number of digits as an input. It also doesn't mean that I will not try entering large digits. Knowing what is acceptable, within limits and what is not is an important skill in testing software.

Using Resources
Why put in extra effort when you can also take help of existing resources.
Are you aware of 
Heuristic Test Strategy Model: https://www.satisfice.com/download/heuristic-test-strategy-model
Context Free Questions: https://www.developsense.com/blog/2010/11/context-free-questions-for-testing/
77 Test Idea Triggers: https://www.thetesteye.com/presentations/REdgren_77TestIdeaTriggers.pdf
Ultimate Productivity Tool: https://leanpub.com/productivitytoolkit
Test Heuristics Cheat Sheet: https://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf

Connect with the team members
Your connect with the team members should never be just for asking help. Ensure that you have a good relationship even before you ask for help. See how you can add value to them. Thank them whenever you get a chance. 

Organized Folders
These also help a lot, especially if you deal with multiple accounts, files, folders which is a given in IT industry. 

What are your habits and muscle memories that you would like to share?

Leia Mais…

The fundamentals have gone for a toss

 25 Fundamental Mantras for Good Testing

1. Why are you testing - Know it
2. Ask it if you don't know it
3. Confirm it if you are not sure about it
4. Test it out before believing anything
5. Listen to everyone but you take the final decision
6. Save as soon as you see it
7. Try for Autosave wherever possible
8. Take backups
9. Pay attention to the Context
10. Pincode can have letters, names can have special characters. Study the domain well
11. Document well, read documentation well
12. Write clearly, Think deeply, Read widely
13. Use tools wherever it helps
14. Know limitation of tools
15. Have a large network of friends and fieldstones
16. Learn to connect the dots across fields
17. If you can model well, you can test well
18. Know mnemonics and heuristics
19. Pay attention to keywords - always, never, must, should, obvious
20. Learn Safety Language
21. Keep collecting fieldstones
22. Start recording and then testing. Never waste time unless it is part of a test
23. There is no one good way of testing. 
24. Testers can get bored easily if you keep doing mundane stuff. Add variety to your questions, ideas, routines.
25. There is already a lot of work done by the community. Learn to search well.
26. Organize well.

Leia Mais…

Can you convert art to algorithms?

In a series of experiments, I tried my hand at a toy piano. 

The first song was easy - Hot cross buns... I and Moganesh mastered it in a few minutes. Then, I wanted to try out "Happy Birthday to you". It was a little tough and Abi took up the challenge, learned it soon enough. I and Moganesh were happy with Hot cross buns tune (Lazy guys).

Then, I realized that there are many more such songs that can be played on the piano. So, the hunt began for the song to be learned. Remember that it is a toy piano and not the actual piano shown in the YouTube videos.

Think of this toy piano as a model of the actual piano and the mapping of the keys had to be done accordingly. The fun of learning from the YouTube video started. Copying every step, the configuration was setup. Instead of the notes, they were translated to numbers and I had to press the key corresponding to the number. 

Here is the image highlighting the order of keys. There were multiple lines and each line had its own order of keys. So, you see two strips of paper one above the other. Later, I realized that there were few keys which had to be pressed and I had to attach extra bit of paper to accommodate those keys.

With all that done, the output was decent, if not great.

Can you guess the song?

After this experiment, I couldn't help think how testing is treated like the above experiment.

If you can run a set of test cases, is that testing? Yes, it helps you confirm few things just like it helps play a tune to an extent.

Can someone finding few bugs or automating few test cases claim to be a tester?

Testing is much more than test cases or automation. If you saw what I did, I also played a tune within minutes but ask me anything around the tune or change few parameters, I will be exposed. Same is the case with many testers who claim to know testing just because they saw early success and are able to replicate certain steps again and again.

Testing is much more than bug hunting or automation. It reminds me of this post I wrote few years ago:

If you want to sharpen your skills in testing software and mindset, I am happy to engage you in exercises and feedback. Email me at ajay184f@gmail.com 

Till then, it is fun to play around but if you want to master something, work hard. 

Leia Mais…

Testing Mistakes that might be hard to spot

Testing Mistakes that might be hard to spot

Hundreds of test cases but not understanding the business use case
Unless you test the main use case, your 100s of test cases add no value. Do not go by numbers alone. Ask what those test cases cover. Is there a test case for every variation of test data and hence the inflated number? Even with the variation in test data, is it within the same equivalence class? Ask deeper questions.

Automating everyday but no one uses it
We must be doing good because our automation % is increasing. Do not fall for the trap. Again, ask the question - why are we automating, who is using it, how frequently? 
Check out the costs of automation.

Attributing a missed bug to lack of test case
Many teams add a test case as soon as a bug is missed. If your testing is 100% relying on test cases (which cannot be, even if you claim otherwise), the general tendency is to add a test case as soon as a bug is missed. How about asking the questions:
- Was it expected?
- Was it a known bug?
- Was it a result of the strategy used?
- What else could be missed?
- How will we capture those bugs?
- Why did these bugs come in the first place?
- Was there a possibility of catching them earlier - What would be the trade-off?

We will test everything every time
We can get into this situation if we don't understand the overall application model in depth. Agreed that there might be cases where every case is critical and thoroughly tested every time. Other than that, why not optimize, go through the impact analysis, analyze better?
Have you heard of RCRCRC mnemonic by Karen N Johnson? There are more here: https://www.qualityperspectives.ca/resources/#mnemonics

One dimensional coverage
Quality being multi-dimensional, it makes sense to think on all the perspectives and stakeholders. One shouldn't need a separate nudge to cover performance, security, accessibility, learnability, usability, compatibility and so on along with functionality. 

Incorrect usage of testing techniques
When was the last time you consciously thought about a testing technique while testing? Many are not even aware of testing techniques, forget about using them. Without knowing the techniques, either an incorrect usage or not using them is hard to find. 

How many of the above are you guilty of committing or ignoring?

Leia Mais…

Learn Testing in 20 days - Response turned to post

Thank you, all for the kind words.

This blog post is a comment turned to a blog post.

Original Post: https://www.linkedin.com/feed/update/urn:li:activity:6887744032022372352/

Are there useful resources in the collection?

Yes.

Can it be better?

Yes

Do they need to be completed in 20 days?

Maybe not

Why did you put it as 20 days?

Thanks for asking. A short story...

When I saw the post Does this seem like a scam to anyone? Thinking of doing it in March and discussed with Rahul, we thought - we don't want to say yes/no to Codemify without knowing what they do.

Instead, what if we suggest Alexandrea Pacheco, materials (learning, practice) for 20 days (days left till March) and then let Alexandrea Pacheco decide what they want to do.

Can we complete any of the resources in 20 days?

20 days (20 * 24hrs :D - yes!

Again, completion is not THE end goal.

We all know testing is continuous learning, exploring, an information gathering activity. Here is the proof. Hours after that video was made, I had my hands on this book - Tech Simplified for PMs & Entrepreneurs by Deepak Singh

Such a brilliant book, I would recommend this book as the first book even before Explore It.

So, thank you all for your comments, suggestions, feedback. Much appreciated.

Will we talk about automation so early in their career?

My personal take: Not really. Introduce them to concepts and let them dive deep once they understand what we do, why we do and let them suggest if there can be tools to help us save time, energy and do at scale.

Leia Mais…

Part 1: Shout-out to TAU, BBST

 

This is a shout-out to Test Automation University and the Learning Paths. While there are many courses, trainers on YouTube on automation, this one I loved the most.

The next one is the evergreen BBST (Black Box Software Testing). This one helps you get the fundamentals right and the references, additional reading - all of them have value. Is it outdated - NOT really.

If you have not visited TAU or BBST websites till now, do check them out. If you have better alternatives, do suggest. I will be happy to learn. Hope to add more such learning opportunities in the coming weeks.

Leia Mais…

Few Chrome browser extensions

 

And more at Ultimate Productivity Toolkit...

Link: https://leanpub.com/productivitytoolkit

Leia Mais…

Sachin's 241* and Discipline in software testing

Three days in 2004, the Master Blaster demonstrated what is considered one of his best innings.

Those who follow cricket, know it. 

For those who don't, here is a brief:
"Cover drive" is a type of shot played by a batter and Sachin's cover drive was an important shot in his range of shots. In this innings, Sachin did not play a single cover drive. Imagine if you are suddenly asked to not use your thumb and index finger while typing. How difficult it would be? And you still managed to type out an entire book.

That was the kind of discipline displayed by Sachin Tendulkar in this innings. 

Now think of software testing and the various ways in which we are tied to a certain habit, tool, behavior, approach.

People:

Are we so comfortable working with certain people that we will struggle a lot when we switch teams?

I do understand the bonding aspect within good teams. At the end of the day, it is very rare that there are teams which work with the same members all the time. How are we preparing for it?

Thinking systems, processes, checklists? Think of the tasks that you do and how you do it. Is there a set pattern to it? Are you aware and well versed with the alternatives?

A handy guide to jiggle your thought process is here - What Do Software Testers Do? by Ministry of Testing

Process and Approach:

How attached are you to a specific process? Suddenly something changes in the process - how quickly can you adapt?

Tools:

Do you have favorite tools? What if they suddenly disappear? Do you have backups?

I felt handicapped for sometime when Jing, TestBuddy decided to move on.

Start browsing and using Ultimate Productivity Toolkit sponsored by TestProject and The Test Tribe to start with.

Data and Domain:

Are you using the same data, relying on the same source and adding minor variations? Where are your new sources? You could try out five new sources and still stick to the old one. By the way, if you are looking at the next weekend testing session, we are targeting Game Testing on Mobile Apps. 

Details here: https://weekendtesting.com/?p=4680 See you there.

When was the last time you tried something new? 

Unless we try, how will we know our potential and areas to improve?

The key takeaway I want to leave you with is:
Process, Tools, Approaches all help. THE key is a nice combo of Skill, Discipline and Practice.
Next time you feel too attached to anything in software testing or life in general, remember 241*

Leia Mais…

Navy SEALS and Software Projects

I woke up to Inc's tweet - https://twitter.com/Inc/status/1477803901986430977 titled "Navy SEALs use this 7-step process to achieve any goal. You can too."

Anything related to the military excites me like a kid gets excited with the latest gadgets.
I nodded multiple times as I read the above article and it struck me that the same principles apply well with software/any project too.

1. Ask clarifying questions
2. Identify all your resources
3. Clarify roles and responsibilities
4. Focus relentlessly on your goal
5. Think through all possible contingencies
6. Train until you're stress-proof
7. After-action review

Leia Mais…

Cost Time Value Risk

 It has been more than 15 years since I first started testing software. From the first software I tested to the last client interaction I had, few points have not changed at all.

• If it can be done quicker, people want it to be done quicker
• If it can be done at a lower cost, people want it to be done at a low cost
• If you can gain more value, people want you to work towards gaining that additional value
• If you can reduce the risk, people want you to reduce the risk. 

Think of these as four points on the circumference of a circle. It is slightly difficult to keep all four at the maximum length from the centre. You increase any one, the other three take a hit. 

Welcome to the interesting world of software testing :)

Let us dive a bit into the four points and how software testers can try balancing the four points near maximum most of the times.

If you are thinking if all four are equally important or is there a prioritised list, good question! You are thinking like a good software tester. My answer is - No, there is no one standard list. Based on the context, the priority might change. At the same time, all four are important and the margin between each is minimal.

Are people okay with a software that is too costly to build, takes a lot (I know a lot compared to what) of time, doesn't give as much value as possible, doesn't cover all the risks known? A BIG NO.

Are people okay with a software that takes reasonable cost, time, value and covers reasonable risk? Maybe Yes, Maybe No.

What is reasonable is a topic for some other day. 

Back to the four points and how software testers can balance:

Cost

As software testing is an information gathering activity and we don't have infinite time available, we should be conscious of the cost to the project every second. Every action we take or we don't take has a cost associated with it. Keeping the environment up also has a cost associated with it - relate it to the cloud services and the charges per minute of usage.

As testers, can we /try/ to be conscious of the following costs:

- cost of software used to test the software

- cost of people's time utilised for the project

- cost of repeating an action because we forgot to make a note of what was the response of the action first time

- cost of delayed action

- cost of incorrect action

- cost of not communicating our expectations 

- cost of not listening

- cost of not asking enough questions

- cost of missing the use case

- cost of brooding over a past mistake ( I remember the slip fielder in cricket who has to be focused and ready for the next ball even if they missed a easy one the last ball)

- cost of not using the right tools

- cost of using a tool because we have the tool

- cost of being in meetings even though you are not contributing

- cost of using the incorrect medium for communication

- cost of making people wait in meetings 

- cost of jumping in to test without bothering to understand the why behind the software and/or the testing

- cost of not venturing into the unknown early

Is there a specific order in which the costs need to be thought of? No, not really. You can get better with experience, if you pay attention to all the experiences. 

Time

Somewhere all of Cost, Time, Value, Risk are so much related to each other that you can have the same questions and replace one of the four words with the other three and it would still make sense.

Ex: Time lost because something was not done right the first time (when there was the chance to do it right first time)

Maybe the following mind map will help you think about 
Cost: What is the cost of this action?
Time: What is the time needed to do this action? Can it be done quicker?
Value: What is the value of this action? Is there a better way to do it to get more value?

Risk: What is the risk of this action? What is the risk of NOT doing this action? 

I used to think on the lines of Cost, Time, Value and Michael Bolton helped me realize the importance of considering Risk too in my thought process. 

Leia Mais…

Time for a new year post?

Everywhere there is New Year Celebrations going on. I am happy for them. I was thinking how would a tester approach a new year...If you have a computer and internet connection, you can do wonders. 

Learn about your company
What does your company do?
Since when?
For whom?
Who are your competitors?
Future plans?
What does your company avoid?
How much do you know about the management and other teams?
What are the problems your company is facing?
Who are your customers? 
What are their top use cases?

Learn about the industry
What is the industry your company is into?
What is the industry your customers are into?
What are the industry trends?
How much do you know about the history of the industry?
What problems does the industry face in general?
How have other industries solved similar problems?

Learn about your craft
What are the fundamentals?
What are the trends and the history?
If there is a topic, are there books, websites, articles, courses, workshops on it? Go through them.
Talk to the practitioners. Don't stop with the fundamental questions. Do your homework, show them your hard work and approach with specific questions.

Practice your skills
Pick up any skill that you think you want to improve and practice. Take feedback and implement the feedback. 
Understand that there are types of skills and a lot of them too.
- Problem Solving
- Learning
- Testing (Questioning, Test data generation, Using the right tools for the context, Modelling an application, Foundations, Bug Advocacy, Test Design and more like the ones mentioned in WHOSE (WorksHop for Self-Education in Software Testing)
- Pick up any session from Weekend Testing, practice and compare with others' approach.

Read Books
There are hundreds of them listed here: https://www.huibschoots.nl/wordpress/?p=1361 by Huib Schoots

Watch videos of conference/meetup talks on YouTube. Check out the list of conferences here - https://testingconferences.org/ maintained by Chris Kenst.

Participate in contests and community activities. There are many. Check out My Testing Dreams which has references to multiple such platforms.

Make new friends and stay in touch with old friends. Check out Coffeemug.ai

In short, LIVE.

Be Happy for what you have.
Learn more for growth and new opportunities
Take care of health as it is difficult to deliver at 30% energy :)
Say no to things that take you away from your goals
Think long term, start now with short term goals.
Experience the moments.

http://www.testingreferences.com/testingtimeline.php

Leia Mais…

The game of right questions

You always say that testing is all about asking questions. 

How do I know if I am asking the right questions?

Many testers have asked me the above question. Recently in my 1-1 coaching too, this question was raised. I thought it is now time for writing the detailed answer. 

Testing is all about asking questions about the product and evaluating the answers to see if there is a problem or not. Testing is also a sampling activity. Due to the limited amount of time, effort, it will be great if the right questions are asked early.  The problem comes when we need to figure out which are the right questions and which are not. It is similar to asking how do I find the critical bugs first compared to the minor ones. The answer to both the questions is similar - CONTEXT.

The more we know about the Context, our questions and our test ideas have a greater chance of being more pointed and useful. Let us work through an example. 

Let us consider two systems at work.

A web application that acts as the dashboard for the temple administration to view the darshan slots and count of devotees. Mobile application for the devotees to book the slots for the darshan. 

Though we can start from anywhere, I would like to focus on the below questions for a start:

Mission: 

Why are we testing? 

Is it a new release or upgrade? 

Based on the answers, your questions should change. 

If it is a new release, more focus is on what the customer has been promised. 

If it is an upgrade, the things that are already released should not break at any cost. 

The focus shifts drastically at just one answer. 

Deadline: 

How much time do we have for the release? 

How much time do we have for the testing? 

Is the development complete or still in progress? 

Users/Customers: 

Who are existing customers? 

Who will be our target customers? 

In this case, will the temple board be our first customer or individual temples manage the website on their own? 

Will devotees be only the senior citizens or will the apps be managed by agents who will help the devotees do the slot booking?

Key Features: 

Is there an existing list of features, documented in any form (Design docs, Code, Requirement documents)? 

Can we use the application to learn about the features? 

Are there test ids available?

Then start thinking about the four components of a test

Configuration

Which platforms will the applications support?

Supported OS Versions? 

Which are supposed to be supported?
How much of load can we expect? 

Which other components are in play?

How are the website and the mobile app connected? 

How frequently or how soon the data is synced?

Any specific time when the load of booking slots will be high?

Are there backup systems?

Where is the data saved? For how long?

How will we know if any of the systems go down? Is the scenario handled?

How is the temple onboarded?

How are the users onboarded?

Which other systems will take the load (SMS, notifications)?

Operation:

How would one book the slot?

How many slots can be booked in one shot?

How quickly can the slots be booked?

How long is the session active?

Any other modes other than online mode? (SMS?)

What about cancellations?

Is there a hold period?

Observation:

What happens to the UI before, during, after booking?

What gets printed in the logs?

What gets stored temporarily and permanently in the DB?

Are there other mediums of communication (SMS, Notifications, Emails)

Any download options (thereby invoking other systems and applications) of tickets?

Error messages and information messages throughout the booking process?

Evaluation:

What is the oracle here - the requirement document? the product owner? the product? similar products? user expectations?

How do we know that whatever we see on the dashboard is right?

Should we trust the website or app or something else?

Now, which of these questions are important and which of these are not?

We don't know till we ask these and get the answers. 

Good testers will not just go through some list of questions but modify the list on the fly based on the answers to previous questions or information gained midway. 

What do you think? How to win the game of right questions?

The more we know about the application, context, the right questions will appear quickly.

Meanwhile, join me for TestFlix - https://www.thetesttribe.com/testflix-2021/ by registering with your teams.

Leia Mais…

A growing problem to be solved soon

Photo by Alex Knight on Unsplash

Somehow the current batch of testers are more inclined towards Automation, call themselves SDET / Automation engineers and look down on the role of functional tester. I am not here to stir up another debate of which term is the right term to use. My concern is somewhere else - The understanding of "testing" as a craft and focus on the "testing skills". 

 Some of the questions have no answers with this batch of testers: 

• Why do we test? (We test to automate - Yes, I was shocked on listening to this answer) 
  
  
• How do you test this product? (I will automate using - Automation is one of the activities based on the context. Don't approach testing with tools. Use tools if they help you in testing) 
  
  
• What kind of bugs have you found? (UI, Usability..) 
  
  
• When was the last time you designed your tests? (Oh, we received them from the manual or functional team and we went ahead and automated them) 

Garbage In - Garbage Out
All I can say is: Garbage in - Garbage out! I am not against automation. Automation is very useful. It helps you achieve the things that you might not be able to do without the tools. 

Without having the right test ideas, what are you going to automate? 

Won't they be incorrect or way too shallow? Think about it. 

Are the checks even valuable? Are they going to answer the questions that matter? 

So, now without your test ideas being strong, I don't understand how you can add value as a tester!

Systematic Product Modelling 

Have you seen the testers who say that they have not tested the feature and hence have no idea about the feature even though it is part of the same product they are testing? On top of it, the two features would even be interacting with each other. Why would one not want to learn about the whole product? 

• Do we even spend enough time and the right techniques to model the whole application? 
  
  
• Do we think across layers - UI, API, DB?
  
  
• Do we think about the different users - the first-timer, the legacy, just started, the one who has not updated?
  
  
• Do we understand how the data flows across features and how it gets transformed?
  
  
• Do we know the defaults?
  
  
• Do we know how the product is marketed?
  
  
• Do we know the complaints the users raise to our customer support teams?
  
  
• Without modeling the overall application, I wonder what use is the automation skill?
  
  
• Isn't it a very narrow-minded approach?
  
  
• Won't the power of automation be well used if you exactly know where to use it rather than using it at every opportunity? 

Who /also/ encourages them?
Think of all the questions that are asked in the interview. 

• How much do we focus on the fundamentals? 
  
  
• Do we jump straight to the tools?
  
  
• Do we fill up the positions even if we know that this tester is not a well-rounded tester?
  
  
• Do we give higher emphasis to automation skills?

Check out the job descriptions that are posted as well. No mention of the core skills. The tools form the majority of the JD. We can't blame the testers with such JDs.

Soon, we will get to a state where testers have no idea what testing is, the bigger picture, the multi-dimensional aspect of quality, and how one can add value. We should get away from the zone of robots with tools ready to automate anything and everything without understanding testing.

The next time you have a chance to influence any of the above three factors - "Decide what to automate", "Knowledge of the product", "Interview the testers", dive in and help the industry move ahead!

Leia Mais…

A-Z of Testing Tips: A for Awareness

Wish you all a very happy new year 2021.
Let us use the experience gained in 2020 to make the best use of 2021.

Based on the talk given at #TestFlix - https://www.thetesttribe.com/testflix/, I want to expand my eight minutes talk into a series of blog posts. 

Here is the first of such posts where I will talk about A - Awareness

Awareness

Awareness Stage

• The four stages of awareness and knowledge
  Know that you know
  Know that you don't know
  Don't know that you know
  Don't know that you don't know
  
  Where are you in these four stages w.r.t testing?
  
  
• Awareness of your time
  Many testers when test, are not even aware of what they are upto.
  Do you know how much of your time is spent on which activity in testing?
  
  
• How do you test?
  Is there a structure of how you test and most of your actions are consciously thought of?
  Do you just follow someone's instructions without even understanding the why behind the how?
  
  
• Industry trends
  Are you so behind the trends that someone who interacts with you feels that you are ages behind, especially if you are supposed to be the expert at that task?

Be super-aware of what's happening both in the industry and also when you test, work with your team members. I have seen many testers perform actions and chit chat or play games that they have absolutely zero idea of what's happening on the system. They are not testing. They are going through the motions, as they say. Don't be one of them.

If you are not aware, how will you improve?
If you don't improve, be ready to be replaced by someone who is less expensive than you :)

Application Stage:

• What's your next step?
  Once you know that you have to be aware, what will you do now?
  Do you know in which situations you need to improve? Based on that you can now focus on improving.
  
  For example, if you feel that you make a lot of mistakes in understanding the requirements, pay attention to what you do when they are being discussed. Are you really listening or waiting for your chance to speak? I know that it is not as easy as I have written in the sentence above. And that is where the practice - conscious practice - comes into the picture.
  
  Remember that if you know and you don't apply in situations which demand application, it is as good as not knowing. 
  
  
• Being more self-aware
  It comes down to habits, retrospections and the cost of mistakes. Being aware 100% of the times in 100% of the activities might be taxing. Instead pick certain high value/cost activities and practice being aware. Slowly, you might observe that you are getting better at self-awareness, till it becomes part of your muscle memory.

Growth Stage

• Did you follow-up?
  Many, almost everyone wants to improve. The first stage is to be aware that one needs to improve. The second is to take actions. The third (growth stage) is to evaluate the actions taken and the results and course correction (if needed). 
  
  I have seen many take the first two steps and then lose track because they are not tracking it. If you don't track, unless you have mastered it and made a habit part of your muscle memory, the chances are high that you might get back to old habits.
  
  Let me give one classic example here:
  When the appraisals happen, the majority promise that they will act on the feedback. The first few weeks after the appraisals, you see the changes. Then the changes disappear. To grow, one needs to be aware of the key items all the time and not just temporarily. 
  
  
• Any changes required?
  You tried few changes, you now see the results. What do you do now? Are the actions yielding the right results or do you need to do any more changes? Close the loop.

To summarise:

• Be aware of what you do
• Be aware of what's expected of you
• Do the necessary changes
• Review after performing the changes

The full talk is available here: A-Z of Testing Tips 

My other videos: YouTube Channel

Leia Mais…

Tribal QONF: Reason #2 to attend the conference

If you have not checked out my previous post - http://enjoytesting.blogspot.com/2020/05/tribal-qonf-reason-1-to-attend.html, please do.

For someone who is not aware of The Test Tribe community or The Tribal Qonf, I thought I will share a few pointers on why this is a must-attend event for any software tester.

In my last post, I highlighted the opening six speakers. In this post, I want to touch upon the next set of six speakers.

Mike Talks

https://www.linkedin.com/in/mike-talks-3423348

I know Mike for close to a decade now and met him for the first time last year at Test Leadership Congress. I love his tweets and blog posts and his books too! When I was writing my book - 50+ mistakes of my software testing career, I had my first mindmap with all the mistakes. I shared it with Mike and within minutes, he gave me feedback on how I could make new sections and club a few mistakes. He is speaking at this conference. If you want to have a small bite of Mike's talk at Test Leadership Congress, check this link - https://www.youtube.com/watch?v=P9ZWnbinAxI

Aprajita Mathur

https://www.linkedin.com/in/aprajitamathur/

Aprajita at TLC 

I met her in the Test Leadership Congress (TLC) conference. Before that, I was in the same panel discussing Leadership. I felt she is someone who is bold, would say the truth at all times with a lot of attention to details and get things done. She is working with data to fight cancer. Beat that for real-world impact. 

You can listen to her TLC talk here - https://www.youtube.com/watch?v=AlFceDqTxpc. I am looking forward to her energetic talk once again in the Tribal Qonf conference panel discussion. 

Anand Bagmar

https://www.linkedin.com/in/anandbagmar/

He has his own fan following. People consult him for his automation, mobile, analytics expertise. One thing I have always noticed is his smile when he greets people. It immediately makes the other person comfortable. He will be speaking on Testing and Automation Analytics. Looking forward to his talk. Do not miss his talk! 

Nishi Grover Garg

https://www.linkedin.com/in/nishi-g-02127aa/

From a time when she applied to Miagi Do school of testing founded by Matt Heusser to giving talks all over the world, I would say Nishi has crossed many levels with ease in a short time. If you are active on social media, you would notice a talk at a conference or a blog post or an article published in one of the reputed websites or she would have finished training to eager participants. Ever busy, ever willing to share her knowledge, she deserves more and I am happy to see her present in Tribal Qonf. 

Santhosh Tuppad

https://www.linkedin.com/in/santhosh-tuppad-338b7412/

Craziness is the new normal :)

What do I say about him? We have our birthdays in the same week and there are multiple moments where we exactly know what the other is thinking or about to tell. We have worked together for Test Maniac meetups and workshops and continue to collaborate even now. His talks always continue even after the time is up and no one complains. They just love him. I am sure some of you will buy the tickets just to listen to him and I am sure it will be worth it even this time as well.

Priyanka Halder

https://www.linkedin.com/in/phalder/

Again, I and Priyanka were in the same panel discussion at Test Leadership Congress and then we met at the conference. I have this habit of shifting tables every few hours and one such shift helped have a 15-20 mins discussion with her. Her weight loss journey and her speaking journey will motivate anyone!

After we discussed about the Decision Deck

If you are asking me, how to purchase tickets for this conference, this is the link: https://www.townscript.com/e/tribal-qonf-2020-a-virtual-conference-by-the-test-tribe-431224

I also have a small discount coupon for you - TTTQONF1 

and if you are buying more than three tickets and don't want to fill all details in the townscript form, contact me at ajay184f at gmail

See you at the conference and stay tuned for more reasons why one should attend TRIBAL QONF!

Leia Mais…