Top 11 QA Mistakes to Avoid When Developing Software Solutions

Having years of experience, we have learned what doesn’t really work when interacting with our clients. While project managers and business analysts are primarily responsible for the overall definition of a project and its management, it is the QA engineer who’s responsible for ensuring the software is built to the customer’s specifications and operates accurately against that design, and in many cases, may find themselves engaged directly with the customer during various phases of testing and demos. This article highlights the top 11 pitfalls for QA to avoid when working with customers.

Mistake #1 — Estimating Projects Using Percentages

When estimating the size or duration of a project, be cautious calculating progress based on percentages from dev hours. Based on our experience, percentage-based planning and reporting tends to be very inaccurate and will lead to longer running projects.

The first step in any engagement is to estimate how long it will take to complete the project. We at Aristek, work with our clients to develop an initial statement of work to determine the overall scope of the project. This SOW is then used to provide an estimate in terms of cost or time depending on whether the project is fixed-priced or time and materials. Fix-priced engagements typically are prioritized around a single price with agreed upon milestones as part of the project plan. Whereas with time and materials project, estimates are based on when the project can be delivered with cost being the variable.

Mistake #2 — Not Understanding All The Project Requirements

It is imperative for you to understand the clients’ requirements at the beginning of the project and to get answers to your questions, such as end user devices, which browsers, OSes, and mobile devices need to be supported. It is not practical to build software to support every possible use case and combination of hardware and software.

Aristek provides experienced project managers and business analysts that work directly with our clients to translate their business needs into technical requirements. To ensure a smooth project kickoff and successful delivery, it is important to gather requirements as early on in the process as possible.

If the client does not know what they need, we can help them determine these requirements by researching the client’s regional market for the most commonly used technologies and if any compliance, data sovereignty, or data privacy requirements exist.

Mistake #3 — Providing Final Estimates Before Understanding All The Requirements

You should only provide customers with a final estimate after all the requirements are understood and agreed upon with the customer. We also recommend reaching out to one of our specialists to provide you with an assessment of the project to help with estimation. On average, you should factor in an additional 20% to the project timeline to cover issues and risks that may arise during the development process.

Mistake #4 — Forgetting to Include Test, Documentation & Demo Phases

Every Aristek project includes phases for performing rigorous unit and user acceptance testing, performing demos, and overall project reporting and communication with clients. These activities constitute 10-15% of a project’s timeline on average.

Mistake #5 — Excluding Sick Leave & Personal Time Off

All project plans include proper resourcing, which maps people to work tasks. When Aristek performs resource planning, we take vacation and sick leave into consideration. Given the state of the world with Covid-19 and the effect it has had on the workforce, we find it imperative to address the risk by factoring it into the project plan.

Mistake #6 — Engaging Directly With QA

Customers should never be allowed to communicate directly with our QA engineers. All communication with a customer must go through an Aristek project manager or business analyst. The foundation of a successful project and the satisfaction of our clients is built with clear, concise, and continual communication. Aristek prioritizes communication with our clients throughout the entire project. This ensures that expectations are properly set between our clients and Aristek and provides an opportunity for continual feedback to address additional feature requests or risks that may arise.

Mistake #7 — Allowing Beta Testers to Chat With QA

While it may seem like a good idea for QA to discuss software defects and findings with beta testers, it has been our experience that such opportunities never reveal any actual defects. Rather beta testers tend to request additional features or enhancements to the application or system.

Mistake #8 — Not Reporting Risk to The Schedule

It is imperative for Aristek team members to report any possible issues, risks, or concerns that may cause the project schedule to be delayed. All risks should be identified and the impact on the schedule should be understood. The development team should then put together a risk mitigation plan, which may include asking for an extension to the schedule or proposing another course of action.

Mistake #9 — Not Providing Clear & Accurate Reporting to Customers

Aristek believes that full transparency and immediate reporting increases our clients’ trust in us and provides an opportunity for additional planning or rework as necessary.

If a client wants to understand all the various aspects of the project, team members should clearly communicate how the project is managed, and how the development process works. This provides an opportunity to set clear expectations with the customer and to provide a level of transparent reporting into the development process.

Mistake #10 — Tracking Time Spent on Bug Fixes

If a client requires that time is tracked against every development task, including bug fixes, then we must explain to the customer how this is an efficient and counter-productive method for tracking project progress, and one that does not align well with agile development methodologies.

Aristek Systems employs the agile development methodology when developing projects. Traditional projects used the waterfall model, where the development and delivery of the entire project were done all at once and did not readily allow for fixes or enhancements, which tended to be very costly if not caught early on in the project.

Our clients who have traditionally done business using the waterfall model, are familiar with time tracking as part of the project. Each individual task was tracked and reported. However, with an agile project, there are many sub-projects or sprints. Tasks are more numerous and much shorter in duration, which allows for increased delivery velocity. As such, Aristek places less emphasis on time tracking at this level. Rather, the progress of a project is based on the number of features delivered during an agile sprint.

Mistake #11 — Not Accounting For Change Requests

Any change requested by a customer has an impact on the schedule. When customers request new features or changes to existing features, each must be sized appropriately in terms of level of effort and prioritized based on customer’s need or desire to have that feature. It is then up to the development team to determine what the impact to the schedule will be and then communicate that impact to the customer.

Conclusion

At Aristek Systems, our success as a company and as a partner is directly tied to the success of our customers and the relationships that have been developed. We hope this list of mistakes to avoid serves as a lessons-learned and best practices guide for our team members who are directly engaged with our customers.