Tag: testing

“Agile teams produce a continuous stream of value, at a sustainable pace, while adapting to the changing needs of the business.” – Elisabeth Hendrickson

In this definition, “business value” refers to shippable code.  Agile teams release business value in the form of shippable code frequently at a very fast pace atleast monthly once.
“Sustainable pace” means that the agile teams continuously add capabilities to the emerging system at more or less the same velocity given no increases in team size.

Thus, Agile ensures that the code is built in a sustainable fashion to a high quality. This article explains how agile manifesto might apply to testing and the roles and responsibilities of a tester in an agile project.

“If you don’t know how to work together, whatever your defined processes, I can all but guarantee that your processes are not being followed” – James Bach

Team building should take the place of processes. The whole development team should commit to delivering a high-quality product. Testing is a key activity that should involve testers,developers and customer representatives. It is not supposed to be done by the testers in isolation. The developers need to write automated unit tests before starting to code. This approach of doing testing before coding is called Test Driven Development. In agile environment the distinction between a tester and a developer is blurred. Testers are not the solely responsible or even the primary owner of quality. Quality is a shared responsibility of the whole team. Individuals in an agile team may specialise in a particular role but will take on different roles depending on the context. Testers who are out of their depth reading code or uncomfortable influencing design decisions may require some training to fit into the agile team. The estimate for test efforts should be done as a part of the overall implementation efforts of the project.

Rigid processes sometimes tend to hinder the team’s progress towards quality goals and impose friction on people interactions. Testers need to be on their gaurd to watch out for any impact of rigid processes on quality. For a long time the focus of  testing has been short-sighted with emphasis on functional correctness rather than value to people. This problem in testing is a subset of the bigger problems of rigid processes in place. For example, in company XYZ if the tester logs a defect that lacks the support of requirement specification document, the issue is considered to be a non-issue as per the process. The tester needs to support the defect with the automated test case that failed and the spec document it violates. Otherwise the DEV doesn’t fix the issue and the test managers do not treat the defect as a priority item. In these situations there needs to be a careful risk assessment of the issue through shared conversations with the developer and high support from the management if indeed the issue falls into high risk area.



Myth #1:

Manager:  Hey Team! We are agile now, therefore the requirements are not documented

Team: No problem, we can deal with it

Having no documentation is called agile…but wait…how do we come up with an elegant, high quality code without requirements documentation. It is a myth that agile eliminates all documentation. While agile testing does not support detailed specifications, the requirements should be clearly documented at a high level though not detailed.

Conversations and shared understanding will take the place of heavy-weight documentation. For testers this could mean favoring manual tests over automated tests. This gives the testers enough freedom to discover, diagnose and exploit the product while testing. This requires exploratory testing skills. Testers should be capable of looking at the big picture from multiple angles and ask good questions that the developers and customers might think of. The rigid test scripts and procedures in automation does not reveal critical issues at times. Exploratory testing can help to spot missing features or opportunities for product improvement. The testers could collaborate with the DEV and read the automated unit tests. Instead of spending energy on the specifications and requirements document, the testers can get into the code itself.

The agile testing mind-set is all about collaborating with customers, looking at the big picture, providing and obtaining feedback. Customer collaboration is at the heart of agility. Here the testers collaborate closely with the customers. Working closely with the customers is favored over becoming a customer proxy. The testers do not merely execute against a negotiated bill of work but have iterative collaboration with the customer. The testers state the user’s point of view in team meetings and bug reports. The testers even fail the release if the quality was unacceptable to protect\defend the customer.

Myth #2:

Manager: Hey Team, the management has just decided to add twenty two new features to the product!

Team: Great! That’s good for the customer!

As an agile team we never  resist changes and can accept any amount of changes anytime…What? If twenty two new features are added to the product what happens to the stability of the product?

While agile testing adapts to changing business needs, it doesn’t encourage adding many new features that can make the code unstable and break quality. Agile focuses on delivering a small set of core features with high quality one at a time and adds the other capabilites in the subsequent releases at a fast pace. The changes should be prioritised and if required deferred to the next release.

Change is at the heart of agile projects. The testing team might be expected to follow a plan when a change has happened in the product. The plan should support the change. After a change has been implemented the testers need to test the untouched areas of the changes to ensure the ongoing stability of the product.

Static testing is the process of evaluating the sanity of the code, algorithm and documents without any execution on computer. It is the only available method to find defects in the early stages of the Software Development Life Cycle. It is completed before the implementation of code.

Static testing can be done through:
1. Walkthrough
2. Inspection
3. Informal Review
4. Technical Review

Walkthrough involves presenting a technical document in a meeting. This is a useful technique to ensure that everyone understands the product. The author of the work product calls for a meeting and presents the product to reviewers, inspection team, engineering leads, managers and other key stakeholders of the product.

Inspection is a well-known software engineering tool to improve the entire development process. In this phase we gather data on the weaknesses in the process and number of hours in correcting them using statistical process control techniques. It is a pre-requisite to reviews. It may be wasteful to do reviews unless the document has successfully exited inspection.

Reviews focus on getting consensus or buy-in to a particular document. Review is the most effective and universal test method. It could be a peer group discussion activity. In this phase the developers can find errors like unreachable code or references to variable that are not initialized. Testers can make sure that the documents (screen design, FSD) are built to standards. Incremental reviews throughout the product construction are essential and profitable method of managing quality.

Review Procedure:
1. What are we testing?

a. Requirements review
b. Feasibility review
c. Review screen layout against standards
d. Analyze program’s control and data flow
e. Existential check of the features expected as a part of the product
f. Review the screen designs, FSD

2. What are the criteria for success?

a. Check for correct and required output
b. Test environment

3. Who will do the work ? (roles & responsibilities)