Pitfalls without a Well formed QA Team (Part2)

Let us try and identify the pitfalls, when such a solution is not in place. We shall include the individual's skill set in the later point of the discussion. The below given is not going to be an exhaustive list. But these are some of the problems that we face in lieu of absence of best practices incorporated in the system.

§  The QA team could be very naive in its processes, methods, techniques and metrics.

§  Development probably could be more or less completed by the time the requirements reaches the QA team. The changes in requirements might be known only when the testcases contradicted the workflows. Since QA was not involved in the requirements stage, the following were the issues that the team will encounter

-      Critical defects defects will go unnoticed or may be closed as ‘By design’

-      Loss of time in re-designing or fixing issues

-      Significant turnaround time from development team and QA team

-      Large amount of Re-work

-      Issues had to be release noted as they are found in the last min
-   Losing the big picture
-   Failure to gauge the impact on the existing baseline 
-   Losing the long term sight
-  Push the dates further or release it as it is, only to be bombarded with the customer tickets

§  There may not be a common agreed upon format of test artifacts or deliverable or they might be the ones that was created ages ago, probably when the software was in its nascent stage. and now the current road map, objectives and the product features and the product positioning have changed. Also, the functional behavior and technologies are very different now.

§  Each member has their own way of doing things and they are very random .

§  There are little standards and procedures or templates in place. or they  were not reviewed for its gaps...

§  Microsoft excel still serves as Test case management, test execution and test report tool. Hence updating of the sheet by multiple members is a task in itself

§   Files are maintained either in remote or local fileserver across all releases.

§  Defect Tracking is done with a primitive tool that had limited features

§  QA Project plan, tracking and metrics are very disjointed and incorporating the learning from the previous project could be tough.

§  Identification of regression suite

§  There was no common place where the product, development, QA, customer support and management can get their respective queries answered.
§  Over a period of time, there is a chance that work will get monotonous and repeated updation of data in different sheets, can bring down the morale of the team and result in lack of motivation.
§  This could result in intellectual wastage 

Thus, the need for identifying, introducing, streamlining, improving the QA processes, methods, techniques and metrics is inevitable

Setting it Right - Foreword (Part1)

A naive QA team has random processes and the outcome is a chaos. The question here is how to streamline them?

I have put in my efforts to come up with an article from my past and current experiences.

It is going to be an enriching experience for me as well as the readers through this article, where a lot of thought process has been put to work and has been reflected and bounced over many times to extract the fine nuances and present this in a form that can serve as a guide for the aspiring quality professionals.

The article will aim to present a holistic picture of streamlining the QA that will include defining, deploying, identifying gaps, improving the processes, planning, execution, measurement and reporting. 

The reader may find discussions that highlight the importance of the active participation from all teams QA, dev, product, etc. Inputs from them and effective communication are crucial for the successful installation of the proposed changes and improvements 

So, how are we going to have a simple, easy to deploy  solution?
It starts with, identifying, introducing, streamlining, improving the processes, methods, techniques, reporting and metrics for any QA Team

Sorry Mr. Michael Bolten, I disagree.

When it comes to quality there are a lot of variations that we keep hearing.
Quality control, testing, quality assurance, quality assistance etc.
There was a presentation, where the focus was on the above "The difference"
The point that got emphasized is, that testers are the gate keepers, and they have no say in decision making!
Further it was added that one cannot assure quality unless one writes either code or defines requirements!!
So, the conclusion made was "tester cannot assure quality, they can only assist"
The highlight was quality control is only for the manufacturing industry it seems!!!
Then what about test driven development, dev-qa pair wise development etc...
Several internet reference were quoted regarding this and the first word that came to my mind was RIDICULOUS!
When you know the system end to end, and when changes come in, you'll question a lot about it.
About its impact, touch points, effects of the changes with respect to the context, feasibility in terms of usability, UI, predictability, consistency, performance etc.
How would it affect the existing end-users who are on the base-lined code?
It is not only the question of testing the application. Only then such doubts will arise.
When you ask the questions, you are verifying the requirements and product team benefits out of it. Also, the design gets improved.
Then how are you not helping to assure quality? Nobody is stopping you from upgrading yourself from tester to quality engineer.
For some people quality assurance is auditing, process maturity etc.
When you can question, analyze, improve, solve, learn, validate, verify, check, test, streamline, emulate, simulate, present, report etc and  address the various dimensions attributing quality, why do you want to restrict yourself? Go for it! Build your own collective skill set and common sense.
Everybody has their own definition and views on each of them. And remember they are OPINIONS.
You have every right to bounce and reflect your thoughts on the same and do some retrospection on your own.
Know the industry standard best practices, the heuristics, the empirical methods, models, research materials etc
Match it up with the work that you do and what really is expected. Happy value adding.

Defect Template

I have come up with the following defect template to ensure the uniformity among the members who are part of the testing/validation team.

Summary

1.     Issue summary should be crisp [E.g. user with option A  is not listed under the report ABC]

2.     Pre-fix the summary with the Release Index, if any. [E.g. SFXRelease - ]

Description

Test Case ID:

Customer: , Browser name, Version:

Steps to Duplicate

Pre-requisites (If any): [E.g. Option A should be available for the customer for which the user for feature 1 is being created]

Checklist for Field Validation

The following is the checklist that can be used to validate the fields for any given UI. This should be helpful for any application that has predominant number of fields.

Test Automation Framework for hosted Model - Proposal

Introduction
Test automation development is software development. Hence all the metrics would apply and the architecture, standards and procedures have to be well in place. Obviously automation suite should not have more lines of code than the application code. From the viewpoint of the automated test application, every aspect of the underlying application under test is data. Similarly, every Testcase shall be treaded as a feature
Benefits
1. Save Time
2. Reduce Human Error
3. Track of what is done
4. Compatibility Testing [eg: Browser compatibility]
5. Performance Benchmarking
6. Regression with little effort
7. ROI in the long run
Framework Proposal For MaasS360

Performance Testing

Purpose

1. To discover bottlenecks, perform capacity planning, optimize the system’s performance

Pre-Requisites

1. Scope of each PSR test
2. Timelines and environment assumptions
3. Details should be obtained from the infrastructure team like network topology diagram to assess which network segments and routers will be affected as a result of the PSR tests. [The network topology diagram and the KBs of data sent per day should help the test engineer plan and mitigate risks associated with the PSR test.]
4. List of components to be monitored like database, application servers, infrastructure etc. and respective contact persons to report the issues.
5. Find out how many KBs of data are currently being transmitted for a typical workday for all applications
6. Templates to collect Environment details
7. Get the detailed requirements to create the expected volumes of transactions and business processes within the environment for a given number of concurrent users
8. Creating a folder structure for the artifacts
9. Tool Evaluation Criteria