QA is a continuously evolving process throughout the life of the project. QA
teams need to continuously adjust to the changes in the life cycle of the
projects and respond pro-actively and effectively. Although, there are many
processes, tools and techniques different QA managers use and imply; but the
high level process should remain the same i.e. Plan well.. Organize ...
Execute!!
Plan well and get the tools
From a client perspective, I believe, it is very important to have an independent
QA team for various reasons. Number one reason, for me, is to have an 'independent'
QA team that does not have any sort of influence from the functional/developer
side of the project. This team may include members from a third party and from
the client. Including members from the client helps in gradual knowledge
transfer from the start of the project and then, later on, deciding on the
SME's. Third party members should have ample knowledge and understanding of AX.
Whereas, the client members can provide a good insight on business processes so
this should turn out to be a good mix. Another important reason is to have an
outside opinion on the proceedings.
As a QA manager, and of course as a team member of QA, a strong emphasis
should be on planning well. If planning is not given enough weightage and
QA team/testers are thrown into testing, it is highly likely to
miss important processes.
First of all a repository i.e. Sharepoint, should be set up where all
documentation may be stored and is easily accessible to the QA team and
other stakeholders.
Another important tool required is for testing and keeping track of
Bugs/Queries/Training questions/Enhancements etc. There are many such tools
available in the market. Spirateam is an example that has the capacity to
store all this information. You can also mass upload and download incidents
(Spira Tickets) to/from Excel. But one of the issues I've seen with Spirateam
is, it's hard to Edit once uploaded. The practice we used at our client is to
download the template on Excel by adding an Add On and then working on the
tickets on Excel and uploading back the file to Spira once done.
We also need to remember planning is a continuous process and should be
adjusted in terms of time spent based on if we are planning for a new release,
if we are planning for Regression Testing or any major/minor fixes.
Organize
Next step should be to organize all the information we have in terms
of what processes need to be tested? How detailed testing do we need? Do we
need to do Unit Testing or End to End? For Regression Testing, all processes
and sub-processes should be enlisted. Functional Design Document, if maintained
and updated correctly, can be an excellent source. Release logs, again if
maintained and updated properly with details of fixes/enhancements in each
release, are another important source of information for organizing.
Planning and organizing for Time and Resources go hand in hand. Who will
be testing? How much time they will require to create the scripts and then
test? Do we require data set up? Can we copy updated data? How long would it
take to do so? What environment should be used for testing? Does that
environment has the desired configuration?
Execute
If planning, arranging for the right tools and organizing has been
given due importance, executing should be easier and smoother. One important tip while executing QA/Testing is to keep an eye open for exceptions. Sometimes you may have missed a scenario while enlisting all possible ones and while testing you see a possible scenario that can have an impact.
