RSS

Tag Archives: Software Testing

Quality is everyone’s responsibility.


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Who is “responsible” for quality? This is one of those interesting questions that on the surface of it seems really simple to answer depending upon your viewpoint … and yet the question itself hides a few thorny issues. Quality is not that simple. We all have the ability to add bits of quality and we all have the ability to take them away. In my opinion, there are various people who handle (certain aspects of) quality and those people are gatekeepers (for their area of quality).

There are so many role involves in Software Development Life Cycle (SDLC) and it is next to impossible to assign responsibility against all roles within the development team and this is where initiative comes into picture. Quality is one of the main factor in SDLC as it has direct relation with end users and when we speak about quality then one question comes into mind, i.e. “who is responsible for Quality?” Our understanding is, it is the job of a Software Tester. There is just no way that Testing can assure quality all on its own.

Quality is not the result of efforts of one single person. It is a combined effort of the whole team.

In general when you are working in a Development Team, many times we came across a statement like ‘I am developer and testing is not my responsibility’. Whenever I hear such statement , I recall this example from my father that “if your family has to be happy then you can’t assign a person in your family a role and responsibility of happiness and blame that person if something goes wrong”. If you want your family to be happy forever then it has to be happen with everyone participating in it!

Quality is not a one time activity. It is a continuous process.

Quality is the responsibility of everyone because no one person can successfully deliver a project by themselves. Usually, in the project world, projects are run by a number of people that are seldom from one organization.

It is imperative that each organization takes appropriate measures to ensure quality is engraved within its culture.

When quality expectations are understood by the project team; and each organization has set up in place a procedure to ensure quality control and assurance measures are taken, the project is more likely to be delivered to a better quality and hence more like to be a succes.

A simple example:

  1. During the Front End Loading of a project (aka. The Planning Stage of a Project Life Cycle), documents are the bulk of the deliversbles. Ensuring quality documents are submitted by the Consultant teams will definetly influence the project’s success.
  2. Likewise, during the Execution Stage (aka. Construction), the Contract shall ensure appropriate quality control and inspection tests are set up as it will also have an influence on the project’s success.


But is it just the Consultant’s responsibility in the first example or just the Contractor’s responsibility in the second?

I would argue it is not.

In my opinion Quality is just like Safety. Every person can contribute to having a safer construction site by identifying “near misses” or ensuring they take action when they see any unsafe act; likewise, every person can contribute to having a higher quality deliverables by understanding project’s quality expectations and delivering up to its standard.

I’ve been involved in software testing for 16+ years, working on major software implantations right across the globe, from Europe to United States, and India. Over that time I’ve seen testing evolve and go through various facelifts, but one thing is always true – you can’t have a good project without good testing!

During my stint in testing, I’ve realised something fundamental: Testers are just the information providers.

Testers alone can’t assure quality… but good testing can highlight low-quality. Through their various reports, testers provide the rest of your project with information needed to drive a quality solution.

Testing will never fix problems itself, but good testing will:

  • Accurately relay the status of a given solution at a given stage of development
  • Provide development with target areas to focus their efforts
  • Let the business know if the project is on track, or not
  • Let training get their ducks in a row ahead of the roll-out

I want to stress; you can achieve this with good testing. That means the right tools, correct coverage, appropriate test conditions, efficient prioritisation, and robust strategy.

It is not enough if one department or one person who is in charge of quality, works towards this. To achieve the goal of 100% perfect quality every employee connected to the company have to do their work on time, in an accurate manner.

I don’t mean that everyone needs to refocus on quality as a number one priority. Rather, other teams should work closely with the testers to understand the information and what to do with it. Despite what a lot of you think, testers aren’t the enemy. Other teams can and should use their information to make their own lives easier.

Accuracy of data and punctuality in the data delivery are very important aspects when it comes to proper Quality Management System.

As Aristotle has rightly said “Quality is not an act. It is a habit.” It has to become a way of life. Only if Quality is inculcated in the daily routine of an employee his or her work output will automatically be accurate and will also be punctual. All that we need to for this is to guide them properly. 

Quality is not an act! It is a habit!  We have to develop a culture of delivering quality products. You have to develop this culture not only in your work life or product you are developing but you need to develop this in your daily routine and this is how you can leave a Quality Life and develop a Quality Culture!

