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…