In a nutshell, here are the deliverables of a competent Quality Assurance team:
• Ensuring a low maintenance cost after the software has been implemented and put to use
• Maintaining superior product standards that are reliable, consistent and meet business objectives
Software development in Sri Lanka is quite diverse, and each agency may have its own etiquette in executing QA processes. However at EFutures, the duties of our Quality Assurance team revolves around the two visionary pointers as mentioned above. So what do our QA staff participate in, in order to reveal successful results? Here’s the lowdown.
As mentioned previously, Quality Assurance goes far and beyond merely identifying bugs and rectifying them. In fact, Quality Assurance of the right kind instead focuses on preventing defects from the initial stages of the project, in order to maintain a streamlined development process.
While technology has been evolving at a breakneck pace, it is viable to only use what is necessary. As lead conversions remain your primary business objective, enabling your users to turn to customers at their convenience (not yours) is something to keep in mind – and surprisingly, is something that may require much less in terms of technology than you thought!
This is because the cost of any defect significantly increases as time passes by. In other words, rectifying a bug during the planning phase incurs far less of a cost than it would have if it would’ve been troubleshot post-implementation.
Here’s why involving our QA team from the get-go benefits every website, app or software that we create:
• QA engineers become more familiar with the business requirements that the software is supposed to fulfil, so that any indicators/facts pertaining to the software can be provided early on in time,
• Predict any possible defects, and subsequent solutions. In turn, this can help manage bugs better, while saving time and money.
In order to be involved from the very beginning, a requirement analysis of the product needs to first be carried out. This is a task that needs to happen as early as the pre-sale stage, by liaising with business analysts and/or relevant marketing personnel.
A concise requirement analysis can then help QA staff members learn better about the following, and ideally in the order that they’ve been stated:
1. Understanding business needs
2. Determining the goals that the software must obtain, in order to meet business needs
3. Determining overall project scope
4. Defining testing types and the necessary level of testing for each
Quality control during each phase
• Ambiguous, implied and/or incomplete requirements
• Requirement gaps and mismatches
• Errors in functional and processing flows
These requirements can be scrutinised by brainstorming with other members of the team, including the client – and reporting the same to the client with updates and changes. This way, every team member envisions a common picture about the final product. Additionally, design and development teams also get to delve into product creation that is supported by precise and refined business requirements, as opposed to incomplete or misconstrued requirements.
Once the key technical designs are complete, our QA team inspects them to ensure that every nuance of these designs are compliant with system requirements. This includes the fulfilment of both functional and non-functional aspects of the design.
Items that are reviewed consist of:
• Solution architecture designs
• Component designs of the system’s key aspects
• State machines and workflow diagrams
• UI/UX prototypes
Reviewed collaboratively with the development team, all the knowledge gathered during this session can assist every project member to tailor their duties accordingly in order to stay on track with the final business objective(s). As for testing, this technical design review provides valuable guidance on implementing automated tests, performance/reliability tests, security/penetration tests etc.
In a scenario as ideal as this one, the testing phase can be concluded in as little as 2 test cycles. This ensures speedy delivery of the product, while maintaining exceptional standards of quality.
Software Release – Rules and Standards
• Releasing the UAT (User acceptance Testing) following internal assessments and subsequent confirmation from the QA team
• Smoke testing on the UAT/production environments by the QA team, in order to ensure that the correct version is available
• Conducting a regression test in the event that any feature/functionality has been altered, or when the client is demanding a release that’s much earlier than the scheduled date
• Regression tests are also applicable for each product release, after implementation. This is a process that needs to be followed after impact analysis. However, if timelines are short, critical items will be prioritised in the interest of faster turnarounds
• Conducting a final test once the entire application has been developed, to ensure that the system functions and integrates as intended
Irrespective of the individuality of each project, every Quality Assurance specialist in our team maintains the following set of best practices, in order to guide them for producing an application that is nothing short of superior quality.
1. A strategy prior to conducting any testing
Determining the course of action that needs to be taken in order to perform stringent testing is something that our QA team focuses on, so that any unforeseen hindrances are avoided during and after implementation.
2. Conducting automated and manual testing parallel to one another
As each method of testing can divulge results from varying perspectives, using both automated and manual forms of testing can provide the most comprehensive QA for software of any size or nature.
3. Using the latest QA technologies and tools
As technology rapidly expands, so does software and subsequently – the way it is tested for quality assurance. With a multitude of test, defect and release management tools out there, utilising the best ones ensures efficient results, while enabling our team to stay on par with current standards.
4. Reporting, analytics and recommendations
Monitoring the results from each test cycle and recording them for future reference is key to determining patterns and trends that QA engineers may otherwise have not been able to pick up on.
5. Requirement repository for future enhancements
Quality Assurance revolves around the business requirements that lead to the creation of any application. Monitoring each requirement, the way it was fulfilled along with any updates can significantly help business development teams ascertain how a deliverable can be enhanced for the future.
While our Quality Assurance team follows a set of standards that enable them to conduct software testing that’s accurate, efficient and timely, the processes involved for each project are also customised in order to suit individual demands and rules pertaining to every brand or business.
In addition to that, varying software development methodologies also contribute to a different set of standards that need to be adhered to, in due course of quality control and assurance. Whether your software is being formulated according to the Waterfall, Agile or Rapid method, the prime focus is always on preventing defects, especially those in terms of business-oriented requirements. This usually takes place well ahead from the actual testing phase, and even as early as the pre-sale and initial briefing stages.
Ensuring that business requirements are correct and complete enables developers to build the right functionalities. If business requirements are incorrect, subsequent features created can be difficult and expensive to fix. Identifying such glitches during the project’s infancy can thereby save companies time and money, as well as create digital products that fulfil their business objectives.
Once business requirements are established, the bulk of work is done. Only technical glitches will remain during the actual testing phase – something which developers can resolve with much ease and speed, as opposed to business requirement glitches.
Here are some more pointers that our QA folks adhere to:
• For software being developed the Agile way, it is compulsory for QA engineers to receive a demonstration of each feature that is being built, by developers. This is so that tester feedback can be provided as soon as it is available
• Conducting white box and grey box tests if time permits
Within the quality management process, there are mechanisms to improve development quality as well. This can be done via:
• Generating test metrics such as defect removal efficiency, defect density, trends across modules/features, average time taken to repair defects etc. This can then be shared with the development team to enlighten them about the nature of each bug that was found, and help them decide the measures they can take to prevent such occurrences
• Sharing test entry and exit criteria, as well as suspension and resumption criteria as applicable
• Each build should accompany developer tests, to facilitate more precise releases
Last but not the least, Quality Assurance specialists are constantly educating themselves in the midst of improving the standards of our software products. Be it software or mobile app development, every project is unique enough to teach everyone something brand new. This can be done by setting certain quality targets at the start of a project, and determining whether they were met upon conclusion.
Another simple but highly effective way to keep track of newfound theories and experiences is by embedding notes within the milestones of projects. This can be a great way to remind oneself of the lessons learned in former projects, so that the contribution to current and future projects can be significantly enhanced.
As a result, this is how our Quality Assurance team sets the benchmark in establishing superior standards for any digital product, while continuing to constantly educate themselves and stay on par with the very latest in their field of expertise.