Parveen Khan

Some final thoughts from Mellody from Masterclass on why is it essential to make decisions in a timely manner and she says "If you can't decide the answer is no. If you really can't decide then do nothing and understand the implications as well'.

Here is some great advice :

Give yourself one night of sleep to sleep on it.

You won't be able to answer every question in a way that will ever allow you to have all the time that you have.

It is crucial to remember these things when in a leadership role and to understand that you are doing your best given the circumstances.

I enjoyed learning this topic on Masterclass by Mellody Hobson.

What topics are you currently exploring and where?

Another lesson from Masterclass by Mellody Hobson's where she say's - I believe people can see success and mistake it for always representing good times. It's the critical moment of failure or difficulty that actually becomes the biggest stepping stone to success. And they're actually necessary components of success.

It's so true in so many ways. When working on teams or projects we often face situations where we might not know everything we do is correct and some of it may be experiments which sometimes might fail. But those failures become the stepping stones for growth and success as you learn what doesn't work. In those moments what I usually do is to

• Write down what didn't work

• Understand why it didn't work

• Reflect on what I could do differently next time

I believe that failures or difficult situations help in learning and exposure to more experiences which helps in growth. Another great takeaway from the lesson by Mellody -

"When you're in a storm you never look up at the storm. If you look up at the storm you will fall. The only thing you do in a storm is you watch your feet so that you can figure out how to get to the next place where you need to be"

What are things that you do when you go through such experiences?

I'm currently exploring this topic on Masterclass by Mellody Hobson. She says - Strategic thinking is an important skill to have, regardless of the size of the teams or organizations we work in. It's about being pragmatic and coming up with a plan to move forward, instead of hoping things will get better.

Here are five guiding principles that she shares, which I have elaborated from a quality leadership perspective.

#1: Put others first

When making changes within teams, whether it's processes, tools, or cultural shifts, consider who will be impacted and how.

#2: Co-Leadership

Leadership doesn't mean working on your own.

Leadership can be collaboration with co-leaders to gain new perspectives and expertise, leading to more innovative and successful results.

#3: Lifelines

Get advice from your friends and mentors. Don't limit yourself to only people within your organization, but also look outside of it. Build your network so that you can get different perspectives.

#4: Hope is not a plan

Rigor. Facts. Math. According to Mellody, these are some of the key ingredients required for sound planning.

#5: Conviction

Once you’ve made a decision, you need to trust and believe in it while still remaining open to change. Having confidence in the path you’ve chosen will “inspire other people to be on that path with you.

It would be great to connect with other people who are interested in these same topics—so if any of the above resonates, feel free to reach out!

I signed up for Dickie Bush & Nicolas Cole's cohort-based course, Ship 30 for 30 in 2023. I have decided to ship 30 in 30 days again.

Here are a few reasons why:

1. Sharing my experiences

2. Building consistency

3. Growing through community

Over the next 30 days, I plan on writing about leadership lessons from Masterclasses, embedding and driving quality.

Join me on this adventure—and let me know if you have any questions or what you'd like to hear from me! I'm open to suggestions, and I'd love to know if there's a specific topic or challenge you're curious about.

I'm excited to start sharing what I know online.

30 days ago, I signed up for Dickie Bush & Nicolas Cole's cohort-based course, Ship 30 for 30.

In that time, I wrote & published 30 Atomic Essays, learned the fundamentals of Digital Writing, made friends, and started gaining clarity over what my niche might be, what topics I enjoy the most sharing and writing. It has been a very rewarding (and challenging) journey, and I am more excited than ever to keep writing online. And I will definitely continue this.

Here are the 3 biggest things writing & publishing consistently every day for 30 days taught me:

1. Building consistent habit 🔁

When I started off with this course I was not really sure if I'll be able to ship for all 30 days for various reasons, how can I find time to write eveyday 🤯 and how can I publish my thoughts publicly 🙈.

It was hard in initial days but gradually it became easier and I was able to build this consistent habit of writing on the same time everyday. Even my kids started asking me if I had done my writing for today 😂. I say it as power of building habit 💪.

2. Idea generation 💡

I learned how to think about generating ideas everyday. I started noting down all the topics on a google docs whenever something new struck on my mind or something that I always wanted to share of what I learnt but never got to do it( but I was able to do it now with these short atomic essays)

So this helped me with not sitting with a blank page staring for hours to think what I'll be writing about. I always started writing with an idea in mind 😎(no more staring at the screen 😊

3. Just press the publish button 🙌

In my past, I would rewrite and adjust anything that I would write, you know write being perfectionist 👌

Initial few days was still the same but gradually withing 3 to 5 days I lost the habit of making it look perfect and hitting the publish button was less scary than when I started off.

Out of all of these I enjoyed the entire process.

Shout out to Dickie Bush & Nicolas Cole for building this amazing course. And a huge thank you to Vernon for inspiring me to take up this course 😇

If you have been thinking about getting started writing online too, let me know. I'm happy to share more about the experience and what I learned.

“If you always do what you’ve always done, you’ll always get what you’ve always got.”

​–​ Henry Ford

This quote always reminds me of how important it is to think about getting out of comfort zone.

Any change is scary, whenever I think of trying something new my first instinct is fear very naturally. This quote reminds me that If I won't try then I will always be where I am.

🗣️ Quiet a lot of times teams don't think or care about CFR's.

They are famously known as Non-Functional Requirements and it kind of reads as "Not Important" 😬

A lot of times there are assumptions around what CFR's are and how they can be implemented.

What is cross functional requirement?

A CFR specifies the criteria that can be used to understand the operation of a system rather than its functionality.

If you are interested to get the team to think and consider CFR's then you can try doing these things :

Talk about the difference between Functional and CFR's

Many times I have seen teams not being fully aware of what exactly is the difference between functional requirements and CFR's.

The best way to help team is by sharing the knowledge and sharing the awareness of how functional and CFR's are different.

As an example :

Functional requirements specifies about what a system should be doing by looking at the acceptance criteria.

CFR specifies about the operational requirements of the feature.

Collaborate with team and stakeholders

Collaborate with the entire team and stakeholders to think and decide about the CFR's that are required and applicatble to be considered as part the current work.

It helps in coming up with what CFR's are important and remember these would always be emerging as the product evolves.

Talk about how to measure

It's not about just coming up with CFR's but also thinking about how to measure to check they have been fullfilled or implemented. Brainstorm as a team to think about this for each CFR and document it.

For example : If you thinking about security CFR then think about what should be considered and implemented. Having vulnerability scans as part of pipeline, no PII in the logs, use burpesuit to do some security checks and so on.

Remember there are many different types of CFR's and they are equally important as functional requirements. So keep bringing this up and keep advocating about it!

I have been working as a tester for 8 years now.

And in that time, I've gotten to do a lot of cool things:

• Being the first tester on the team and setting up the processes

• Growing as a tester by learning through conferences and communities

• Speaking and attending conferences to learn and network

There isn't much I would change about my journey.

If I could go back, here are a few of the mistakes I made early on—and what I would have done differently:

1. Thinking I should know everything about testing

Early in my career I used to feel so much pressure, it was not by others but by me. I would always think that I should an anwser for every question that's related to testing.

I could do differently by "being ok if I don't know anytihng". I could have just removed this thought from my mind that I should know everything about testing. And I would think of giving more thought on learning as opposed to knowing everything.

2. Testing is only my responsibility

I would always think that testing is just my responsibility and I would get so offended when the developer would talk about testing a story. This was when I joined my first job as tester in a startup.

I could do differently by involving the whole team to test and think about quality. Not just me but entire team to be taking ownership.

3. Developers role is more superior than a tester

I would always think of developers role as more superior than a tester. I would always give myself an excuse that I'm not a developer so that is the reason why they excluded me from certain meetings.

I could do differently by removing this thought of comparing two different roles as they both are valuable in their own ways. I would think of everyone as engineers who are trying to solve user's problem by building this software solution. There's no comparision between the roles as each role brings different value.

Have you heard about "flaky tests" in your team?

"Just rerun the tests and keep trying until it's green", do you hear this in your team?

What are flaky tests?

It's a test that sometimes fails, if you retry it few times it passes eventually.

Every team deals with these flaky tests differently. The problem with the flaky tests is that it becomes difficult to understand if it's failing due to a bug or if its just a flaky test.

