DevQAExpert

Menu

Work Process

01. Discuss

A project cannot take off without having a clear requirement. This is the most crucial phase where ideas need to get written in a well-understandable and formatted document. If you are part of a project where you are participating in the requirement-gathering phase, then consider yourself lucky.

Wondering Why? It is because you are witnessing a project in making from scratch. Though there is pride in being since inception, it comes with some responsibilities and challenges too.

Challenges

A lot of discussions will happen, some of which may be simply irrelevant to your project but even then they may contain some vital information for your project. Sometimes the speed of discussions may exceed your grasping capabilities or you would simply not pay attention to the product owner

One cannot imagine all the requirements to gather in a single sitting. Be patient enough.

 

 02. Test Strategy

Testers are supposed to come out with a test strategy that is not just sufficient to test the software better but should also instill confidence in every stakeholder regarding the quality of the product.

Challenges

The most crucial aspect of this phase is to create a strategy that when worked upon should deliver a software product that is error-free, sustainable, and accepted by its end users.

Test strategies are something you will not change every other day. In some cases, you need to discuss your test strategies with the customers also. So this part should be dealt with with high importance.

Best practices

  • Here are some of the best practices, which when followed can provide you great relief and result in smooth testing.
  • Go through the requirement document once again. Highlight the import points with respect to the environment of the target software.
  • Make a list of environments where the software will actually be deployed.
  • Environments can be understood as a type of Operating system or Mobile Devices.
  • If Windows is the operating system, list down all the versions of the window where you will be testing your software. If the versions viz. Windows 7, Windows 10, or Windows Server(s) are still not defined in the requirement document, then it is high time when these should be discussed.
  • On a similar note, get the target browsers with the versions discussed and documented if the AUT is a web-based system.
  • Make a list of all the third-party software that the application will need (If required/supported). These may include Adobe Acrobat, Microsoft Office, any add-ons, etc.

Here the idea behind this is to keep every necessary and required platform, device, and software that our application will need to function before us so that a comprehensive strategy can be formulated.

 

 03. Production

Finally, your application build is out and you are ready to find bugs! Now it’s’ time to work on test planning and find as many bugs as possible. There will be some phases in between if you work in an agile environment, then simply follow those scrum methods.

Challenges

Testing is a cumbersome process that itself is error-prone! One finds many challenges while testing an application. Given below are some best practices to rescue.

Best Practices

Cheer up! You are trying to find defects in the code. You need to pay attention to the overall working of the software.

  • It’s always advisable to look at the application with a fresh look, WITHOUT GOING THROUGH TEST CASES.
  • Follow the navigation path of your software (AUT).
  • Get yourself familiar with AUT.
  • Now read the test cases (All) of any particular module (Maybe of your choice).
  • Now go to the AUT and match the findings with those mentioned in the expected section of the test cases.
  • The idea behind this is to test every mentioned feature on every supported platform.
  • Make a note of every deviation however trivial it seems to be.
  • Write down the steps on how you reach any deviation, take screenshots, capture error logs, server logs, and any other supporting documentation which can prove the existence of defects.
  • Don’t hesitate to ask. Though you have the requirement document, there will be times when you will be in doubt.
  • Reach out to the developers (if they sit next to you or they are reachable) in doubt before you reach out to the Product Owner. Understand the developer’s perspective on the working of the software. Understand them. If you feel this implementation is not according to the requirement, then inform the test manager.

 

04. Release

Finally, the time comes when we have to deliver the product to its intended users. We all as a team have worked hard to sign off the product and let the software help its users.

Challenges

Software test engineers are primarily responsible for the release of any software. This activity requires a process-oriented workflow. Here are some of the best practices that are involved in this phase.

Best Practices

  • Always remember, you are not working on the release document on the date of ACTUAL RELEASE.
  • Always plan the release activity prior to the actual release date.
  • Standardize the document as per the company policies.
  • Your release document should try to establish positive expectations from the software.
  • Mention all the software and hardware requirements with specific to their versions clearly in the document.
  • Include all the open defects and their severity.
  • Do not hide major impacted areas due to open defects. Give them a place in the Release document.
  • Get the document reviewed and digitally signed [may differ as per company policy].
  • Be confident and ship the release document along with the software.

 

Thanks