The timing ,scheduling and backlog clearing plan needs to be created very carefully along with all team members. Risk is the ultimate priority. High risk areas needs to be tested before any release and comparatively low risk area can be taken up in subsequent release or sprints.
Poorly written requirements-Challenges in Testing world
This is an important factor for Challenges in Testing.Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems. Sometimes the requirement was not written always.In a meeting, customer just says the requirement.
Requirement details are critical and a standout among the most dependable techniques for protecting issues in a mind boggling programming venture is to have ineffectively reported prerequisite particulars. Prerequisites are the subtleties depicting an application’s remotely seen usefulness and properties.
Requirement related to functionality ought to be clear, finished, sensibly point by point, firm, feasible and testable. A non-testable requirement would be, for instance, “easy to use”, which is excessively emotional. A testable prerequisite would be something, for example, “the item will enable the client to enter their beforehand appointed secret word to get to the application”. Care ought to be taken to include the majority of a task’s huge clients in the prerequisites procedure.
Clients could be in-house or outside and could incorporate end-clients, client acknowledgment test engineers, analyzers, client contract officers, client the board, future programming upkeep engineers, sales reps and any individual who could later crash the undertaking. In the event that his/her desires aren’t met, they ought to be incorporated as a client, if conceivable.
In a few associations, prerequisites may finish up in abnormal state venture designs, practical determination reports, structure records, or different archives at different dimensions of detail. Regardless of what they are called, some sort of documentation with itemized necessities will be required by test builds so as to appropriately design and execute tests. Without such documentation there will be no obvious method to decide whether a product application is performing accurately.
All reports ought to be kept in touch with a specific standard and format. Principles and formats keep up report consistency. It likewise helps in realizing where data is found, making it less demanding for a client to discover what they need. Ultimately, with principles and layouts, data won’t be coincidentally overlooked from a record.
So overall requirements are more to do with non agile projects where clients or business analysts can not come up with clear requirements. In agile way of development, requirements gets clarified during story grooming sessions.(Agile also faces requirement detailing issue though!!)
Lack of requirements contributes more Challenges in Testing (Software Testing challenges) and in Automated Testing challenges.
Bad requirements can be broken down into 4 different segments:
- Under specifications- resulting in incomplete or vague description.
- Incorrect specifications
- Inappropriate techniques used for description.
- Over specification
It is the most common type of requirement error.The common form is to omit important alternative flows.Alternative flows describe error handling and alternate behavior paths.
Failing to identify important alternative flows results in the system failing to handle important exceptions or errors conditions.
If an alternate flow is not described, we have to assume that the system does not support the alternate behavior.
Another important aspect is lazy description. The problem here,the requirement owner thinks that the reader is having full knowledge about the requirements. Now each reader translates this requirement as per their understanding and try to derive something which may /may not correct.
A common problem is that most of the teams barely have enough time to specify requirements in the first place.
An incorrect spelling,a semi colon mistake may completely change the meaning of a sentence. It is seen a small incorrect specification may screw up a whole code base as the meaning of the sentence was interpreted differently.
In agile world, over specifications are very rare but it is there.Even over specification can ruin the system.It starts with a good intention but end up with failures.Over specification provides too much details that tends to treat the symptoms. without going to the root causes for the problem the system needs to solve.
Design an user interface is often a tough job.most users are not very experienced with this.Even though it may seem harmless initially but later proved to be impractical.
Second area could be to provide implementation details to the world. There would be too much of descriptions. If we start providing implementation details in requirement space, that may lead to leak the implementation details. Crazy stuff.
Another aspect of over information happens when we develop different features in different phases of stories. Say, while working with a banking application,the user might have billing address,shipping address,debit/credit card related information,several other products information.
So preparing requirement for such customer with different information in different phases will create huge confusion as and when the new requirement comes in. It is very tough for anybody to visualize and then come up with test cases. It may so happen they may create many duplicate test cases covering the same functionality.
I have seen in few stories where they use third party names. Like
Priyanka should be able to enter details
A test engineer derived a testcase from it as follows:
- User should be able to login to the application
- User should be able to provide Priyanka’s details into the application.
Clearly a miss in the understanding right?
How to resolve?
In writing requirements,precision is required and this requires precision in language used. Mostly we want to ensure that everyone has the same understanding and we really want to understand when we have active discussions about the requirement.
The best way to mitigate is to have open communications approach instead of writing some requirement and throw them to developers and testers, encourage them to participate in requirement discussion.
In agile world open communication and discussion matters more than writing requirements or documentation.
Incorrect specifications can be avoided with peer review of the documents(It is a labor intensive process though) or an open discussion(time taking process). But unfortunately, these are the two ways available to rectify this sort of issues.