This is Part 5 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Dealing with Objections. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Testing Requirements for Part 4 of this series.

Here is a list of all the blogs in this series:

• Part 1: Understanding Requirements
• Part 2: Requirements in The Agile World
• Part 3: Exploring requirements
• Part 4: Testing Requirements
• Part 5: Dealing with Objections

Post Workshop

You can check the workshop by heading over to the Worqference 2023 recordings page.

• Does this workshop have a follow up exercise or activity for us?

Yes. Here are few follow-up exercises to enhance the learning from the techniques for exploring requirements:

1. Group Activity: Divide the participants into small groups and assign each group a product/project. Ask them to apply the techniques mentioned in the workshop to gather requirements for the assigned product.
2. Role Play: Ask the participants to act out a scenario where they are eliciting requirements from stakeholders. One participant plays the role of the requirement elicitor and the other plays the role of the stakeholder.
3. Review of a Product: Ask the participants to pick a product and apply the techniques mentioned in the workshop to analyze the requirements of the product. Have them present their findings to the group.
4. Mind Mapping: Ask the participants to create a mind map of the requirements of a product or project of their choice. Have them share their mind maps with the group and discuss the different techniques they used to gather the requirements. Ex: Product coverage outline, Context free questions, etc.
5. Feedback Collection: Ask the participants to conduct a survey or gather feedback from users, customers or stakeholders to understand their perspectives on a product or project. Have them present their findings to the group and discuss the importance of considering different perspectives while eliciting requirements.

These exercises will help the participants to reinforce their learning and apply the techniques discussed in the workshop in a practical setting.

• How do we as a tester practice questioning skills in our free time post workshop?

As a tester, you can practice questioning skills in your free time by:

1. Games & Puzzles: Engaging in activities that require critical thinking, such as solving puzzles or playing strategy games. You can refer to a collection of such games here: Testers Playground (unicornplatform.page)
2. Active questioning: Asking questions in everyday situations and trying to understand the motivations and perspectives of others. Most of it is also driven by curiosity. Here are few ready to use toolkits on questioning:
   1. Questioning Toolkit (fno.org)
   2. Context-Free Questions for Testing – DevelopSense
   3. Context-Free Questions for Automation – Testing Titbits – Rahul Parwal

3. Reading: Books, articles, and blogs that encourage and challenge you to question assumptions and think deeply. You can go for any moral or ethical or philosophical books/short stories/articles. I also like mythology material.
4. General discussions: Engaging in discussions with colleagues, friends, family, or community members. Asking questions and trying to understand their perspectives.
5. Practicing active listening: Paying attention to the words, tone, and body language of the person speaking and asking follow-up questions to gain deeper understanding.
6. Journaling / Note-taking: Keeping a journal of questions that come to mind, exploring them, and writing down your thoughts and observations.

• How do I measure value I provide?

Measurement is often a double edge sword. In modern teams, setting up and tracking various parameters have become easy and simple due to the availability of powerful tools that we use for our project and task management. However, if the focus on measurement has gone to extreme, it can also lead to people optimizing what we measure them against, at the expense of what we don’t measure them. 

A measurement system yields “distortion” if it creates incentives for a person to make the measurements look better rather than to optimize for achieving the organization’s actual goals. A system is “dysfunctional” if optimizing for measurement yields so much distortion that the result is a “reduction of value”.

Having said that here are few parameters that can certainly showcase the value that testing adds by being in requirement process:

1. Increased customer satisfaction
2. Reduced testing cycles.
3. Shorter testing duration
4. Low design bugs
5. Feedback from sales & marketing team
6. More focus on bug prevention

This is Part 4 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Exploring Requirements. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on exploring requirements for Part 3 of this series.

Here is a list of all the blogs in this series:

• Part 1: Understanding Requirements
• Part 2: Requirements in The Agile World
• Part 3: Exploring requirements
• Part 4: Testing Requirements
• Part 5: Dealing with Objections

• How can a tester be plugged in early at ideation stage, there could be a lot of testing issues raised which are too basic?

As a tester, being involved in the ideation stage is crucial in ensuring that the testing issues that may arise later on due to false assumptions are addressed early. This can help to minimize the risk of basic testing issues being raised later in the development process, which can be more time-consuming and expensive to resolve.

