Fighting Defect Clusters in Software Testing

Defects tend to cluster in some areas of the software under test. It may happen due to higher complexity, algorithms, or a higher number of integrations in a few constrained segments of the software.

These defect clusters can be tricky, both to find and to deal with. Testers need to be on constant alert for ways to isolate defect clusters and devise ways to overcome them, fight those defects and move on to new clusters.

In my article for Gurock blog, I discussed some ways to fight Defect Clusters in Software Testing:

Locating Defect Clusters

Most defects tend to cluster in certain areas of your software. It is one of the seven testing principles. Many testers intuitively know of these defect-prone areas, but we can still strive to be on the lookout for clusters of defects in a number of ways, like utilizing

Metrics

Using metrics like defect density charts or module-wise defect counts, we can examine the history of defects that have been found and look for areas, modules, or features with higher defect density. This is where we should begin our search for defect clusters. Spending more time testing these areas may lead us to more defects or more complex use cases to try out.

For example, the chart below shows that Module 4 has the most defects, so it would be smart to continue concentrating on that module in the future.

History

Use the defect management system and the history of the software to go through older defects, and try to replicate them in the system. You will get to know the system’s history, where it broke and how it works now. You may learn a lot about the software and find many new areas to test.

Experience

A tester’s intuition, experience and history with the product is by far the best way to find defect clusters. Lessons learned by experienced teammates should be shared with new coworkers so that the knowledge can be passed on, utilized and improved upon by exercising these defect-prone areas with new perspectives.

Fighting Defect Clusters

Defect clustering follows the Pareto rule that 80% of the defects are caused by 20% of the modules in the software. It’s imperative for a tester to know which 20% of modules have the most defects so that the maximum amount of effort can be spent there. That way, even if you don’t have a lot of time to test, hopefully, you can still find the majority of defects.

Once you know the defect cluster areas, testers can focus on containing the defects in their product in a number of ways. Continue Reading—>

Read Along- ‘Agile Testing’ Chapter-7

“Technology-Facing Tests that Support the Team”

A look at tests in Quadrant-1 – Technology Facing tests

Agile Testing Quadrants
  • Unit tests and component tests ensure quality by helping the programmers understand exactly what the code needs to do and providing guidance in the right design
  • The term ‘Test-Driven Development’ misleads practitioners who do not understand that its more about design than testing. Code developed test-first is naturally designed for Testability.
  • When teams practice TDD, they minimize the number of bugs that must be caught later.

The more bugs that leak out of our coding process, the slower our delivery will be, and in the end, it is the quality that will suffer. That’s why programmer tests in Quadrant-1 are so critical. A team without these core agile practices is unlikely to benefit much from agile values and principles.

  • Source Code Control, Configuration Management and Continuous Integration are essential to getting value from programmer tests that guide development.
  • CI saves time and motivates each programmer to run the tests before checking in the new code.
  • An advantage of driving development with tests is that code is written with the express intention of making tests pass.
  • A common approach in designing a testable architecture is to separate the different layers that perform different functions in the application.

Teams should take time to consider how they can take time to create an architecture that will make automated tests easier to create, inexpensive to maintain and long-lived. Don’t be afraid to revisit the architecture is automated tests don’t return value for the investment in them.

“The biggest value of unit tests is in the speed of their feedback.”

  • Each unit test is different and tests one dimension at a time
  • Learning to write Quadrant-1 tests is hard.
  • Because TDD is really more of a design activity, it is essential that the person writing the code also writes the tests, before writing the code.
  • To Managers—
    • If a delivery date is in jeopardy, push to reduce the scope, not the quality.
    • Give the team time to learn and provide expert, hands-on training.
  • Technology-facing tests cannot be done without the right tools and infrastructure

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 »

Four Things That Can Sabotage a Sprint

Success and failure are a part of any journey. For agile teams, continuous delivery is the expectation, and that may be a hard thing to achieve. As sprints go on and tasks pile up, we may deter from the path.

Whether your team is beginning their agile journey or are already agile pros, you are bound to encounter a failed sprint at some point.

When do you deem a sprint as failed? Why does a sprint fail? What are the possible reasons, and how can you learn from the mistakes to avoid them in the future? In my article published at TestRail blog – I examine four possible reasons for a failed sprint.

Read the complete article at https://blog.gurock.com/four-things-sabotage-sprint/