It’s really important to keep in mind that the term responsibility refers to the contextually proper sphere or extent of someone’s activities. When you call a team “Quality Assurance” that very name tends to imply that this is the team that is responsible. So don’t do that. Treat quality assurance as what it is: a function. It’s a function that stretches across multiple teams, embracing many roles. When you look at things this way then, yes, quality is potentially everyone’s responsibility but with the recognition that everyone has various areas of quality that they can reasonably influence and others that they have to rely on others to influence. What everyone can do is collaborate and communicate about those areas of influence, learning how to build a shared notion of quality throughout the organization.

In the end, the output of quality is primarily the result of all the people in the organisation so rather than blaming each other, let’s work as a team and deliver what is exactly needed. After all, there is only one team, and we’re all in it.

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

Advertisement
 
Leave a comment

Posted by on November 13, 2022 in Technical, Work Place

 

Tags: , , , , , , , ,

Pair Testing User Guide


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Pair programming is a familiar practice in extreme programming. Therefore, Pair programming considered as a great approach for programming software. Like wise pair testing is an alike process for testing software.

When you think of software testing, you probably think of an individual sitting at their computer performing manual tests or maybe writing up a Selenium script. In this scenario, they are also the sole person providing feedback on the test case and recording any notes or documentation.

However, pair testing is a little different, and it’s gaining popularity among the testing community. Pair testing, often referred to as Buddy testing, is a software testing technique where two people from the project team test the same feature in parallel under the same conditions while exchanging ideas. It generates more ideas which result in better testing of the application under test.Contrary to how it appears, pair testing does speed up test assignments while delivering more quality results.

One does the testing and the other analyzes or reviews the testing. This can be done between one tester and developer or business analyst or between two testers with both participants taking turns at driving the keyboard

In this a single task is divided between two individuals who exchange ideas, discuss test scenarios, take notes, and generally collaborate to test software functionality. It is a form of exploratory testing.

Generally, the pair in pair tests comprise a developer and a tester. However, in some instances, a customer, business analyst, solution designer, or technical writer can also form part of the pair if the situation calls for it.

This guide serves to introduce beginners in software testing to the concept, and where and when they can adopt the technique to maximize its benefits.

How to Conduct Pair Testing

Pair testing really isn’t that different from other methods of software testing, but there are a few things you may want to do in preparation.

Following these steps will ensure that it’ll be a productive use of both your time.

  • Identify scenarios to be tested: Identify the test case you want to work on and why you think pair testing is a solution. Come up with a few specific cases you want to be included in the pair testing. I suggest to write down a simple checklist of ideas.
  • Determine an objective from your pair testing session. Do you want to find bugs or suggest new features? Maybe you want to define tests that should be automated — maybe all of the above. Understand who you will be bringing your results to if it’s different than your normal report.
  • Establish Goals: Even though pair testing is a form of ad-hoc testing, testers shouldn’t be completely unstructured when approaching it. At the very least, formulate a list of software areas to cover. For example, let’s say a pair is testing a new feature with multiple components. Testers should come prepared with a list of components to cover, expected results for each, and what the test intends to accomplish.
  • Decide on Roles: Before starting, decide which of the pair will operate the machine (the driver) and who will direct the session (the navigator). The navigator takes the driver through the steps of the tests, suggests scenarios, takes notes, and swaps ideas. However, both parties should equally contribute ideas, suggestions, and concepts to enrich the test cases.
  • Create a timeline:  The duo should have access to a quiet room where they can talk (and not disturb anyone else) as well as the required machine for one or two hours. That gives yourselves enough room to explore and meet these objectives while staying focused on the tasks at hand.
  • Partner Up the Right People: Find two people comfortable with collaborating. The two people should have a sense of each other’s working styles, be able to communicate adequately, and see eye-to-eye on project goals.
  • Log Bugs and Take Notes: Once the session ends, log bugs, if any. Additionally, make detailed bug reports and note any unexpected discrepancies and anomalies that might have popped up.

Characteristics of Pair Testing:

  • Testing is an open-ended defect hunting process. Pair Testing will generate more effective test cases quickly and cheaply.
  • Forming testers in pairs will enable test managers to gather performance of the testers within the group.
  • Pair Testing is the best approach for mentoring and training the newbies in the team.
  • Testing in pairs generates a positive energy within the team with increased coordination.
  • Pair the domain expert with a novice tester to develop domain knowledge within the team.

When to Conduct Pair Testing

