Agile Testing, Exploratory, Usability

Adaptive Planning

In our efforts to manage the risks of our project, we also support change at the system or organization level by educating the organization and influencing processes, behaviors, and people in order to make the organization more effective and efficient. A more effective and efficient agile project organization equals a more productive organization that can better withstand and handle the risks and other uncertainties expected in every agile project.

With the information and intelligence gained from testing, process tailoring, and managing risks, we make adaptations and improvements. Some of the adaptation happens on the cadence and the planning processes. These are primarily based on results of periodic retrospectives about characteristics or the size, complexity, or criticality of the project deliverables and the manners in which the team collaborates and works to deliver the maximum value. Another part of risk management, testing, and process tailoring is to inspect and adapt the project plans, backlogs, and the user stories to reflect changes in requirements, schedule, budget, and shifting priorities based on team learning, delivery experiences, stakeholder feedback, and defects in order to maximize the business value delivered.

Testing, Exploratory, Usability

When executing agile projects, there is sometimes a misunderstanding about the need or lack of attention given to testing or quality assurance. Testing, quality assurance, and documentation are all crucial parts of any agile project. You cannot deliver a product that has not been tested, validated, assured against quality standards, and documented to a sufficient level. At least not as a best practice. I have seen and participated in plenty of projects where very little testing (especially in the form of end-user training), quality assurance and control, and documenting has been sparse or nonexistent. That may work in some agile projects or some companies, but eventually, you are going to get burned and have to pay the price. Avoiding testing is more laziness than good practice. A best practice is to incorporate the appropriate amount of testing, documentation, and quality management throughout the agile project. It shouldn’t be an afterthought or put off until later with the hope that you’ll get to it if you have time. Making time for it during the project is the best practice. These should be activities planned and incorporated into every iteration.

Testing in agile projects is generally classified into two categories: exploratory and usability. Exploratory testing is more about improving the tester and their ability to learn and apply better testing and optimize their work.

Accordingly, exploratory testing can be summarized as being done while the product is being tested. The tester learns to improve quality, generate new tests to run, and their own learning. This approach is better suited for experienced and knowledgeable agile development team members because it allows the tester freedom and creativity away from scripted use test cases to find out how the product actually works and explore. This ad hoc approach does not always have pre-described estimated end results to compare the actual results from a more standardized test. As the tester explores the product, he or she performs pair testing when applying the pair programming technique, observes, operates, and investigates other forms of “playing with” the product. The tester may even try to attempt to break the product to uncover bugs or dead ends.

Exploratory testing has the benefit of needing little prep time to organize or plan for, but you may also have few expectations of what to get from the test and how much time to box the effort into. Additionally, this type of testing is often more enjoyable and intellectually challenging for the tester. It’s similar to little kids taking apart a piece of equipment to see how it works or a big kid getting a new gadget and seeing all that it can and can’t do.

Usability testing is typically more structured and scripted with use cases, acceptance criteria, or some other form of test cases. Frequently, usability tests:

  • Seek to ensure the product meets its intended goal or objective
  • See that the product fulfills the actions of various pre­defined roles or personas
  • Respond as expected to inputs
  • Perform functions as a design
  • Meet business requirements
  • Mean a user can intuitively navigate or work the system
  • Are sufficiently stable and reliable
  • Achieve stakeholders’ objectives

Those are pretty much the same goals of many farms or implementations of the exploratory testing approach we just discussed. These two forms of testing exploratory and usability are often used in conjunction or concurrently.

The usability approach to testing sets out to see if the product can function as expected in order for a particular role or person to perform their job or achieve the objective from the product without failure or mishap. When failures and mishaps do occur, they are captured, recorded, and evaluated. Essentially, we are seeking to confirm the product’s usability and usefulness, and validate its warranty, or its fitness for use.

Whichever forms of testing you and your team apply to your agile project, you want to dedicate the appropriate time and resources to testing activities, whether formal scripted test cases or informal unscripted testing. You should not be relying on end users to be conducting your testing after the product has been released.

There are other forms of testing you may need to incorporate into your agile project plans. Some tests are relative to the industry your product is for or the environment it is being developed in. For example, stress testing could be necessary in your construction project as well as your software project. They are testing two different things, but at the root of each test, they are attempting to confirm whether large spikes or surges in unexpected strains or workloads on the product don’t break the product. Other forms of testing are:

  • Load testing
  • Volume testing
  • Scalability testing
  • Performance testing
  • Stability testing
  • Destructive testing
  • Smoke testing (this tests with the minimum necessary to get the product to run in order to see if it will run)
  • Regression testing
  • Sanity testing (testing to see if it worth continuing)
  • Installation testing (sees if it can be and how well it is installed)
  • Compatibility testing (tests it against other products and tools already in use and makes certain they play nicely together)
  • Accessibility testing (aims to check for usability by those with disabilities or difficulties using a similar product)

There are more types and forms of testing that your agile project could incorporate throughout the project lifecycle or for specific needs or during select iterations. This list is not intended to be an exhaustive list. However, it is a fairly substantial list that most likely covers any testing your agile project is likely to encounter or incorporate.

Leave a Reply

Your email address will not be published. Required fields are marked *