As the requirements in subsequent development cycles are shared over email or on calls, hence, they tend to get scattered. Insufficient or NO requirements also add to this problem. Lack of documentation asks for a smarter way to collate and translate the requirements into testing artefacts such that they don't get missed out.
Possible risks while testing the software without requirements
Half-baked development – expected since the requirements aren't sufficient
Inexperienced resources.
Unavailable functional knowledge in the teams.
Ability to comprehend diagrammatic representation in various ways.
Inadequate time to document functionality properly.
Unavailability of business analysts, developers, testers or team architects.
Constantly changing requirements.
Level of detail required may be too high, and the time to produce the detail may be too less.
Conflicting diagrams/views arising from ambiguous discussions with business analysts, testers or developers
Possible ways to tackle the risks
Recognise the team's strengths.
Know the technical "modules" as developed by the developers.
Collate the modules or decompose them further, depending on the type of testing planned.
Assign modules as per a person's strength and knowledge.
Maintain a clear communication line between the team, developers, testers and business analysts.
If the above is done, changing the documentation to match the ever-changing requirements should be possible, although it could create havoc with the estimates.
When conflicts arise, make sure to discuss them with the parties involved. In case that is not possible, refer to prototypes- if any. If there are no prototypes, validate it from an end user and the desired business need.
To avoid ambiguous interpretations of diagrams or documents, make sure to determine standards for the teams to follow. In the case of diagrams, choose those approaches which are clean and analysis free. When a diagram is open for analysis, it is open for interpretation, which may lead to errors. Maintaining error-free documentation and tracking the same can be painful for a large project.
If the level of detail required is high with limited time, document the basics, i.e., a very high-level approach and update the test cases going ahead with testing.
Unfortunately, there is little one can do in terms of inexperienced resources or inadequate functional knowledge expertise within the teams. Be prepared to hire outside help or build up the knowledge by assigning a team member to the task.
Hints and hacks:
· Always inform the teams and stakeholders about the risks.
· You cannot test everything, test by priority.
· Discuss doubtful issues.
· Always follow up discussions with written notes.
· Keep calm and test, test again, and then test some more.
Best practices to follow before testing without requirements
A proper Planning Plan would include a list of deliverables, the types of tests to achieve, and the roles and responsibilities of the team members. Added to this, it's always beneficial to team up with the development teams to get to know the documents they were referring to for coding and utilise those documents to start test planning.
Investigate It's always beneficial to gather all the dispersed documents, email communications, recordings, and defects to connect the dots. Due to the time crunch, for this activity, it's better to be quick and prepare a high-level requirement document. Read and understand the high-level document organised and make a note of every single piece of evidence. It will act as a baseline document for future reference.
User Scenarios and Checklist To further benefit from the requirements point of view, preparing user scenarios could be a value ad. A user scenario is written in natural language to provide a clearer picture of what the customer is expecting and how we can accomplish a bug-free product.
User scenarios are stories to understand users' motivations, needs, barriers and more in the context of how they would use a design and to help ideate, iterate and usability-test optimal solutions. Furthermore, it's another value ad to list down functional tasks in the form of a checklist. There are many types of checklists that could be prepared, including the UI checklist, functional features, defects and boundary values etc. Checklists are easy to maintain, and users can quickly get the expected information out of them. Tester can easily improve the checklist by adding and removing checkpoints.
Grab the Developers We may not always find useful information in poorly maintained requirement documents. It's beneficial to have a discussion with the developers to solve and understand the questions or understand module-specific requirements. If the test teams don't have access to the business teams, contacting developers would always be a bright idea to answer the requirement queries.
Risk-Based Testing With no signed-off requirement, risk areas should be identified as quickly as possible. The risk-based analysis would be helpful in making choices on what tests needs to be run first in a time-crunch situation. Before testing, it would be beneficial to identify all areas where the user is most likely to find an issue, including the most defect-prone areas of the application, the functionality that is more visible to the users, core features, functionalities that underwent the most recent changes, all integration scenarios etc. Approve all risk areas with the application architect, developers, and customer support to make sure the test teams are heading in the right direction.
Ad hoc Testing When software testing is performed without proper planning and documentation, it is said to be Adhoc testing. Such kinds of tests are executed only once unless we uncover the defects. Testing is carried out with the knowledge of the tester about the application, and the tester tests randomly without following the specifications/requirements. Hence the success of Adhoc testing depends upon the capability of the tester who carries out the test. The tester has to find defects without any proper planning and documentation, solely based on the tester's intuition.
Ad hoc testing could be done in many ways, including Monkey Testing Testing performed randomly and without any Test Case. The purpose is to break the system.
Pair Testing Two Testers are allocated to the same modules, and they share ideas and experience to find defects. Buddy Testing One development team member and one tester work together on identifying defects in the same functionality/module. It helps testers to better understand the system from a different perspective.
Exploratory Testing Exploratory Testing opens testing to all key stakeholders and not just trained testers. Using exploratory testing, one can capture screenshots, record voice memos and annotate feedback during sessions. This enables faster and more efficient reviews by people beyond the traditional software tester. The beauty of exploratory testing is testers do minimum planning and maximum execution. Test design and test execution activities run in parallel. Hence testers document key aspects of the application during execution.
Exploratory testing is the essential approach when Testing without requirements.
Explore the software. Think from the user's perspective and try to observe things as a user. Try to explore the most critical and high-use features. Focus on the features which will be released soon. Learn the software behaviour. Learn users, objects, workflows, and product properties. Explore competitors' products.
To conclude, all one requires careful thought, planning and mapping out of tasks before one actually begins testing. Testers usually react by pressing the panic button and begin testing, and that would ultimately lead to complete chaos and immeasurable quality of the product. Clear thinking with valid goals will help the product achieve desirable quality.
Making the decision to act is the most difficult part; the rest is just tenacity and perseverance. Uncertainties and lack of requirements are mere paper tigers. You can do absolutely anything, including the efficient testing that you decide to do. You can act to change and control your project for a bug-free product. Happy Testing!
Thank you so much for putting in the time to come visit the all-things-testing blog.
Best regards
all-things-testing
PS: Please write back to me if you need assistance, so I can help you with more information on software testing without requirements.
Comments