All development projects start by assuming a solution to a problem can exist. Testers can contribute by focusing on the starting point of the project and slowing down to think about the requirements. In the ideation or development phase it is important to not focus on the basics build of the app and instead focus towards identifying any ambiguity in the stated requirements, as this can lead to missing requirements. Example: Identify if there are ambiguous words in the requirements such as “small,” “fast,” “inexpensive,” or “group.” The cost of such ambiguity in the requirements increases exponentially as the project progresses, making it important to question assumptions and explore ways to remove any ambiguity as early as possible.

The order in which questions are asked is also important. Testers can prioritize the problem statement and purpose. They can also sort and filter their questions to ensure that they are relevant to the context. By doing this, testers can help to ensure that the requirements are clear and unambiguous, minimizing the risk of basic testing issues being raised later in the development process.

• To what I have seen mostly many of the testers are skipped at this phase. How can we get them involved? OR What would be your approach to ensure that testing team is brought onto the table during requirements gathering phase?

To involve testers at the ideation stage, it is essential to break the myth that testers are only required after the product is built and that their involvement is expensive. This notion is long outdated, and the development industry has already realized that tests are first-class citizens. Read more about TDD and its importance to get a detailed commentary on this topic. It’s important to communicate to the larger audience that testers bring a lot more to the table than just testing and have deep investigative and critical thinking skills that they practice on a daily basis. These skills are very effective for exploring requirements and making sure that the requirements are well defined and effective.

Testers can start exploring requirements even before the build is available. Instead of waiting for builds to be ready, testers can use their skills to question and critique the requirements. This not only ensures that the requirements are of good quality but also that the testers are involved in the ideation process. By being involved in the early stages, testers can catch any missing or ambiguous requirements and suggest changes that can help to reduce the number of testing iterations and make the overall process more efficient.

Testers should be seen as more than just testers, and their involvement in the early stages of product development should be encouraged. Also, if you are serious about this change, I would recommend you to read two books: Perfect Software and Other Illusions about Testing, and Secrets of Consulting by Jerry Weinberg. These books would help you to solve the people and mindset related challenges that often limits testers to just the testing phase or process.

• What are you take on not to file “very basic issue” and resolve them on go?

Having a shared understanding of what constitutes a “very basic issue” is key to ensuring that it is handled appropriately. This will vary based on the organization and the product being developed, but in general, “very basic issues” refer to those that are relatively straightforward to fix and do not have a significant impact on the product.

While it can be tempting to simply resolve these issues on the go without filing a bug report, it is important to weigh the pros and cons and then decide if you want to make this tradeoff. On one hand, avoiding the creation of unnecessary bug reports can save time and reduce noise in the development process. On the other hand, if a fix for the issue is not well-documented, it may be difficult to track and understand later on.

To determine whether to file a bug report or resolve the issue on the go, consider the following factors:

1. Impact: How significant is the impact of the issue on the product? If it is relatively minor, it may be reasonable to resolve it on the go.
2. Complexity: How difficult is it to resolve the issue? If it is relatively simple to fix, it may be more efficient to handle it immediately.
3. Documentation: Will the fix be well-documented so that it can be easily referenced later on? If not, it may be better to file a bug report.
4. Future considerations: Could the issue resurface in the future and cause problems if not well-documented? If so, it may be better to file a bug report.

Ultimately, the decision of whether to file a bug report or resolve the issue on the go will depend on the specific circumstances of each case. The key is to weigh the pros and cons and make a well-informed tradeoff in the best interest of your projects long term needs.

• How can I write maximum number of test ideas from minimum documented requirements?

To deduce the maximum number of test ideas from minimum documented requirements, you can follow the following steps:

1. Review the existing requirements: Read through the available requirements and try to understand the product, its functionality, and the intended behavior.
2. Identify gaps in requirements: Look for missing information, ambiguities, or other areas that need clarification. Use it to add test points.
3. Collaborate with stakeholders: Engage with the product owner, stakeholders, and other team members to understand their expectations, and gather additional information. Use it to add test points.
4. Use heuristics and risk-based testing: Utilize popular heuristics to generate a large number of test ideas. Focus on high-risk areas and identify where the most critical failures may occur. Check out some useful heuristics here:
   1. Resources | Quality Perspectives
   2. Test Heuristics Cheat Sheet | Ministry of Testing
   3. FEW HICCUPPS – DevelopSense

