Lessons Learned from employers new test plan Agile Testing

These are the lessons I have learned through my exposure to the NGT:

  • Agile verses fragile– As mentioned earlier,I have seen both agile and fragile projects. Fragile is apparently the buzzword for a “fake agile” project:this is where some, but not all of the buzzwords are used,yet the test teams lack the expertise and disciplines to actually follow through and carry them out to a successful conclusion. I’ve seen some development groups totally embrace the concept and redesign, build and unit test their flagship Web site in a few weeks with no recognized testing function other than some user acceptance test(UAT) done by the project’s business analysts on behalf of the user community. They used Extreme Programming techniques. It was agile. It worked. It may not work for you but in this context it was amazingly successful and cost-effective.
  • Islands of enterprise– Many times I find that developers, business analysts, project managers, operations people, infrastructure and architecture experts are all working in isolation with no overall knowledge of the “big picture” of what the systems are supposed to do. Only in the test group does all of this expertise supposedly comes together; to perform an end-to-end test of a business process at either a systems or UAT level requires knowledge of the back-end systemsand databases, interfaces, protocols and much, much more than just the small changes developed at the front end in the Scrum. This increases the knowledge and skill levels needed in the test team. I do not believe that the software testing industry has yet found the right balance,and part of the problem is the awareness(or lack of it) of what testing is all about.
  • No one-size-fits-all solution– There are no simple answers or one size fits all.The problems are essentially the same; however,the solution within each organization is unique–it depends on the organization’s culture,level of investment,likely resistance,and buy-in from all senior stakeholders to give people time to “sharpen the axe.”
  • The value of embracing agile– In one large organization we worked with,agile has consistently delivered new and valuable(revenue-enhancing) business functionality month in,month out;it has fundamentally changed the relationship between the business and the IT group and although we normally expect UAT to be done by the users, in this case the IT group has taken on that responsibility on the users’ behalf. They will look to try and solve the problems of doing an agile development as well as coping with end-to-end testing and especially nonfunctional testing such as performance, usability, accessibility, and security.
  • Tool support for agile– The tools, methods and techniques within the industry are all starting to adapt to agile methods. We are starting to find that using commercial-strength test management and test automation tools is not as essential as it once was if you adopt the true agile principles.There are many opensource test tools available that can help.Maintaining traditional automated test scripts within a two-week sprint is a nightmare and often impossible to do well.And what value do the automated regression tests provide?Perhaps some comfort level,but do they find any new bugs or give you good information about the quality of the new code drop?Maybe the time would be better spent using exploratory techniques.(With a control mechanism like session-based test management these can be very effective in some situations).
  • Process improvement– Paradoxically the process improvement community does not yet appear to have models that will be of use in an agile environment(e.g., TPI, TMM) and yet technical capability and organizational maturity are required, in my experience, for agile to work well. Testers in the organizations I have worked with almost exclusively relied on their experience and domain knowledge to design tests, whereas I would expect agile testers to also be highly skilled test professionals; with a crazy workload they will need to use techniques to get better coverage with fewer tests, use softer skills to negotiate a better position and have the technical skills to set up their own test data and test environments.
  • Breathtaking pace– One retail web company released software three times a week at a breathtaking pace. Attempts to try and consider testing outside of the Scrum functionality for a particular sprint always seemed to get delayed until the next release, by which time all the code and impact had changed anyway.
  • Experience counts– At a U.S. software company, a small, well-funded and managed, more technically able team delivered better testing in half the time with fewer resources than a conventional test team.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics