Skip to main content

FAQ

We have summarized most common questions you might want to explore below.

What tools can I use for test management and where can I get them?

There are quite a few test management tools available in the market that can ease the task and help introduce useful metrics and collaborations into daily operations. You can read a blog article “Top 10 Test Management Tools—Free & Paid Options” to learn more about the capabilities and usefulness of the tools. The blog will show the difference of the tools and also explain how to choose the right one for the project.

What is a formal approach to risk management?

There should be at least some degree of formality in the risk management strategies within the projects to ensure that the risks are communicated with the whole team and are addressed accordingly. The risk management consists of five main phases - planning, identification, analysis, mitigation, and monitoring/control. Each of the phases should be coordinated with such activities:

  • Planning - in the estimation planning, there has to be a time buffer appropriate to the possible risks that can occur. Consider additional time for the project activities.
  • Identification - identify the risks possible in the project or activity, understand possible and the most important risks that would negatively affect the project outcome.
  • Analysis - analyze the risks while assessing their probability and impact. Try to be precise on the impact and understand how expected the event is, try to understand the triggers that could be identified earlier. Prioritize the risk mitigation based on the risk score.
  • Mitigation - go through the risks and try to mitigate, transfer or avoid said risks with appropriate planning for the project. In case, if the risk cannot be mitigated, plan a contingency plan for the risk event.
  • Monitoring & Control - throughout the project, periodically, reassess existing and identify new risks appropriately to the current state of the project or activity. Monitor if the risk assessments were accurate and mitigation plans successful.

Keep in mind that a risk management plan should be communicated with the whole team. The processes of each phase can be formalized appropriately to project needs. In the future, company standards might be introduced.

What are the most common risks the project can face?

Risk: Test environment not ready on time

  • Description: The environment for the testing is not prepared on time by the clients or is not functional on time due to an internal team delay.
  • Mitigation / Response: Agreement with the client about the availability of Test environment and Test builds, as well as about mechanisms and procedures in case they are not. SPOC should be defined from the client side, who could be contacted in case of an issue. Environment from the TestDevLab side should be planned and prepared ahead in the timely manner.

Risk: Devices are not available

  • Description: Device availability is not properly managed, or delivery is delayed.
  • Mitigation / Response: An agreement with the client must be made in regard to what devices are necessary for testing or, in case the client doesn't have specific requirements, TestDevLab team must offer a reasonable amount of devices to cover and as many as possible Manufacturer/Model/OS version configurations. The availability should be arranged and discussed beforehand.

Risk: Sudden QA shortage

  • Description: QA engineers are on sick leave or cannot come to work unexpectedly.
  • Mitigation / Response: TestDevLab has procedures in place, so that, in case of necessity, any team member could be replaced by another. The replacement should be warned about such roles and should be prepared accordingly.

Risk: Limited availability of stakeholders

  • Description: Clients or other stakeholders are not responsive to the issue in one or more communication channels which directly affect the schedule of the project.
  • Mitigation / Response: An agreement with the client must be made, and a dedicated SPOC must be allocated to assist the TestDevLab team. Ideally, more than one communication channel should be possible with the ability to contact in a very efficient manner.

Risk: Insufficient scope coverage

  • Description: Proposed and agreed scope found to be not sufficient in the middle of the project processes.
  • Mitigation / Response: Scope should be aligned and traceable to project requirements and goals. It must be approved by clients and reviewed throughout the project to ensure that the goals are being met.

Risk: Poor scheduling

  • Description: Schedule does not showcase the reality, the deadlines are not met, or the processes take longer than expected.
  • Mitigation / Response: Time buffer for risks events or longer actions should be calculated for tasks within the projects to cover the most probable risks. Any discrepancies of the timings should be communicated to the clients and new deadlines should be set and approved from both sides.

Risk: Infrastructure downtime

  • Description: Unexpected failure of the network infrastructure or hardware that directly impacts project deadlines.
  • Mitigation / Response: Time buffer for risks events or longer actions should be calculated for tasks within the projects to cover the most probable risks.

The examples mentioned should be treated as examples and, when applied to a project, should be modified accordingly. Please make sure to evaluate other risks for the project as well.

How to decide which approach works best for the client - manual or automation testing?

The most important thing is to understand the bigger picture for the tests that are necessary for the client. While automation can be efficient, the benefits of such testing come out more in a long term partnership, especially if the automation setup is tailored and customized. There are multiple factors to take into account when deciding on the best approach:

  • Consistency - very strict consistency in the testing might require choosing automation, as it disregards human error and can complete the same task the same way all the time. If consistency is needed, but together with human touch to ensure human factors in the equation, then manual testing would be the way to go.
  • Amount of regression - if the primary idea for the project is to do regression testing that is consistent and rarely changes, creating automation for this would be a good idea. However, if the tests request bigger flexibility and change unexpectedly, then manual testing might be more advantageous.
  • Nature of the tests - clients usually have some kind of understanding, what is more important to them, to do a lot of tests efficiently or have a subjective opinion from the tester as well, as both give different benefits. Understanding the goals and objectives of the project might help to understand the best approach.

Additionally, you can check out the TestDevLab blog about this topic.