by Ray Scott, ComputerWorldUK
To me it means influencing the decision to release software into subsequent environments. Over the last few decades testing organisations have matured from an afterthought in the development cycle to trusted partners consisting of architects, automation technicians, tool administrators, performance, mobile and security experts, analysts and many other infrastructure support positions. This is quite an array of roles through which to assess the ‘readiness’ of software. This article looks at how the traditional role of QA is evolving, in step with the transition towards Automation best practices, by focusing on the FRINGE test practice that will change the face of traditional testing strategies. Fringe tests are those which arewhich are not included in the “Happy path” or “Use Case” but are possibly too complex to automate quickly or are rarely executed; they exist in the ‘Fringe’.
They are the RISK in testing; they are the tests that if time is running out are often omitted from execution and classified as RISK based low priority.Manual testers that have little to no business knowledge add little to no value to the maintenance of test cases. If the majority of the testing becomes automated in the development phase, their roles, too, become redundant. Many offshore and outsourced solutions are based on the creation of test cases based on static requirements; however, if development is based on short term bursts or sprints of requirement fulfilment there will be little to no benefit to this testing effort. Testers must adapt to their changing environment; testing is expensive and often over flowing with redundancy and process for the sake of process. This article looks at why these changes are occurring and what can be done to align with the change.
Traditionally, when a project is in jeopardy, management look at 3 significant game changers; Scope, Cost and Time. If cost is in danger the cogs that control Time and Scope can be adjusted, likewise if time is in danger the cogs that control Cost and Scope are adjusted and so on. However, the stakeholders may not wish to surrender one or two of the three controlling components to meet the delivery, which means that QUALITY is often the sacrificial lamb used to bring the project in. Sacrificing quality may mean executing fewer test cases, accepting lower performance statistics, and lowering stage gate criteria such as the pass-through of defects or fewer sign offs. Regardless of the path selected RISK is increased and, as such, the end user may not have the software available to them that meets their requirements.
To read the full article click here.