Utilize test design techniques: Use techniques such as test data tables, decision tables, and use cases to create a comprehensive set of test cases.

This is Part 3 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Exploring Requirements. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Requirements in The Agile World for Part 2 of this series.

Here is a list of all the blogs in this series:

• Part 1: Understanding Requirements
• Part 2: Requirements in The Agile World
• Part 3: Exploring requirements
• Part 4: Testing Requirements
• Part 5: Dealing with Objections

By following these steps, you can quantify exploration and measure its effectiveness. Additionally, documenting the findings and evaluating the outcomes will help you communicate the value-added during exploration to stakeholders.

This is Part 2 of the Requirement Gathering Blog series by Rahul Parwal. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Understanding Requirements for Part 1 of this series.

Here is a list of all the blogs in this series:

• Part 1: Understanding Requirements
• Part 2: Requirements in The Agile World
• Part 3: Exploring requirements
• Part 4: Testing Requirements
• Part 5: Dealing with Objections

This is the Part 1 of the Requirement Gathering Workbook by Rahul Parwal. We’d like to thank him for sharing his expertise with the community through this information-packed piece.

Here is a list of all the blogs in this series:

• Part 1: Understanding Requirements
• Part 2: Requirements in The Agile World
• Part 3: Exploring requirements
• Part 4: Testing Requirements
• Part 5: Dealing with Objections

The purpose of this Workbook | Session Notes | Summary Document is to help testers understand the importance of requirement gathering and how it can add massive value to the testing process. The document will provide insights and guidance on how to gather and analyze requirements effectively, with the aim of testing beyond the written requirements. The document will highlight the importance of exploring the requirements thoroughly, considering the perspectives of all stakeholders, and utilizing the tester’s own knowledge, experience, and insights to create a comprehensive and effective testing plan.

Prepared By:

These session notes are the result of incorporating feedback and addressing questions raised by Chandra Pandey, Brijesh Deb, Sahil Kaushal, Mayuri Ubhad, Aravind M, Shoaib Ahmed, Balaji Ponnada, Apoorva Ram, Mayuri Ubhad, Jim, Ralf Roeber, and Anees Shaikh. Their insights have enabled me to tailor the workshop to address the most common and relevant concerns of participants. The notes serve as a reference guide for review, reinforcement, and further learning after completion of the workshop, organized by section.

Understanding Requirements

• How we decide that we have understood the requirements as it is required? OR what all parameters should be considered to ensure that requirements are clear? OR how you can make sure not just you but your fellow testers are also clear with requirements?

Determining that requirements have been properly understood is crucial for the success of any project. However, in reality it often gets difficult to know if the requirements have actually been understood correctly as we mostly work with the requirement documents and multiple sources of ambiguities. The more time and resources spent upfront to understand and verify the requirements, the better the chances of success. This includes effective communication with stakeholders, thorough analysis, and proper documentation. The following strategies can help increase the odds of achieving this goal of understanding requirements fully:

1. Technical Reviews: Technical reviews of requirements help to identify any gaps, ambiguities, or misalignments with the intended project outcome. This can involve subject matter experts, architects, testers and developers to ensure that the requirements meet the necessary technical standards.
2. Project Reviews or Demos: Regular project reviews are a valuable opportunity to assess the status of the project and ensure that the requirements are aligned with the project objectives. These reviews also provide a platform for stakeholders to ask questions, provide feedback, and raise any concerns.
3. Summary Reports: Regularly updated summary reports provide a high-level overview of the project’s progress and highlight any deviations from the original requirements. This helps to identify and address any issues early on, before they become significant roadblocks.
4. Measure Communication: Effective communication is crucial to understanding requirements. Regularly tracking the effectiveness of communication channels and identifying areas for improvement can help ensure that all stakeholders are informed and on the same page.
5. Measure Satisfaction – Take Feedbacks: Regular feedback from stakeholders is crucial to understanding their level of satisfaction with the project. This can help identify any areas where the requirements are not being met, and corrective actions can be taken to improve the overall project outcome.
6. Include everyone who might object later: It’s essential to engage with all stakeholders who might have a direct impact on the project later. This includes end-users, customers, and stakeholders who might not be involved in the day-to-day project management but can have a significant impact on the project’s outcome.

