They are in deep trouble. And we should address them now, or never. A tester’s day cannot always end with checking the pile of latest builds after his fellow developers submit code at late hours. The day also cannot start with writing a multitude of repetitive test cases, managing multiple versions of test runs, sending defect items to developers in a spreadsheet or document, and then again wait for the final builds to come in.
There has to be a better way of doing things that is faster, non-repetitive, and progressive.
Estimating Test Efforts is Always Critical
Testing effort estimation depends on a number of factors such as size of a system (in terms of function points, use case points, lines of code), types of testing (load testing, installation testing, help files testing), non-testing activities, number of test cycles and the need for scripted or exploratory testing. Estimating time for these regular activities is a challenge on its own. Any cross-tool activity and cross-team communication that adds to these core testing functions can make things practically unmanageable.
With the paradigm shift in software development culture to agile practices, and the growing needs for continuous delivery, testers’ jobs are no longer limited to writing repetitive test cases, manual test execution, frequent regression testing, manual defect submission, and continuous follow-ups with developers for re-testing the repaired code.
You cannot even expect testers to hop around analysts’ or developers’ desks, or exchange hundreds of emails in a day to maintain records of relations between source requirements, test cases, and defects.
Needless to say, a simple project in manual testing may need you to write 30-40 test cases a day, and executing 40-50 test cases per day.
So, imagine the amount of efforts needed to establish traceability relations (requirements>test>defects) for all new and existing defects raised in a day. The emergence of testing earlier into the lifecycle also keeps tester awaken throughout the project cycle.
Testing is No Longer a Sub-process
Today, QA and Testing as a functional group represents the bigger picture of Software Test Life Cycle — STLC. It is no more considered as a subset of development functions, but a standalone operation that demands quick turnarounds and uncompromised software quality. The need for process agility and continuous deployment has fueled the demand even more.
Identifying Problems is the First Step to Curing Them
The competitive nature of software delivery plans and usage of varied tools by cross-functional team members has left "Testing" nothing but a zone of uncertainties and unmanageable emergencies.
Let us see the major concerns or expectations, any testing department would have in common.
Concerns and Demands of Fellow Testers:
How do we get involved early in the overall development process?
We need an automated update whenever a business requirement is changed, the development process ends, or the defects are fixed.
How do we drill-down into the artifacts submitted by other stakeholders from different tools?
Our team needs to update analysts about the source requirements for which test cases were written and have failed, but how do we automate the feedback mechanism?
How do we automate test scheduling, test runs, and defect capturing?
Can we run test automation scripts in different tools directly from our working tool interface?
Do we need to learn new tools to exchange data with other team members?
Are our vendor-locked test tools be able to sync with other popular COTS tools like HP QC, RQM, Selenium, QTP, and more?
We want to add test requirements to our test tool directly from Excel, CSV, or 3rd party tools, but how do we do that?
Can we jointly review the test cases to detect early errors?
We want to send data to and from analysts and developers right from our own systems, but how?
How do I know which other parts of the application need retesting since I have been working on a specific part of it?
We need to continuously update our fellow developers about defects raised and track resolved defects. Can we automate the end-to-end defect tracking system?
Concerns and Demands of Test Leads:
- How do we get a consolidated test coverage report real-time?
- Can we create a standard test management workflow and automate it for process and performance enhancement?
- Our testers don’t have a single source of information to collaborate on. How do we achieve that?
- We need to send weekly reports on the cost of quality and cost of testing to our supervisors. Is the data readily available in a presentable format?
- We need to have an access to real-time reports like Defect Submission vs. Fixing vs. Closure trend, Avg. Defect Turnaround time. Is it possible through graphical charts? Can I drill down the data for detailed analysis?
Will our existing test platform support Continuous Integration (CI), as it seems really important for our agile teams? We want agile planning teams, developers, and testers to collaborate on a single system to address high-priority customer issues?
Concerns and Demands of QA Managers
- How do we optimize our testing effort, man hours, and tool usage?
- Is there a tool to guide me through the implementation of processes, procedures, and standards in the context to verification of developed software and desired requirements?
- I need a single data repository for all test artifacts across teams and project lifecycle.
- I need a well-knit platform from where all the different organizational tools across development chain can be easily accessed.
- I need to know the productivity and quality gain after introducing static code analysis, code coverage test, unit testing, and code reviews?
- Are we on track to reach the delivery deadlines set by customers?
- I need a full visibility into the test projects, team productivity, and opportunity costs across global teams.
- I need a better control on the cost of quality and delivery schedule. Are the test data readily available to work on? Are the reports and metrics easily forthcoming from intended tools?
Helping Testers and QA Leads in Need
All the above problems or needs are varied in dimensions, nature, and complexity. You cannot deploy multiple tools to cater them all at a time. Adopting an integrated set of testing and other development tool suites makes sense. Let us see what an integrated test management tool is up to.
Collaboration is the Key
Using a comprehensive platform for managing end-to-end test cycles that support automation ensures that your testing effort is always paid off, no matter how complex the testing scenarios are and how large your teams and toolsets are.
Once the entire testing team is connected to the software lifecycle tool chain, the test artifacts get exposed to other ALM tools making testing progress visible to relevant stakeholders. Similarly, developers, business analysts, and other team members can easily share their working files with testers and exchange feedbacks on each other’s work progress.
Automation Needs Another Look
Running automation test scripts is the next step to achieve momentum in testing progress. For a simple project in automation testing, a tester may need to write 8-10 test scripts and execute 5-10 test scripts per day. Testers must be able to trigger test automation scripts without leaving their preferred testing tools and thus save valuable time in an effort to achieve daily targets.
Historical Data Helps in Effort Estimation
Using a test management tool helps to compare data between current and earlier projects which aids in decision making. Such a tool also provides a top-down or a bottom-up view of testing approach to refine test effort estimation strategies.