Tag: agile transformation

10 Lessons When Moving from Waterfall to Agile

Nishi Grover Garg1 Comment

Many organizations take up the transition from waterfall to agile with the best intentions in mind. Like so many other companies, you might also be seeking to replace your traditional waterfall processes with agile in a quest to shorten the time-to-market and deliver high quality applications.

The road to agile, though, can be a rocky one! That’s why, in my latest refresh post for Ranorex blog, I have put together a few lessons and tips that will help you in succeeding in moving from waterfall to agile successfully!

The article was published at https://www.ranorex.com/blog/10-lessons-when-moving-from-waterfall-to-agile/

Here is a quick list of lessons we dive into-

1: Embrace the agile culture first

2: Adapt roles and responsibilities

3: Take a whole-team approach

4: Test early and often

5: Remember that agile is iterative

6: Encourage transparent communication

7: Make test automation your friend

8: Commit to early feedback and re-planning

9: Include the whole organization in the agile transformation

10: Adopt tools to enable team collaboration

Check out the complete article to read in detail about each of these learnings that can help you succeed in your agile transformation.

Cheers

Nishi

Advertisement

Read Along- ‘Agile Testing’ Chapter-21

Nishi Grover Garg2 Comments

“Key Success Factors”

Outlining some Key success factors for Agile Testing –

Success Factor -1 Use the Whole Team Approach

When the whole development team takes responsibility for testing & quality, you have a large variety of skills sets and experience levels taking on whatever testing issues might arrive.

Success Factor -2 Adopt an Agile Testing Mind-Set

Use agile principles and values to guide you. Always try the simplest approach first. Experiment with new practices, tools, and techniques.

Success Factor -3 Automate Regression Testing

Use Agile Testing Quadrants and test automation pyramid to help you automate different types of tests effectively. Experiment with different ways of getting support from management and from team members to start some tiny automation effort.

Success Factor-4 Provide and Obtain Feedback

One of the most valuable skills you can learn is how to ask for feedback on your own work. Feedback is imperative for agile teams.

Success Factor -5 Build a Foundation of Core Practices

Continuous Integration process needs to be implemented, setup test environments and manage technical debt

Success Factor -6 Collaborate with Customers

Help customers clarify and prioritize requirements, illustrating requirements with concrete examples and turning those examples into executable tests.

Success Factor -7 Look at the Big Picture

Testers tend to look at the big picture, and usually from a customer point of view, which is a big contribution to the team. Plan testing to cover all angles. Use Exploratory testing to learn more about how the application should work, and what direction your testing needs to take.

************************

And here ends my ‘Read Along’ Series for ‘Agile Testing’ by Lisa Crispin and Janet Gregory. It sure was a fun and informative read and I learnt a lot from it! I hope this series helps someone read along chapter-wise or even someone looking for quick introduction to agile testing.

Happy Testing!

Nishi

Read Along- ‘Agile Testing’ Chapter-20

Nishi Grover Garg1 Comment

“Successful Delivery”

  • It’s not enough to just code, test and say it’s done. Our goal is to deliver value to the business in a timely manner.

It is helpful to have a “Fit and Finish” checklist. Sometimes fit and finish items aren’t ready to be included in the product until close to the end. It may be necessary to rebuild parts of the product to include items such as new artwork, license or legal arrangements, digital signatures for executables, copyright dates, trademarks and logos.

It is helpful to assemble these during the last full development iteration and incorporate then into the product while continuous integration build cycles are running so that extra builds are not needed later.

  • Agile testers can serve as a conduit or facilitator when it comes to physical delivery of the software.
  • Most teams accumulate some technical debt, despite the best intentions, especially if they’re working with legacy code. To maintain velocity, your team may need to plan a refactoring iteration at regular intervals to add tests, upgrade tools and reduce technical debt.
  • Some teams resort to ‘hardening’ iterations, where they spend time only finding and fixing bugs, and they don’t introduce any new functionality. This is a last resort for keeping he application and its infrastructure solid. New teams may need an extra iteration to complete testing tasks, and if so, they budget time for that in the release plan.

