Wednesday, August 3, 2016

Do not attend stand up but follow agile not Agile



This post is about my learning from a very short but interesting assignment I recently completed. Though I say, the lessons learned are specifically from the project, my overall experience has an influence on these thoughts.


What was the challenge?

Product’s Graphical User Interface was completely redesigned. The product was going through the frequent design changes and so, programmers were facing their own challenges. This caused a number of issues in the product. To reduce the number or at least core issues before it goes for third-party testing, an internal tester was introduced.

Challenges faced by a tester?

  1. Entered in the middle of the development cycle
  2. The product was going through frequent design changes
  3. Testing in the development environment, as no independent QA environment was available (but as I moved forward, realized that in this context testing in the development environment was a huge plus from the project outlook)
  4. Not part of any of the meetings (but sometimes this saved my time J)

Knowledge or resources available for testing?

  1. Product Knowledge: I had used the previous version of the user interface while testing the back-end of the system
  2. The older interface as a reference product
  3. Story tickets
  4. Access to programmers
  5. Freedom to conduct testing

What are the lessons learned from this challenge? 

  1. Testing without test scripts
    As I was testing within the programming cycle time frame, preferred not to write any test cases. This approach is interesting (though mine need a lot of improvement as it was not structured as mentioned by the James Bach in Structured ET). Structured ET (Exploratory Testing) cannot be learned and implemented in one go. Initially, struggled to document the tests, as I was learning and testing the product simultaneously.
     To overcome this documentation issue, execute few tests, note them, and move further.  During testing one area if you feel potential bugs in any other areas, make a note as a future opportunity
  2. Collaboration with other developers of the product
    • Who is the developer here? I feel every team member who contributes to the development of the product. So, with this understanding, all the different roles Project Lead, UI/UX Designer, Programmer, Architect, Customer, and Tester can be referred to as a developer
    • Programmers were readily available could immediately inform them about the priority defects.  I think this helps to reduce the programmer's time in understanding and fixing the issue and so project's time and money.
    •  Sometimes programmer's counter questions to the tester's observations can give more test ideas or may help the tester to avoid if she is focusing on the wrong path.
    • As a tester, our job is to log the defect against product not against any developer in the project team
    • The project team needs to understand; testing is questioning the product and see how it responds (more practical definition is "Testing is an investigation of a product to evaluate it"). So, as much information provided to the tester about the product/feature being tested will help them to test better.
    • When everybody in the team has the same goal, trivial, minor issues can be discussed and fixed without reporting. This saves the time of both tester and developer.
  3. Testing in the development environment was helpful  
    • Apart from the core issues, other functional, usability, UI issues, enhancements were also observed. This helped to reduce the feedback time as issues were identified in the development environment and within the development cycle. Otherwise in the typical process, when a bug is observed in QA environment, programmers are already in the next sprint and need to go back to the previous sprint to fix the issue
    •  

Why the title "Do not attend stand up but follow agile not Agile"?

  1. Agile: As per my reading and knowledge, Agile is a methodology which tries to introduce the communication within the project team by following a certain process. In this assignment, I did not follow any such process.
  2. agile: A word which means “Able to think and understand quickly”.  This is possible if different members of the product development team collaborate with each other to achieve the same goal, as one cannot think and understand quickly if alone. 
  3. This assignment also helped me to understand the importance of the first point “Individuals and interactions” mentioned in the AgileManifesto 

 Summary

  1. One may not go away from the scripted testing completely. However, introducing the structured exploratory testing with scripted testing can be useful. (to introduce the exploratory testing formally, one needs to understand and learn it.) 
  2.  A project needs to have the process, as the purpose of the process (as per my understanding and experience) is to help different individuals on the project team to organize themselves to give good productivity and a tracking mechanism.  So, the process is for the people, by the people who are working on a project towards a common, shared goal.
  3. When I work on my next assignment, learning from this project may be applicable or may not be. That will depend on the context of the project.
  4. In order to have every member of the project team working on a common shared goal, one aspect of the organization which can have the considerable impact is the evaluation process. Project team members should be more evaluated as a team than as an individual contributor. 

References

http://www.satisfice.com/blog/
http://enjoytesting.blogspot.in/