In conclusion, ensuring that requirements have been understood correctly is essential to the success of a project. A combination of technical reviews, project reviews, summary reports, effective communication, stakeholder feedback, and engagement with all relevant parties can help improve the odds of success and looking beyond the explicit requirements.

• How to keep track of all the information we receive on daily basis related to the product/project? Some good tips and tricks to efficiently manage all the information gathered by the testers.

Note taking is an essential skill for any tester. It requires consistent practice to get good at it and once you get good at it, it will give you exponential results. It’s a powerful meta skill.

I would recommend you read this paper by Michael Bolton on this topic, i.e., Microsoft Word – An Exploratory Tester’s Notebook – 63.doc (developsense.com)

Here is a quick summary if you want to just have a high level gist of it:

• How to deal with situation when you are onboard for testing late in the project and there are many issues with unclear requirements?

When you are on board for testing late in a project with unclear requirements, it can be challenging to catch up with the project and ensure proper testing is performed. However, there are several steps you can take to address this situation:

1. Get up to speed on the project: Start by getting a clear understanding of the project requirements, timeline, and goals. This can be done through meetings with project managers, stakeholders, and team members. Use context free questions to get this info. Refer to Context-Free Questions for Testing – DevelopSense
2. Assess the requirements: Evaluate the existing requirements and identify any gaps, ambiguities, or inaccuracies. Document these issues and work with the project team to resolve them. You can use a query tracker to track and discuss these issues. Ex: Shared google sheet document or a OneNote notebook.
3. Collaborate with the team: Work closely with the development team and other stakeholders to ensure that all requirements are well understood and properly defined. This can help you to ensure that your testing is aligned with the project goals and requirements.
4. Focus on risk-based testing: In a situation where requirements are unclear, it is especially important to focus on testing areas that pose the greatest risk to the project. This can help you to ensure that critical issues are identified and addressed as soon as possible.
5. Document your testing: Keeping a clear and detailed record of your testing activities and results can help you to demonstrate the value of your work and ensure that any issues you identify are taken seriously by the project team. Debrief your test notes with the team to get a feed for your next testing cycles. 

By taking these steps and working closely with the project team, you can help to ensure that the project is properly tested and delivered successfully, even when requirements are unclear.

• When you are new in any domain and how to acquire more knowledge about that domain so that you will understand requirement better. Is it really necessary to have more knowledge in specific domain to understand project requirements correctly, with this can we achieve customers perspective while writing tests.

Acquiring more knowledge about a domain when you are new to it is important in order to better understand the project requirements. This can be done through various methods such as:

1. Reading relevant material – Start by reading up on the industry, market trends, and any relevant technical material related to the domain.
2. Interacting with domain experts – Speak with experts in the field to gain a deeper understanding of the domain and its challenges. Join communities or follow relevant handles on social media.
3. Attending relevant trainings and workshops – Attending training, conferences, workshops and other events related to the domain can provide a wealth of information and also help you network with other professionals in the field.
4. Participating in hands-on projects – Hands-on experience is a valuable way to gain knowledge about a domain. You can contribute to projects that are relevant to the domain or take on a personal project to build your knowledge.

By having more knowledge about the domain, you can develop a deeper understanding of the requirements, and better anticipate the needs and perspectives of the customers. This will result in more effective and comprehensive testing, and better products that meet the needs of the customers.

This concludes the Part 1 of the Requirement Gathering Workbook. Stay tuned to The Test Tribe blog for the upcoming parts. Till then, keep learning!

Technology & Software is one of the fastest-growing sectors in the world today. In the tech industry, the number of people doubles every five years and more than half of the workforce has less than five years of experience. With so much development going on in these areas, the market for testing, automation, and quality analysis is growing exponentially (with few minor exceptions/corrections) too. The trend has continued for over 20 years now and hopefully will remain the same going forward. If you are someone who is just about to complete your engineering, or has recently completed your engineering and looking for a job, Software Testing could be an interesting field to be in.

However, in reality (thanks to our engineering/education curriculums), most fresh graduates actually don’t even have the slightest of an idea about ‘testing’, or ‘what working as a software tester’ is. Most testers who work for industry companies became testers by chance. This scenario is definitely changing with time but the gap is still very huge.

Through this article, I would like to talk about some tips & ideas on “How to get a job in software testing”. But wait, If you are a total beginner to this term, then I would suggest you to refer to these blog posts on Testing is…  and What Is A Tester? by Michael Bolton to get an idea about what Software Testing actually is.

If you are interested in self-learning the basics of software testing before you begin with a job search, then you can start with the BBST 3.0 Course on Testing Foundations by Dr. Cem Kaner. It is one of the most comprehensive courses on Software Testing Foundations. If you need free notes for this course, you can get them here.

So, If testing interests you as a good potential career, Here are some of the popular ways (not in any order) that have helped people to seek a job in software testing as a fresher.

• Campus Placement: Most IT Companies (including specialized testing companies) hire freshers from Campus Placements. There are On-Campus & Off-Campus Drives that take place for passing out batches. Skills that help in such drives:
  • • Aptitude for Learning
    • Good Written & Spoken English
    • Reasoning & Logical Abilities
    • Programming & Technical Knowledge: The degree to which this is expected varies from company to company. Generally, Product based companies expect these to a good level. In contrast, companies who are focused on service might want to access how quickly can you upskill with training and support. However, there are no fixed rules and it’s mostly context-driven.
• Post Graduate Diploma Courses: There are good courses that emphasize practical and industry-oriented learning by institutions like the Centre of Development for Advanced Computing (CDAC). A lot of companies visit such institutes for hiring freshers. There are many new promising options coming up in this format too. If you don’t have much familiarity with the tech world then this might be a good option for you.
• Internship / Externship Programmes: Many testing and IT companies offer internship and externship programs to college students. Start with such an opportunity and add value to the work you are doing there. They would most likely offer you a full-time role once you complete your graduation. Things that would help you to get such an opportunity:
  • • Build a profile on professional platforms like LinkedIn.
    • Watch out for opportunities.
    • Do 2-3 projects till your third year. It doesn’t matter how big or fancy it is. What matters is that you should know what you have done.
    • Learn to showcase your skills & work.
    • Approach relevant people to check if they can refer you to any such opportunity. As Anuj Magazine says, “Your first message should not be asking for help”. Keep that in mind!
    • Approach your college placement officer/alumni network if they can help you with any such opportunity.
    • Look forward to learning the basic skills that can help you be eligible for such opportunities.
• Testing Courses: There are courses that are open to all graduation streams. They will guide you on the basics of testing, programming, tech skills, interview skills, etc. In some cases, they can also help you with job search assistance. Despite the fact that there are some genuine courses in this area, most of them are simply designed to generate revenue for instructors. Prior to joining one of these courses/trainers/institutions, do some background checking. Seek out the feedback of people who have already been through such courses. Do not take advertised testimonials at face value.
• Job Portals: Learn about testing & tech and apply for jobs via portals. Good popular platforms are Naukri.com and Indeed.com. Most recruitment consultancies scout for profiles from these portals. If you are lucky, you will get a call.
• Job Referrals: Another popular method for getting a job is to ask for referrals. You can also ask your seniors/network that, what you can do to get a referral. Make it easy for people to refer you. Focus on networking within your space by being active in software testing conferences, workshops, and meetups.  
• LinkedIn Posts: Apply for jobs that people post on Linkedin. Drop mails to the concerned HR, write a cover letter, share your work portfolio (if you have one and you want to maximize your chances of selection) along with your resume for such job applications. It is likely that you would have to compete with a large number of equally competent professionals, so you should do whatever makes you stand out from the crowd.

• Automation in Testing Courses: There are many institutes that provide training on UI / API / Mobile Automation that is industry-oriented. If you are interested in automation, scripting, or programming and want to start your career in this field, apply for these courses. Again, Seek out the feedback of people who have already been through such courses.

So, those were some of the basic tips that will hopefully assist you in getting a job in the exciting field of software testing. Also, I plan to write one advance post on how to obtain a job in software testing for people who are ready to put in some effort in building a relevant portfolio. As an open market today, the software industry offers a lot of different possibilities, opportunities, and ways to make your way in.

Stay Tuned!

By – Rahul Parwal