Bad Estimation

Estimates cannot be completely accurate every time. But when the agile team fails to see the correct depth or complexity of a task or a user story, the estimates may go haywire, leading to a big diversion from planned timelines within the sprint.

Incoherent Definition of Done

To ensure true completeness, we must list coherent and agreed-upon definitions of done for each type of task we undertake within a sprint, be it development, testing, design, review tasks or test automation. This makes it easier to keep track of the quality of work and get every person’s understanding of the expected work on the same page.

Incomplete Stories

More often than not, user stories being developed in the sprint get stuck at some tricky juncture toward the end. Situations may arise where you reached the last day of the sprint but there are still things holding up the team:

  • Development of the story was completed but testing is still underway
  • Developers and testers paired to conduct tests but some critical issues remain in the feature that need fixing
  • Development and testing are completed but the automation script is yet to be created for regression of the feature (and automation was part of the exit criteria for the user story)
  • Code review is pending, although it is already checked in and working fine
  • Tests for the user story were not added to the test management system even though the tester has performed exploratory tests

Due to any of these reasons or a similar situation, the user story will be incomplete at the end of the sprint. At this point, that feature cannot be deemed fit for release and cannot be counted as delivered.

Technical Debt

In a fast-paced agile environment, we cannot shirk off any part of our work or leave it for later. This becomes technical debt that is hard to pay off. The longer we do not pick up the task, the harder it gets to find the time and spend the effort on it while working on ongoing tasks at the same pace… Continue Reading

My contribution to the eBook “Software People- Work From Home” -now on Leanpub

I am super excited to share that I have my first ever contribution to an eBook now published on Leanpub. This eBook called “Software People- Work From Home” is initiated and compiled by Stephan Kamper and Maik Nogens which has many software professionals from all around the globe contributing their stories, experiences and ideas on their work-from-home experiences.

In my chapter , I wrote about Speaking and Engaging from home in this pandemic-induced lock-down situation. I shared my take on engaging with your colleagues, engaging with the community and also with oneself while working from home. Check out Chapter-9 in the eBook to read my contribution. Please give it a read and support this wonderful initiative –> https://leanpub.com/softwarepeopleworkfromhome

Catch updates and opinions about the book, and tweet about it using the hashtag #SoftwarePeopleWfhBook

My Work-from-Home Desk

Another fun aspect of this eBook is getting to see all the fun ‘work-from-home’ setups and desk images shared by the authors along with their write-ups. It brings a sense of belonging, understanding and normalcy to this unique situation and helps you relate to the writer’s life and experiences. I , too shared by home desk image! 🙂

Find out how software people experienced the corona-virus-caused time working from home!

Software people from all over the planet share their insights & experiences, opinions, and tips.

The coronian times during the year of 2020 have – in fact are still at the time of the writing – proven to provide a good number of challenges for everyone.

– eBook “Software People- Work From Home”

This eBook is available for free at LeanPub. Please give it a read and support this wonderful initiative! https://leanpub.com/softwarepeopleworkfromhome

Cheers

Nishi

Four Ideas for Self-Care When Working from Home

Work life can be equally as stressful as personal life, if not more. This especially true when your home becomes your workplace. The boundaries between professional and personal life are blurred and it’s easy to forget to take care of yourself. Tech professionals need to tackle their daily stresses in order to be happy, healthy and more productive.

Practicing self-care goes a long way toward helping battle those stressors and can have great benefits for your mental and physical health. Don’t feel guilty about taking time to care for yourself. It’s not selfish to make your health a priority. And it’s not just for you, either: You will be better able to help others when you are your healthiest.

You cannot control everything life throws your way, but you can control how well you take care of yourself. Here are four ideas to practice self-care when working from home to increase happiness and bring back balance to your life. Read full article at https://blog.gurock.com/four-ideas-for-self-care-at-work/

Simplify Your Schedule

Although you may be frequently tempted to, it is best not to overpack your day with too many discussions or online meetings. Spending too much time talking about work rarely leaves you with the time or energy to get any actual work done during the day, leading you to burn the midnight oil.

Set a limit to spend a maximum of two hours in meetings per day. Keep your calendar open for others to see and let them know they can schedule time with you only up to that limit and within the hours you are most comfortable with. This will give you a simpler schedule and not take away your most productive hours with meetings.

Similarly, create a simple schedule for your personal tasks, chores, and things to do around the house each day and set some time aside to get them done. You will feel so much better doing things and checking things off your list, instantly adding a boost in your productivity.

Avoid Stress Triggers

Although it is easier said than done, you must make special efforts to avoid any known triggers or stress-inducing things at work, as well as while working from home. Some situations, people or types of interaction may leave you zapped of energy and feeling bogged down. If you look for these situations and learn to recognize them, you can then make an effort to avoid those scenarios, saving your energy and giving you better mental health.

Read More »

Four Goals of Testing Beyond Finding Defects

Are you testing with the sole purpose of finding defects? What if you don’t find any? Your testing should deliver more value than just finding bugs. In my article published at https://blog.gurock.com/, I examined the true goals of testing and how we can aim at achieving all four of them for the quality benefits of our software.

Gaining knowledge about defects 

While there is more to testing than pinpointing bugs, finding defects and problems is the first instinctive goal. Looking for places where the functionality breaks or does not work as expected is key. 

Testers can adopt a number of approaches, test techniques and strategies to find these problems before users do. This helps the team keep updated on the status of product quality, fix the problems, and improve the software for the users.

Proving functionality

If you have been testing diligently and going through a bunch of test cases and various scenarios but haven’t yet found a defect, it doesn’t mean it was all for nothing! If a test doesn’t fail, that means it passed, and that is useful information, too.

Another major goal of testing is to prove that the functionality works fine, and it is that proof that helps us make decisions about its future. Without this proof, we would never have a clear picture of the software’s quality, its intended functionality or whether it’s fit for use. Many teams would also get into problems with regulations, audits, and compliance without this proof of functionality.

Generating information

Testing also generates a lot more information than just passing or failing tests. Testers generally have loads of questions occur to them while testing. They may be about the need, implementation or design of the features, their related integrations with existing features, or actual usage scenarios. The answers to these questions are paramount in making the feature assimilate well within the software. 

Read More »

Read Along- ‘Agile Testing’ Chapter-6

“The Purpose of Testing”

  • The Agile Testing Quadrants matrix helps testers ensure that they have considered all of the different types of tests that are needed in order to deliver value.

Quadrant-1

Unit tests verify functionality of a small subset of the system. Component tests verify the behaviour of a larger part such as a group of classes that provide some services. Unit & Component tests are automated and written in the same programming language as the application. They enable programmers to measure what Kent Beck has called the internal quality of their code.

Quadrant-2

  • Tests in Quadrant-2 support the work of the development team but at a higher level. These business-facing tests define external quality and the features that the customers want. They’re written in a way business experts can easily understand using the business domain language.
  • The quick feedback provided by Quadrant 1 and 2 automated tests, which run with every code change or addition, form the foundation of an agile team. These tests first guide the development of functionality and when automated, then provide a safety net to prevent refactoring and the introduction of new code from causing unexpected results.

“Appraising a software product involves both art and science.”

Quadrant-3

  • Quadrant-3 classifies the business-facing tests that exercise the working software to see if it doesn’t quite meet expectations or won’t stand up to the competition. They try to emulate the way a real user would work the application. This is manual testing that only a human can do…use our senses, our brains and our intuition to check whether the development team has delivered the business value required by the customer.
  • Exploratory testing is central to this quadrant.

Quadrant-4

  • Technology-facing tests in Quadrant-4 are intended to critique product characteristics such as performance, robustness and security.
  • Creating and running these tests might require the use of specialised tools and additional expertise.
  • Automation is mandatory for some efforts such as load and performance testing.
Agile Testing Quadrants

Technical Debt

  • Ward Cunningham coined the term “technical debt” in 1992, but we’ve certainly experienced it throughout our careers in software development.
  • By taking the time and applying resources and practices to keep technical debt to a minimum, a team will have time and resources to cover the testing needed to ensure a quality product. Applying agile principles to do a good job of each type of testing at each level will, in turn, minimize technical debt.
  • Each quadrant in the agile testing matrix plays a role in keeping technical debt to a manageable level.

The Agile Testing Quadrants provide a checklist to make sure you have covered all your testing bases. Examine the answers to questions such as:

  • Are we using unit & component tests to help find the right design for our application?
  • Do we have an automated build process?
  • Do our business-facing tests help us deliver a product that matches customer expectations?
  • Are we capturing the right examples of desired system behaviour?
  • Do we show prototypes of the UIs and reports to the users before we start coding them?
  • Do we budget enough time for exploratory testing?
  • Do we consider technological requirements like performance and security early enough?

I am speaking at the Tribal Qonf by The Test Tribe!

I am super excited to be a part of the wonderful lineup of speakers at Tribal Qonf, being organised by the awesome community at The Test Tribe https://www.thetesttribe.com/tribalqonf-virtual-2020/

It sure is going to be a great event with some awesome talks lined up by internationally renowned speakers.

My talk is going to be about “Adopting a Simplified Risk Based Testing approach” which includes a little bit of a story from my past project and a showcasing how to implement a simplified risk based approach on a new project.

https://www.linkedin.com/posts/activity-6676435963583037440-ssRp

Here is a link to the conference for you to check out the details and the agenda – https://www.thetesttribe.com/tribalqonf-virtual-2020/

Link to Register -> https://www.townscript.com/e/tribal-qonf-2020-a-virtual-conference-by-the-test-tribe-431224

Discount Code -> TQNISHI

Details of Discount – > This code is to claim a 5% discount but across categories, and as many as 50 folks can claim it. 

Here are some awesome community posts to check out!

https://www.linkedin.com/feed/update/urn:li:activity:6666906210366820352/

http://enjoytesting.blogspot.com/2020/05/tribal-qonf-reason-2-to-attend.html

See you there!

Cheers

Nishi

Working from Home? Five Tips to Keep Your Sanity and Productivity Intact

As teams and companies across the globe are following social distancing recommendations, many workers are wading into unchartered territory. How are you supposed to maintain any kind of workflow when your surroundings (and mental state) are different from what you’re used to?

If you are new to working from home, here are five tips to help keep your sanity and productivity intact! Read Full article at https://blog.gurock.com/working-from-home-tips-productivity-sanity/

Embrace the Change

Working from home will be different from working from your office. You might miss the human interaction — the lunches with your team or the coffee breaks and informal chats. You might also feel derailed from your goals a little as you figure out the dynamics of online collaboration tools, remote meetings, and screen-sharing applications that take away time from your actual work.

But this is not the time to get bogged down by these changes. Since most of it is out of your control anyway, it is better to embrace the changes — or at least accept them — to give yourself peace of mind. Try not to fight your new situation or get negative about it.

Manage Your Distractions

Your day at home will be filled with many distractions that may take your focus away from your work. Working can be hard when you see that sink full of dishes or a dirty living room that needs a vacuum. I personally find myself rushing to the kitchen every hour to fix myself a snack, just because I am so close to it! You may also have partners, children or other people living with you who are trying to get through their day too.

It is imperative to create a routine that helps you manage these distractions. First, try to set your work hours at a time that fits your day and your family. Your at-home work hours may not be the same as your in-office work hours, and that is OK. If you can wake up early to get a couple of hours of work done before your kids are up, do that! It will start your day off on a productive note and you will feel less stressed about spending an hour feeding your toddler breakfast. Once you get them to settle down for the day with schoolwork or an activity, you can resume working.

If you have a partner also working from home, manage your time with them in mind. What are the best times to begin working? Do you both want to take a break to have lunch together? How can you split your chores so that you are not perpetually stressed and distracted with them?

Even if you live alone, having a routine and set times for beginning work, having a snack or lunch, and finishing work will help you keep your focus and get things done!

Designate Your Space

This is the most important factor when living with someone else. Being productive requires a space of your own and the feeling of being at work. Even if it is as little as setting up a desk, using a corner in the living room or making your couch your work area, you will need to make the effort! Have your laptop, books, chargers and other stuff you need at hand, and set up that area to feel like your workplace from now on. Use that space consistently for at least a few hours each day and keep distractions to a minimum. 

If you are lucky enough to have a study, home office or other separate room to work, you might need to coordinate with your partner on using the desk at different parts of your day. My husband and I use our study room alternately, mostly with me spending the first part of the day there while he uses it in the later half of the day, since most of his work calls happen at that time. If you and a partner or roommate are both scheduled for calls at the same time, decide on your separate areas and give each other space to work in peace…….

Read More — > https://blog.gurock.com/working-from-home-tips-productivity-sanity/

Published at (https://blog.gurock.com/)