How to use your QA Skills in a Scrum-Based Project Part 1

by Muhammad Ramzan

How to use QA skills in Scrum

The concept of multitasking and teamwork is very strong in Scrum, but there is not such a thing as ‘specialist in everything’ as people are always better in one area. Even if they know many other areas, they will never have time to do everything. Therefore, there are Developers and there are Testers.

In Scrum there is no separate phase of testing. Rather it is continuous development and testing. In Scrum, nobody is allowed to sit and wait for a delivery. Testers need to be an active member from the sprint’s start and everyone is expected to contribute.

The following are a few suggestions to a be good, proactive tester:

  • Find what requirements mean and discuss the understanding with the development team
  • Start to collect all information and learn. Capture the domain and analyze all the user stories
  • Conduct sessions when you feel there isany confusion. You should have clarity of the business and all user stories
  • Think like a QA, but behave and work like a Scrum Team member. Your  focus should always be on the quality of the product.
  • You should have the skills to know how to build a release and how to deploy the release.
  • Don’t consume much time on formal documentation like a Formal Test Plan or QA Plan.
  • Just prepare a simple Test Plan if all activities are planned in your project.
  • While developing test cases, always focus on business processes. Your test case must cover “Acceptance Criteria” of every user story.
  • Write Test Cases as fast you can, do not waste time on long elaborations / clarifications.
  • Reuse old Test Cases if possible, this can be part of a regression test
  • If daily (or personal) build is possible, start testing and probe the developed functions. If Dev. resource is not available to provide you build/release, do not wait. Build the release and start testing.
  • Make sure that for every task to be executed there is also Test Case to be written and executed.
  • Test coverage is important, so create a model
  • Remember that the sprint has an end time, so make all efforts to fulfill the time line.

Be sure to join us next time when we discuss the testing approaches that can be used in Scrum!

Testing Your Own Code

by Moinuddin Sohail

Testing your own code

This is an interesting debate. What are the results when you decide to test your own code? Will there be happy endings? The person who develops a code generally sees only happy paths due the basic human instinct where we do not want to see the negative aspects of our work and don’t really opt to go into much details in order to see where something can go wrong in our work.

The main concern of developer testing is – the possibility of not understanding the requirements. This task can fall to the customer if there is no second opinion, as in from a peer review or internal testing). If the requirements are misunderstood by a developer, then no matter how well the developers test the application, they will never find the error.

What Optimistic developers think:

I wrote the code very carefully and I am confident it is working properly. Therefore, there is no need to test this or any other path, as I know it’s working great. The problem with this line of thinking is there is a greater probability of missing errors when this mentality is being adopted.

The Developer vs The Tester

As a software developer, you always want to see your code working perfectly. So you will exhaustively test it to be sure it’s working correctly. But do you know how the tester will test the application? The tester’s job is to make it fail in any way and to find out in which ways the application might not work correctly. This is the main difference in a developer’s and a tester’s approach to testing code.

Should developers test their own work?

I personally don’t mind if developers test their own code.

After all it’s their baby and they know their code better than anyone else. They know the traps in their codes, where it can fail, where they need to concentrate more closely, and the critical path of the application. Keeping all this in mind, the developers must do the unit testing themselves.

This all goes better with a developer who likes to be a critic for their own code! But most of the developers I’ve worked with consider testing a painful job. Even they know the system well, , they tend to skip many of the validation paths because they don’t give their code a comprehensive look during code review. If the developers find any errors in their code, it is comparatively easier to fix at that point.

It is the tester’s primary responsibility to make sure each and every path is tested properly. Testers should ideally give importance to all possible details to verify that the system is not breaking anywhere. I  suggest that developers to do proper review of their code before pushing it to QA for their verification. This helps in not wasting time on all basics during the system testing phase.

Conclusion

For success of any software project, there should be an independent testing team validating all aspects of your applications.