These are the 3 small mistakes:

Mistake #1: Not trying to find the problem

When you see a red build don't just focus on turning it green by rerunning the build. Try to analyse the problem. Try to understand if the problem is in code or is it failing due to a bug. Have enough observability in your test automation that can help in finding the problem or root cause.

👉 I would recommend this course "Introduction to Observability for Test Automation" on TAU by Abby Bangser (@a_bangser)

👉 Talk by João Proença (@jrosaproenca) "Observability meets flaky test"

Mistake #2: Adding sleep or waits

Don't just add waits or sleeps in the code and keep your fingers crossed to see a green build. It would only add more flakiness to the existing flaky tests and doesnt help.

👉 Talk by João Proença (@jrosaproenca) "Should we just...delete it?"

Mistake #3: Commenting out the tests

Don't just try to comment out the tests to make the tests pass and to have a green build. Investigate further to find more information around the failure. Document the flaky test to understand how often it fails.

What common mistakes have you seen when dealing with flaky tests? Do you have any resources that you'd like to share?

Share them in the comment below 👇

When you are a solo tester on the team, even though you try hard not to but do you become a bottleneck by doing all the testing and everything else by yourself?

What can you do in such situations? 🤔

You can try taking steps to enable the team so you don't become the bottleneck and you don't end up doing everything alone. But are you thinking how is it possible if you are not a lead or manager?

You don't have to be one to enable the team. You can use the following 4 things and build your influence that can help in driving change.

1. Build Your Allies 🫱‍🫲

Get people invested and advocate for yourself. Build that trust so people can believe in you. You dont have to do everything on your own so build those allies.

2. Use storytelling 📖

Be a storyteller when you sharing or proposing new ideas.

• What is the concern?

• Why is it worth discussing?

• How do you plan to solve this?

• What examples or data do you have to show?

3. Build your visibility 🔎

You can build internal credibility by having external visibility. By sharing your external work like blogs that you might have written, conference speaking or anything else that you might have done , build your visibility. If you are like me you might have constant thoughts of feeling like bragging about yourself but if you don't talk about yourself who else would 😉

4. Use feedback as a tool 🔁

Giving and recieving feedback is such an helpful tool that can be used as part of your growth. And also to know the things that you have been trying on team if they are being valuable and helpful to the team. It's about asking the right questions to get constructive feedback so you can find out what worked and what dint work so you can gain confidence, motivation and improvise your approach.

These are few of the things that you can try to enable the team so it can help you drive different experiments around testing and quality. I'll expand on this in the next post.

Accessibility is one of the Cross Functional Requirement(CFR), which I have mostly experienced as being taken care by a 3rd party service or its treated as 'not a must have'.

Ofcourse there are a lot of teams and companies that make accessibility as a part of feature develpment.

From the teams that I have worked on where we followed these 5 simple practices within our teams to make accessiblity practices as part of our ways of working :

1. Test with a screen reader

Screen readers read the text displayed on the website. You can use voice over tools to test if it reads the text and alt text on images if added. I use VoiceOver on Mac to test using screenreader.

2. Check the colour contrast

There are many people who experience colour very differently for example red/green colour blindless. Being red/green colour blind means people with it can easliy confuse any colours which has some red or green as part of the whole colour and so on.

3. Test using only keyboard

Testing by using only keyboard to input, navigate and for button clicks. Many users with motor disabilities will have issues using mouse so they rely on keyboard.

4. Automate accessibility checks

Automated testing is a way to find obvious errors but not enough to cover everything. There are many different tools like Axe-core, Lighthouse, Pa11y that can be integrated as part of pipeline.

5. Test using different user personas

Build different personas with different abilities and goals so you can use this while testing for accessbility.

These are few ways that can help teams to encorporate accessibility testing as part of the ways of working. And accessiblity is a shared responsibility, a teams responsibility.

I have joined a lot of different slack groups over the period of time.

Why did I join these slack groups?

❇️ Most of the time I'm an observer on these slack groups and sometimes I do contribut as well, I learn so much from different people sharing their challenges and by reading the thread responses from so many different people and perspectives.

❇️ Some of these slack groups have virtual coffee ☕ which means you'll be automatically paired with another person to set up a call with each other. It's like virtual pairings that happen automatically every week or every month.