There are a few situations in which pair testing comes in handy:

  • Short pair tests between team members to quickly validate software components and further collaboration.
  • As a learning opportunity, pair tests are ideal. Assigning a new member or junior tester with a senior tester can help the former quickly come up to speed on the development lifecycle.
  • Pair tests are also helpful in supporting collaboration among different roles and expand the purview of QA operations. Testers can pair up with designers to get a sense of the software’s visual significance and design relevant test scenarios. Similarly, testers can pair with business analysts to ascertain how a customer-facing feature can be enhanced to boost revenue streams and brand credibility.
  • When bugs are identified, pair tests are perfect for bringing objectivity into the debugging process. With the second set of (preferably fresh) eyes on the job, it became much less likely for incorrect code to go unnoticed.

Benefits of Pair Testing

  • Breaks down siloes for better collaboration: Since pair testing requires people from the same and different teams to collaborate. Hands-on knowledge sharing and test activities break the ice between teams or individuals, invites new perspectives into QA, and keeps everyone appraised of overall project progress. It also fosters better inter-team relationships.
  • High creativity: Working in a pair forces each person to explain their ideas and react to the ideas of others. The simple process of phrasing ideas seems to bring them into better focus and naturally triggers more ideas. 
  • Easy Training Technique : A strong pairing is one where people are grouped so that their strengths will mutually complement their weaknesses. This presents an opportunity for people to learn from one another. Pairing is a good way for novices to keep learning by testing with others. It’s also useful for experienced testers when they are new to a domain to quickly pick up business knowledge.
  • High productivity: Each person must stay focused on the task or risk letting their partner down.  Pairing allows the person at the keyboard to follow their train of thought without pausing to take notes or locate reference information. It encourages dogged pursuit of insights. Two people working together limits the willingness of others to interrupt them.
  • Provides greater accuracy: A tester may miss out on a bug if they know the feature too well from its initial development phases. Technical personnel can lose sight of how actual end-users may approach the software.In pair testing, testers can join forces with someone less technically oriented (business analysts, product owners) to not miss out on the obvious errors. A fresh pair of eyes can contrast their “curse of knowledge” and help keep them connected to end-users’ concerns.Even if they pair up with a tester from another team, valuable feedback can come from the person not acquainted with the software. Basically, pair testing provides QAs with a pair of fresh eyes to examine software with, which tends to identify far more bugs than one tester working alone.
  • Promotes Knowledge Sharing: This might not be a tangible benefit, but its importance should not be downplayed. With experts from different teams/roles working together, both individuals will better understand how diverse software development operations work.Naturally, this fosters easier communication and helps individuals gain a more comprehensive understanding of team dynamics. This results in people who work better together (always a good thing) in the long run.
  • Creates Better Bug Reports: With two people examining software for bugs, bug reports tend to be more detailed, which helps developers address issues faster. Additionally, with insights from members from different teams, bugs are analyzed from not just technical perspectives but from customer-facing and financially relevant POVs.

Pair testing is one kind of what Malcolm Isaacs calls “social software testing”. When following an agile methodology and shifting left, it’s crucial for testers, developers, product owners, and other participants in the SDLC to come together for collaboration. Pair testing is just way one to do this.

While it may not be as deeply technical as, say, test automation might be, there are clearly many advantages to having two team members get together to discuss the quality of the application under test — what’s working, what’s not, and what needs to change?

Finally, it is a blend of team work and testing but it has many advantages like sharing knowledge about testing and SUT, training new members, making barrier between members and above that it is fun. we should use pair testing wisely.

Better software. Together.

Do you know of any other resources that might be useful to add to this list?

REFERENCES

  1. Pair Testing
  2. Exploratory Testing in Pairs Cem Kaner & James Bach
  3. Boost acceptance testing with pair testing Mark de Bono
  4. Testing Dojos
  5. The Power of Pairing Mike Talks
  6. Pairing – seeing the flipside of the coin Ben Kelly
  7. Pair Testing: How I bought developers into the test lab Jonathan Kohl
  8. The Moment Marlena Compton
  9. Pair Testing or something like it Matt Heusser
  10. Communication avenues to pairing opportunities Sean Cresswell
  11. Pair Testing QA Hipster
  12. Pair Testing: A Beginner’s Guide Shreya Bose
  13. Pair testing – A best practice to enhance accessibility test coverage Sunil Dangwal

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on February 14, 2022 in Technical

 

Tags: , , , , , ,

 
%d bloggers like this: