My experience as a Panel speaker @LeadDev webinar

I was invited by @LeadDev organisation to be a part of a webinar where we had a panel discussion on “Building a better testing culture“. I was elated to be a part of this great group pf panelists alongside Thayse Onofrio from Thoughtworks and Marcus Merrell from Saucelabs. We had a spirited and interesting discussion and shared some meaningful ideas on the topic. I would also like to thank our host Amanda Sopkin for her really on-the-nail questions and for directing the conversation, and our organiser Olivia Christian for inviting me and for her support throughout the event!

The webinar panel was live, lasted for 45 minutes and then we had some time for Q&A. There were some great questions and discussions over the LeadDev slack channel as well.

Here is a bit more insight into the event-

The world of software testing is changing under the pressure of ‘speed to market’. The pressure to quickly get products to market means we are starting to see a significant shift towards automated tests during development. This will likely cause socio-technical complexities for orgs and teams currently involved in testing.

In order to be successful through these changes, orgs will need to have a clear strategy and processes in place that will ensure testing is a vital part of the delivery process. In this new age of testing, how can engineering leaders prevent pitfalls such as friction between teams, a culture of blame, and outdated processes?

In this panel, we examined how shift affects traditional testing set-ups, covering what a healthy testing culture looks like and how to avoid the anti-patterns that lead to uncommunicative teams and project bottlenecks. We explored how engineering teams can best work together and how to encourage a shared vision of quality and the importance of efficient and effective tests.

Key takeaways

  • Define clear roles and responsibilities for quality and testing in your org 
  • Encourage QA to be seen as necessary, rather than inhibiting release times 
  • Understand which tests to automate, and which to not

About LeadDev

LeadDev is a community of software engineering leaders that come together to learn and get inspired on all things team, tech, process, and personal development. 

LeadDev has become an essential destination for anyone in tech and engineering who wants to scale themselves and create impact. They provide a range of content that includes articles, thematic content series, video talks and panel discussions, written and delivered by the best voices in engineering.You can register a free LeadDev.com account to gain access to our free engineering leadership content, free online events and our weekly email newsletter. 

Advertisement

Defining Your Definition of Done

The success of your team and the release depends on everyone getting their individual parts done in time. But how do you define being “done”? What indicates a finished task and differentiates it from a half-baked one?

It is all about having a clear definition of done established and agreed upon within the team from the onset of the project. Check out my article published at https://blog.gurock.com/definition-of-done/ – Here I talk about some good ways to define your Definition-Of-Done

Brainstorm with your team

The person who is going to work on each task is obviously the best person to comment on how and when it will be closed. So, the first step would be to discuss and list the obvious things these people deem would need to be done in order to be able to say that their task is done. Sometimes, you may be surprised how different these “obvious” points may be for different team members.

For instance, Tester 1 may say that after executing tests on their user story, they also spend an hour doing exploratory testing before completing their testing tasks, while Tester 2 did not consider that as part of the task. They completed the test execution task once done with scripted tests and later, if time permitted, would perform some exploratory tests.

By doing this exercise you are baselining your expectations from each task, independent of its owners.

Consider quality goals

If you are seeking to come up with a definition of done, there is probably an area you are trying to improve and some quality goals you are trying to achieve, so consider them now. Think of what seem to be your team’s problem areas, or the source of their delays at the end. Now add a part of those quality goals in the relevant tasks.

For example, let’s say your builds seem to fail too often, and that leads to a lot of rework and retesting within the sprint. After some analysis, you found that the build failed because of developers checking in buggy code, mostly lacking integration tests.

Read More »

Ways to Stay Engaged with Your Team While Working from Home

Many software teams were forced to work remotely because of the onset of the global pandemic of COVID-19. Months in, most teams have now found their pace and made their peace with it. Hopefully, you’ve gotten comfortable and set a routine for yourself in your new work-from-home setup.

But are you engaging enough with your colleagues? Or are your conversations limited to virtual meetings and video calls? It’s important to have other ways of staying connected with your team.

As an organization, it is important to realize that however close-knit or small your team may be, not having a proper open channel of communication may make people feel out of the loop. In my article published at Testrail blog, I have discussed some tips on how to keep yourself and your team engaged when working from home.

Bump up communication

Before, it may have been enough for the manager to have one-on-one conversations with team members once a month, but our new remote situation calls for a little more. Managers should increase the frequency as well as the quality of the conversations they have with their teams. Strive to understand what teams are struggling with, remove their impediments, and ensure a smooth workday for each person.

As a team member, you too now have the responsibility to stay in touch with your peers more often. It is important for you to participate more in conversations with others rather than just being a spectator in your group chats or calls. A simple greeting and an update about what you are working on today is a good start that helps others peek into your day, and it increases the chances of their doing the same.

Provide clear directions

Managers and leaders need to focus now more than ever on setting up open lines of communication within teams. Give clear directions about what is expected of everyone, share what you feel about their work in the form of constructive feedback, and ask them their opinions. It is important to be empathetic and understanding and to have a listening ear.

In the middle of this chaos, it is important for people to have specific instructions, tasks, and goals so that they can focus on achieving objectives and have some structure to their days. Achieving these small tasks will make their time more productive and motivate them to get more done!

Read More »

Are you a Good Agile Leader?

Agile leaders are supposed to get the maximum amount of quality work done with minimum control of the situation. The team constantly needs support and guidance while remaining independent and self-motivated.

How do you get this done within the tight deadlines? Do you have the team’s trust, and do they have yours? How do you know if you are a good leader for your agile team?

In my article for Testrail blog, I discussed the challenges of Agile Leadership and shared some tips for aspiring Agile Leaders to excel in their team management! Here are some areas to focus on:-

Communication

Communication is the backbone of agile. Open, clear and frequent communication breathes life into the agile team.

As an agile leader, you will be required to be big on communication, stressing its need, ensuring it is happening, and keeping it open and constructive at all times. You may even need to get over your own fear or reluctance if you are an introvert! A good agile leader needs to constantly encourage people to work together, discuss issues, and enforce good communication practices.

Vision

As a good agile leader, it is imperative to maintain a clear vision for the project. Since agile requires teams to deliver working software frequently, most of the team’s time is spent concentrating on different tasks and activities to make the release happen.

But since requirements change often, it is easy to lose sight of the overall vision for the project amidst all that chaos. It falls to the leader to keep the team aligned, maintain the overall vision, and help everyone zoom out periodically to look at the bigger picture.

Removing Impediments

A Good Agile Leader

An agile leader is required to be a constant problem solver. They need to look for problems before they happen and resolve them as early as possible.………

Read More »

I am speaking at TestBash Home 2020

When life gives you lemons, make lemonade! None better example of this than the zingy, sweet lemonade under preparation by this awesome community at @Ministry Of Testing , bringing the ‘testing’ flavors of the entire world right to your home!

Despite cancellations of a number of events due to the ongoing pandemic, this community has come back together to create an amazing online event. I am super excited to be speaking at TestBash Home 2020 – the first online software testing conference by Ministry Of Testing. It will begin on the 30th of April 2020 and run for a full 24 hours into the 1st of May 2020, traveling all timezones so that everyone in our truly global testing community can get involved. 

I am honored to be a part of such an awesome line-up of speakers. These hours are going to be packed full of interactive sessions including talks, panels, challenges, plus we’ll relive and reflect on some classic TestBash talks.

Speakers List – TestBash Home 2020

The agenda is live now-

Checkout more details about the event and schedule here –https://www.ministryoftesting.com/events/testbash-home-2020

Follow the updates on Twitter—

Register now for loads of fun and learning and engaging with a worldwide community of testers right from your home!

Cheers

Nishi

Blind Spots in Software Testing

Reduced awareness or unintended ignorance of certain aspects can lead to inattentional blindness, or the failure to notice something that should have been visible because our attention was engaged elsewhere. As a human psychological concept, inattentional blindness also plagues testers and their mindset when testing. In my latest article for Testrail blog, I look at some steps we can take to overcome this challenge and avoid blind spots in our testing work.

Target Fixation

It is a natural response of our brain to avoid getting overloaded with information. It automatically focuses on information that is most important while avoiding unnecessary details and noise.

In many situations, this manifests in our focus on the task at hand and its context so much that we neglect surrounding details. This is true for day-to-day activities like bumping into a pillar while looking at our phones, failing to see a swerving car when watching the road ahead… or not noticing a takeaway coffee cup in the middle of a popular television show set in ancient times!

Let’s say you are browsing through a website with the intention of looking at the layouts that must match provided mockups. While you are doing that, you may miss the following:

  • The homepage of the website has an older logo of the company that should have been replaced by the newer version.
  • The login box has username and password fields but the login button is missing.
  • The URL structure of the website is all wonky and the individual page URLs are not named correctly.

Overlooked Information

Testers often execute tests that have defined steps and expected results, so we frequently overlook anything that is not defined and only check for the results we’re looking for. The tester’s mind is attuned to looking for specified errors, while other information or defects may tend to get missed, even though they may be right in front of our eyes.
Pick up any passed test case and try to re-execute it, but this time keep an open eye and an open mind for any new information surrounding the test. More often than not, you will find that many more defects, risk areas or questions can be found in the same area, despite the test having passed.

Read More—>

Read complete article at https://blog.gurock.com/blind-spots-software-testing/

How Technology Has Changed Project Management

The use of advanced technology in business environments can sometimes be jarring. Adjustments can be difficult, and on top of that many employees across a range of industries worry that technology can make them obsolete. These can be legitimate concerns in some cases. But, more often than not, technology serves instead to simplify processes and, ultimately, make life easier on people as they go about performing their jobs. This is certainly proving to be the case where project management is concerned.

Project management demands and processes vary across different businesses and industries, which means that not all teams in this category can implement modern technology in exactly the same ways. Here we’ll examine a few key ways in which tech can and has changed project management for the better.

Communication & File Sharing

Maybe the biggest change that technology has brought about for project management teams is a simplification of communication among groups in a work setting. In 2019, our post on ‘Overcoming Barriers to Effective Communications in Agile Teams’ touched on the idea that various barriers to regular communication can negatively impact productivity. And the same is absolutely true for project management teams of all kinds.

Now, however, there are several different communications platforms that are being used in professional environments to streamline collaboration. Often enough, they’re used to simplify digital communications in office environments in general, providing a space where everyone from a manager to a part-time freelancer can log in, see shared information, engage in relevant chats, and generally stay up to speed. These platforms can also be invaluable for project management teams.

For instance, think about a fairly common project such as developing a website or an app for a business. These are projects that involve contributions from people with different skills in conjunction with one another. A page design can’t be completed without understanding of the content layout; content layout can’t be finalized without a thoroughly developed visual aesthetic, and so on. On these modern communication platforms, these matters can easily be discussed between relevant parties such that the greater project can move forward. Updates and examples can be shared, and people can easily work with relevant collaborators whenever they need to.

Collaborative Design

In the past, one issue that plagued some project management teams is how to get everyone on the same page in more multi-faceted projects. There haven’t always been structured ways for different aspects of one overarching project to be addressed in a cohesive manner. This is changing, however, thanks in large part to both abstract and specific software.

Read More »

Personality Traits that make a great tester

Testing concepts and techniques can be learned. But having a knack for testing is different. What makes someone a born tester? What are some personality traits and skills that can make a person innately good at this profession?

In my latest article published at https://blog.gurock.com/natural-traits-great-tester/ , I have described four traits that belong to people who naturally make great testers. Developing these traits can help you in your testing career, and if you are a manager, these are the traits to seek when looking to hire new testers for your team!

  • Communication
  • Empathy
  • Curiosity
  • Meticulous Organisation

These traits may not have much to do with technical side of the job, but they surely contribute to the testing mindset and success of a great tester in a team. Read the full article -> https://blog.gurock.com/natural-traits-great-tester/

Defining Exit Criteria for different phases of your Agile project

Exit criteria are a list of items to check off that define the end of any activity. Exit criteria can be defined for any activity you want to undertake: You can have exit criteria for cooking veggies to the desired doneness, or for a city tour to be sure you see all the sights, or for a meeting to assign action items for everyone! Exit criteria are helpful to tell you (and others involved) when to stop the activity. Specifically, for an agile project, having clear and concise exit criteria makes it easier to understand the scope and avoid going overboard while keeping a tab on your quality. 

In my article published at Gurock https://blog.gurock.com/agile-exit-criteria/ , I have discussed some ways to structure your exit criteria at the sprint, user story, and task levels in an agile project.

The first rule for exit criteria is to have them defined up front, before beginning the activity.

For an agile project, let’s say we want to have exit criteria in place for the end of the sprint. We will need to work on defining them at the beginning of the sprint, or at the release-planning stage. Once the activity begins, the goal is to achieve all exit criteria by the end. We cannot have people defining or changing the planned exit criteria during execution of the activity, since that will not be upholding the quality standards set in the beginning.

The second rule is to have standard exit criteria for all similar activities. So, exit criteria defined for the sprint level apply to all sprints in that release, and exit criteria defined for the user story level apply to all user stories in all sprints. This upholds the same standard of quality and expectation of work required for each of these work units.

In the article, I have discussed sample Exit Criteria for Sprint, User Story or Task level and also shown how to create your own exit criteria based on your project’s and team’s context.

The important things to focus on are having the exit criteria defined up front and ensuring follow-through by sticking to the criteria throughout your release cycle. Being consistent with checking off everything on your exit criteria list ensures a smooth flow of high-quality work.

Check out the complete article here – >

Metrics your Agile team should & should not be tracking!

Agile teams are constantly running toward goals, requiring constant planning, monitoring, and re-planning. Metrics can help support these efforts by providing useful information about the health and progress of the project.

There are a few common metrics we use in agile teams: sprint burndown charts, release burnup charts, team velocity. They’re common because they communicate practical information, but they’re not the only metrics we can employ.

In my recent articles for TestRail blog, I described 3 Uncommon metrics you can easily create that will be very useful for your agile team. I also wrote about 3 Metrics that are not useful and you must stop using now!

Here are the posts–>

Three Uncommon Metrics Your Agile Team Should Be Tracking

Here I described 3 most useful metrics –

Defect Health

Defect Health Chart

Test Progress

Metric for weekly test progress

Build Failures

Sprint-wise metric for No of Build Failures

Click here to read the complete article —>

Three Metrics Your Agile Team Should Stop Using

Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.

In this post I have described three metrics that can impede your agile team instead of motivating you.

  • Defect Counts
  • Hours
  • Lines of Code or Defect Fixes per Developer

Click here to read the complete article–>

Please share your experiences with metrics and how they helped or impeded your progress!

Cheers

Nishi