These are the 3 slack groups that I enjoy mostly being part of :

1. Women In Testing

This was the first ever slack group I joined, I have learnt so much from different channels conversations, got connected with amazing testers and a place where I feel so happy and comfortable to brag about my achievements.

2. Ministry of Testing

Since I have joined this group I have been part of so many virtual coffees and especially during pandemic while working from home it was such a blessing to be able to connect with other testers and share our knowledge, challenges or experiments. And ofcourse so many variety of channels where there's so many active discussions to learn from.

3. Aspiring Women Speakers

I joined this recently couple of years ago(I know it's definitely not recently 😁) and it's been so helpful where you can get help is anyone is looking to become an aspiring speaker. I got connected to so many amazing people on this group and Helen Scott is one them who helped me a lot during my keynote journey ❤️. I also come across so many new events and conferences through this group.

Are you part of any slack group or communities that you'd like to share? Share it in the comments below 👇

What is that 1 tool that you use everyday?

I have one and that's Xmind for mindmapping. I like to write notes for everything and what's even more better to visualise it in a mindmap.

But what do I use it for?

Here's few things I use it for:

• #1: Notetaking - I use it for notetaking whether its during the meetings, to understand a feature or while exploratory testing

• #2: Planning - I use it for planning whether its for planning testing, planning my personal goals or while brainstorming ideas.

• #3: Learning - I use it as a tool while learning any new topic, reading a book, watching a talk or reading a blog to write down any points that I liked and keytakeaways.

• #4:Ideas Tree - I use it to add any ideas that comes to my mind so I can revisit and pick some of them and work on it.

I use this tool for anything and everything 😄

What is that one tool that you use that helps you in your productivity?

As a tester there are so many skills that are required when working on the teams

Every tester has a different skills that becomes their strengths.

Here are 3 most valuable skills as a tester that are very useful(in my opinion) :

1. Asking Questions

As a tester we are great at asking questions to find out more information which also helps uncover how everybody thinks or understands about the same topic.

2. Collaboration

Testers have great collaboration skills as they pair with developers to test the stories or collaborate with the team to build the process or collaborate the business analyst to understand the requirements.

3. Creative Thinking

Testers have a creative thinking mindset, they come up with ideas, experiments and looking at the same feature from different angles while exploring.

We all plan goals and create tasks to achieve those goals.

We can't just keep learning and go on, we need some feedback to know if the work that we are doing is creating an impact and making difference.

These are 2 things we did on our teams to help people feel empowered to contribute and feel motivated :

1. Regular Speedbacks

Speedback sessions are a way to give and recieve feedback in a quick format which helps the team members to know their strengths and weakness. Because its a quick format it was done very regularly.

2. Feedback

Speedbacks are great way to get some quick feedback, our team would also collect regular written feedback which were based on the specific questions being asked and the goals that were set by each one of them.

By having these 2 things as part of the process helped the team members to develop a way to give and recieve feedback. It helped them to share their goals so they could get some constructive feedback very specific to their goals.

This helped the team members in coming up goals based on the feedback they got on their strengths and weaknesses.

When I first encountered the word observability(or o11y for short) I was curious to understand how it can help the teams in the world of testing or is it just something that is useful for certain roles for very specific usecases.

Let me share the following 3 reasons of how it totally fits into testing world.

#1 Learning from production

Having an observable system can help testers to learn from production and improve the way the product is being tested from the feedback.

#2 A tool for exploration

Testers are typically very curious, great at exploring and asking questions. Having an observable system can help testers to understand or find root cause of an issue while exploring and also helps in providing enough information that can be shared with the developers which makes it easier to colloborate to find the solution together.

#3 Helps uncover details

An observable system can help to uncover a lot of unknowns about the product so it helps in the learning of how different services interact and work. This allows to uncover a lot of valuable information that can be used as a guide for decision making when testing.

These are just very few of the reasons to mention. I'll share more in upcoming posts.

Have you read or heard about 'whole team owns quality'?

I have and I think every team goes through a different journey to get to the whole team owning quality. And ofcourse it's a continuous process.

These are 3 things I try to do on the teams that I work to enable the team

• so that they understand how to think or own quality

• so that I don't become the bottle and slow the feedback loop

1. Share Testing Knowledge 📚

I believe that team cannot think or own quality until the whole team understands what it is. I share the testing knowledge from the basics without thinking that people might already know these concepts.

I try to do this by facilitating different workshops and sessions on all various quality aspects so the team can learn by collaboration and interaction.

2. Collaborate To Build Test Strategy 🤝

Very early in my career I was always asked to come up with test strategy that was set up for team.

But now I try to advocate on teams to collectively collaborate and share ideas that would be part of the test strategy and make it as an evolving process. It helps the team to understand why we thinking about testing strategy, context of how things were decided and it becomes much more meaningful as it's been thougth by the entire team.

3. Quality Champions 🏆

When I'm the only tester on the team it's highly impossible to do all the testing and testing activities by myself. To overcome this challenge I encourage having quality champions on the teams or even better if the whole team wears a testers hat or thinks like a quality champion.

To help the quality champions I pair with them and create some guidance or template documents that they can follow for certain ceremonies like for example what kind of questions to ask during 3 amigos, kickoffs and deskchecks. I don't tell them what questions to ask but help them in coming up with what types of questions to ask.

These are again just the different experimentations I try depending on the teams context to help them and enable the team. And these are just 3 things I have mentioned out of many.

Do you have any ideas or suggestions? Share it in the comments 👇

How can testers make their work more visible?

Here's few things that testers can try to create the visibility of testing that will help the teams to understand better instead of having assumptions.

1. Pair Testing

Pair with the developers while testing. It helps in knowledge sharing, breaking the silo's and also helps the developers to understand how testing is being done.

And it doesnt have to be always pairing with only developers, we can pair with UX to test the usability and accessibility of the feature, we can pair with the business stakeholders to check if the requirements of the given feature were as expected.

By pairing with all the different roles, it helps in creating the visibility of how the testing is done and how testing helps to uncover a lot of things.

2. Daily Standups

Testers can use their story telling skills during the daily standups to share about all the observations and any issues about the features. It helps the entire team to understand what's being tested and what information is being capture while testing.

This helps in creating the visibility of how testing helps to uncover lot of unknowns as well and that its not just to find the bugs.

3. Documentation

Creating a central place for the teams with all the topics related to quality, for example documenting test strategy on confluence. When I say documenting I don't mean to create lengthy documents but just the right detail of information so anyone on the team can just follow and it would also be good for onboarding when someone new joins the team.

I use mindmaps while I'm testing the story and attach that to the Jira story. This helps the team to understand the detail level of testing done for each story and how its done.

4. Advocate for Quality

Advocate for quality improvements and different approaches to help the team to work towards quality. You can try running some workshops and you could also advocate for the processes within the team.

5. Testing Community/Guild

Have a space or slack channel so people can discuss challenges or any ideas about testing. Have a montly guild meeting and invite different roles like developers, UX and BA's so they could contribute and colloborate in the quality improvements process.

These are few things that can help testers to create visibility of testing which is so important to break the assumptions.

Do you have any other suggestions that you have tried on teams? Share it in the comments!

There are a lot of podcasts and articles on various trends for testers to learn from.

And honestly, I've tried listening to most of them.

But these are few that I keep coming back to, over and over again.

If you are interested to learn testing related topics and trends, here's the list of podcast I enjoy listening and learning from.

#1: TestGuild Automation Testing Podcast

I enjoy listening to this podcast hosted by Joe Colantonio. It covers all the topics related to test automation, latest new trends, new tools and a lot more.

If you interested to keep up with latest trends in test automation then this is the podcast you might want to listen to.

#2: AB Testing

Hosted by Alan and Brent with variety of topics like Agile, Devops, leadership and modern testing. I enjoy listening to this podcast which covers so many various topics and the discussions are so great way to learn different perspectives.

#3: Tester's Island Discs

I love music and testing. This podcast has a combination of both so I enjoy listening to this podcast to hear different veiws from different testers and listen to their favourite music.

#3: Quality Bits

This one is new on my list and I already enjoyed listening to each one the episodes from this podcast. It covers all the topics related to quality hosted by Lina Zubyte

Do you listen to any podcasts? Share them in the comment below.