I, too, have worked with Hardening Iterations and here is the article I wrote a while back about it https://testwithnishi.com/2018/10/08/optimize-your-hardening-sprint-for-a-quality-advantage/

End Game

It is the time when the team applies the finishing touches to the product.

It is not meant to be a bug-fix cycle, because you shouldn’t have any outstanding bugs by then, but that doesn’t mean you might not have one or two to fix.

  • Use the end game to do some final exploratory testing. Step back and look at the whole system and do some end-to-end scenarios.
  • As a part of the end game, your application should be deployed to staging just like you would deploy it to production.
  • Staging environments can also be used for load and performance testing, mock deploys, fail-over testing, and manual regression tests and exploratory functional testing.
  • Automating data migrations enhances your ability to test them and reduces the chance for human error.
  • Last minute disasters can happen. The team should cut the release scope if the delivery date is fixed and in jeopardy.
  • Work to prevent a “no go” situation with good planning, close collaboration, driving coding with tests, and testing as you code.
  • As a tester, it is important to understand how customers view the product, because it may affect how you test. Alpha and Beta testing may be the only time you get to interact with end users, so take advantage of the chance to learn how well the product meets their needs.

Learn from each release and take actions to make the next one to go more smoothly.

Read Along- ‘Agile Testing’ Chapter-18

Nishi Grover Garg2 Comments

“Coding and Testing”

  • The beginning of coding is a good time to start writing detailed tests.
  • As testers think of new scenarios to validate with executable tests, they also think about potential scenarios for manual exploratory testing. Make a note of these for later pursuit.
  • Some quick risk analysis can help you decide what testing to do first and where to focus your efforts.

The Power of Three Rule – When unexpected problems arise, you may need to pull in more people or even the entire team. Tester, Developer and Customer (or businesspeople) can together decide on correct behavior and solutions.

Explore It!

As soon as testable chunks of code are available, and the automated tests that guided their coding pass, take time to explore the functionality more deeply. Try different scenarios and learn more about the code’s behavior. You should have task cards for tests that critique the product both business and technology-facing. The story is not ‘done’ until all of these test types are done.

If your exploratory tests lead the team to realise that significant functionality was not covered by the stories, write new stories for future iterations. Keep a tight reign on “Scope Creep” or your team won’t have time to deliver the value you originally planned.

Technology-facing tests that critique the product are often done best during coding. This is the time to know if the design doesn’t scale or if there are security holes.

  • MANAGING DEFECTS
  • Leaving bugs festering n the code base has a negative effect on code quality, system intuitiveness, system flexibility, team morale and velocity.
  • Strive for “zero tolerance” towards bug counts.
  • Teams have solved the problem of how to handle defects in different ways.
    • Some teams put all their bugs on task cards
    • Some teams chose to write a cared, estimate it & schedule it as a story.
    • Some teams suggest adding a test for every bug
  • The more bugs you can fix immediately, the less technical debt your application generates and the less ‘defect’ inventory you have.
  • Try making the estimate for each story to include (atleast) two hours or half a day for fixing associated bugs.

If a bug is really missed functionality, choose to write a card for the bug and schedule it as a story.

Code produced test-first is fairly free of bugs by the time it is checked-in.

  • The Daily Stand-Up helps teams maintain the close communication they need.
  • Use Big, visible charts such as story boards, Burndown charts and other visual cues to help keep focus and know your status.
  • Having story boards gives your team focus suring the stand-ups or when you are talking to someone outside the team about your progress.

Communication

  • Testers can help keep the iteration progressing smoothly by helping make sure everyone is communicating enough. They can help programmers and customers find a common language.
  • Use retrospectives to evaluate whether collaboration & communication need improving and brainstorm ways to improve.
  • Teams in different locations have to make a special effort to keep each other informed.

Build Process

  • Teams take different approaches to make sure their build stays ‘green’.
  • The build needs to provide immediate feedback, so Keep It Short.
  • Tests that take too long, such as tests that update the database, functional tests above Unit level or GUI test scripts, should run in a separate build process.
  • Having a separate, continual ‘Full’ build with all of the regression suites is worth the investment.

During the iteration, you are automating new tests. As soon as these pass, add them to the Regression Suite.

As you start the iteration, make sure that test environments, test data, and test tools are in place to accommodate testing.

You may have brought in outside resources for the iteration to help with performance, security, usability or other forms of testing. Include them in stand-ups and discussions. Pair with them to help them understand the team’s objectives. This is an opportunity to pick up new skills!!

  • Consider what metrics you need during the iteration – Progress and Defect Metrics are 2 examples.
  • Whatever metrics you choose to measure – Go for Simplicity!

Read Along- ‘Agile Testing’ Chapter-17

Nishi Grover Garg2 Comments

“Iteration Kickoff”

  • Most teams kickoff their new iteration with a planning session. – where they discuss one story at a time, writing & estimating all of the tasks needed to implement it.
  • Task cards need to be written along with development task cards and estimated realistically.
  • When writing programming task cards, make sure that coding task estimates include time for writing unit tests and for all necessary testing by programmers.
  • Testers should help make sure that all necessary cards are written and they have reasonable estimates.

Your job as a tester is to make sure enough time is allocated to testing and to remind the team that testing & quality are the responsibility of the whole team. When the team decides how many stories they can deliver in an iteration, the question isn’t “How much coding can we finish?” but “How much coding and testing can we complete?”

Commit Conservatively – It is always better to bring in another story later than to drop a picked story.

  • Working closely with customers or customer proxies is one of the most important activities as an agile tester. Good communication usually takes work.
  • We want “big-picture” tests to help the programmers get started in the right direction on a story. High level tests should convey the main purpose behind the story.
  • Don’t forget to ask the programmers what they think you might have missed. What are the high-risk areas of the code? Where do they think testing should be focused?

When Testability is an issue, make it the team’s problem to solve.

One beneficial side-effect of reviewing the tests with programmers is the cross-learning that happens.

High level test cases along with executable tests you’ll write during the iteration will form the core of the application’s documentation.

People unfamiliar with agile development often have the misconception that there’s no documentation. In fact, agile projects produce usable documentation that contains executable tests and thus, is always up to date.

Read Along- ‘Agile Testing’ Chapter-16

Nishi Grover Garg1 Comment

“Hit the Ground Running”

  • Testers in agile must be proactive. Instead of waiting for work to come to them, they get up and go look for ways to contribute.
  • Working on stories in advance of the iteration may be useful for teams that are split across different geographic locations. By working ahead, there’s time to get information to everyone and give them a chance to give their input.
  • If we make our iteration planning go faster and reduce the risk of the stories we’re going to undertake, it’s worth doing some research and brainstorming before we start the iteration.

The Pre-Planning Meeting

  • Go Over stories for the next iteration
  • The Product owner explains the purpose of each story – business conditions of satisfaction.
  • Team brainstorms about potential risks and dependencies, asks questions and figures out the simplest path.
  • Pull in customers to answer questions, get a better idea.
  • Experiment with short Pre-Iteration discussions and Test-Writing sessions
  • Invest preparation time when it’s appropriate. There is a risk to ‘working ahead’.
  • To go Fast – We need to Slow Down First!

Teams that are distributed in multiple locations may do their iteration planning by conference call, online meeting or teleconference. ( And Cut to 2020 – Coronian Times – Every one of us is doing that!! )

  • One practice that Lisa’s team used was to assign each team a subset of the upcoming stories and have them write task cards in advance.

(I, too, have used this practice – only the Task Cards were in fact story Sub-tasks being created in JIRA for our user story items created by the PO)

  • If the customers aren’t readily available to answer questions and make decisions, other domain experts who are accessible at all times should be empowered to guide the team by determining priorities and expressing desired system behavior with examples.

(I have experienced that – our Product Owners essentially did this job for us)

  • Examples are an effective way to learn about and illustrate desired functionality. Using Examples, you can write high level tests to flesh out the story a bit more.
  • Mock-ups are essential for stories involving UI or a report. Ask your customers to draw up their ideas about how the page should look.
  • Before the next iteration – triage the outstanding issues with the customer. Those deemed necessary should be scheduled into the next iteration.

Read Along- ‘Agile Testing’ Chapter-13

Nishi Grover Garg1 Comment

“Why we Want to Automate Tests and What holds us back”

  • Test automation is a core agile practice. Agile projects depend on automation.
  • Manual tests take too long and are error prone.
  • Automation regression tests provide a safety net. They give feedback early & often.
  • Automated builds, deployment, version control and monitoring also go a long way toward mitigating risk and making your development process more consistent.

“Build Once, Deploy to Many” – is a tester’s dream!

Projects succeed when good people are free to do their best work. Automating tests appropriately makes that happen!

If we become complacent about our testing challenges and depend solely on automated tests to find our issues, and then just fix them enough for the test to pass – we do ourselves a disservice.

However, if we use the tests to identify problem areas and fix them the right way or refactor as needed, then we are using the safety net of automation in the right way.

When tests that illustrate examples of desired behavior are Automated, they become ‘living’ documentation of how the system actually works.

Barriers to Automate –

  • Programmer’s attitude – Why automate at all
  • The Hump of Pain – the initial learning curve
  • Initial Investment
  • Fear – Non-programming testers fear they have nothing to contribute
  • Legacy code
  • Old habits, team culture
  • Without automated regression tests, manual regression testing will continue to grow in scope and eventually may simply be ignored.
  • Teams with automated tests and build processes have a more stable velocity.
  • Good test design practices produce simple, well-designed, continually refactored, maintainable tests.
  • Team culture & history may make it harder for programmers to prioritize automation of business-facing tests than coding new features. Using Agile principles & values helps the whole team overcome barriers to test automation.

Read Along- ‘Agile Testing’ Chapter-12

Nishi Grover Garg1 Comment

“Summary of Testing Quadrants”

This chapter reviews all the four Agile Testing Quadrants by illustrating an example of a team’s success story in testing their whole system using a variety of home-grown and open source tools.

The system is related to Monitoring of Remote Oil and Gas Production Wells. The software application had a huge legacy system, with very few unit tests. The team was slowly rebuilding the application using new technology. And describes how they used tests from all four quadrants to support them.

  • Using Test Driven Development and Pair Programming wholeheartedly. Also adding unit tests and refactoring all legacy code they encountered on the way.
  • The product engineer writing acceptance tests and sharing with the developers and testers before they began creating.
  • Automation involving functional test structure, web services and embedded testing
  • Exploratory testing to supplement the automated tests to find critical issues.
  • Don’t forget to Document… but only what is useful
  • Finding ways to keep customers involved in all types of testing, even if they are remote. Have UATs and end to end tests
  • Use lessons learnt during testing to Critique the product in order to drive the development in next iterations
Agile Testing Quadrants

Read Along- ‘Agile Testing’ Chapter-9

Nishi Grover Garg1 Comment

“Toolkit for Business-Facing Tests that Support the Team”

  • As agile development has gained in popularity, we have more and more tools to help us capture and use them to write executable tests.
  • Your strategy for selecting the tools you need should be based on your team’s skill set, the technology your application uses, your team’s automation priorities, time, and budget constraints. Your strategy should NOT be based on the latest and coolest tool in the market.
  • In agile, simple solutions are usually best.
    • Some tools that can help us illustrate desired behavior with examples, brainstorm potential implementations and ripple effects and create requirements we can turn into tests are—
      • Checklists
      • Mind maps
      • Spreadsheets
      • Mockups
      • Flow diagrams
      • Software based tools
  • A picture is worth a thousand words, even in agile teams. Mock-ups show the customer’s desires more clearly than a narrative possibly could. They provide a good focal point to discussing the desired code behavior.
    • Visuals such as flow diagrams and mind maps are good ways to describe an overview of a story’s implementation, especially if it is created by a group of customers, programmers, and testers.
    • Tools such as Fit (Framework for Integrated Tests) and FitNesse were designed to facilitate collaboration and communication between the customer and development teams.
    • Finding the right electronic tools is particularly vital for distributed teams (chat, screensharing, video conferencing, calling, task boards etc.)
    • Selenium, Watir and WebTest are some examples of many open source tools available for GUI testing.
  • Home-Brewed Test Automation Tools
    • Bret Pettichord (2004) coined the term ‘home-brewed’ for tools agile teams create to meet their own unique testing needs. This allows even more customisation than an open source tool. They provide a way for non technical customer team members to write tests that are actually executable by the automated tool. Home-brewed tools are tailored to their needs, designed to minimize the total cost of ownership and often built on top of existing open source tools.

The best tools in the world won’t help if you don’t use them wisely. Test tools might make it very easy to specify tests, but whether you are specifying the right tests at the right time is up to you.

Writing detailed test cases that communicate desired behavior is both art and science.

Whenever a test fails in Continuous Integration (CI) and build process, the team’s highest priority should be to get the build passing again. Everyone should stop what they are doing and make sure that the build goes ‘green’ again. Determine if a bug has been introduced, or if the test simply needs to be updated to accommodate intentionally changed behavior. Fix the problem, check it in, and make sure all tests pass!

Experiment – so that you can find the right level of detail and the right test design for each story.

  • Keep your tests current and maintainable through refactoring.
  • Not all code is testable using automation but work with programmers to find alternative solutions to your problems.
  • Manual test scenarios can also drive programming if you share them with the programmers early. The earlier you turn them into automated tests, the faster you will realise the benefit.

Start with a simple approach, see how it works, and build on it. The important thing is to get going writing business-facing tests to support the team as you develop your product.

Read Along- ‘Agile Testing’ Chapter-8

Nishi Grover Garg2 Comments

“Business-Facing Tests that Support the Team”

A look at tests in Quadrant-2 – Business-Facing tests

Agile Testing Quadrants
  • On an agile project, the customer team and the development team strike up a conversation based on a user story.
  • Business-facing tests address business requirements. They express requirements based on examples and use a language and format that both the customer and development teams can understand. Examples form the basis of learning the desired behavior of each feature and we use those examples as the basis of our story tests in Quadrant-2
  • Business-facing tests are also called “customer-facing”,”story”,”customer” and “acceptance” tests. The term ‘acceptance tests’ should not be confused with ‘user acceptance tests’ from Quadrant-3.
  • The business-facing tests in Q-2 are written for each story before coding started, because they help the team understand what code to write.
    • Quadrant-1 activities ensure internal quality, maximize team productivity, and minimize technical debt.
    • Quadrant-2 tests define and verify external quality and help us know when we are done.

The customer tests to drive coding are generally written in executable format, and automated, so that team members can run the tests as often as they like to see if functionality works as desired.

  • Tests need to include more than the customer’s stated requirements. We need to test for post-conditions, impact on the system as a whole, and integration with other systems. We identify risks and mitigate those with our tests. All of these factors then guide our coding.
  • The tests need to be written in a way that is comprehensible to a business user yet still executable by the technical team.
  • Getting requirements right is an area where team members in many different roles can jump in to help.
  • We often forget about non-functional requirements. Testing for them may be a part of Quadrants 3 and 4, but we still need to write tests to make sure they get done.

There are conditions of satisfaction for the whole team as well as for each feature or story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. They also help identify risky assumptions and increases team’s confidence in writing & correctly estimating tasks needed to complete the story.

  • A smart incremental approach to writing customer tests that guide development is to start with a “thing-slice” that follows a happy path from one end to the other. (also called a “steel-thread” or “tracer-bullet”). This ‘steel-thread’ connects all of the components together and after it’s solid, more functionality can be added.
  • After the thin slice is working, we can write customer tests for the next chunk.
    • It’s a process of  “write tests — write code— run tests — learn”
  • Another goal of customer tests is to identify high-risk areas and make sure code is written to solidify those.
  • Experiment & find ways your team can balance using up-front detail and keeping focused on the big picture.

Quadrant-2 contains a lot of different types of tests and activities. We need the right tools to facilitate gathering, discussing, and communicating examples and tests.

>>Simple tools such as Paper or Whiteboard work well for gathering examples if the team is co-located.

>>More sophisticated tools help teams write business-facing tests that guide development in an executable, automatable format.