Tuesday, 23 May 2017

When should a tester engage in testing?

Test Early
Image Credit: https://cdn-images-1.medium.com
- Why should I hire testers at an early stage of a project and not just during the testing phase?
- Why should I let my testers test early?
- How can I hire and retain testers?

- How testers can evolve as PRODUCT ENGINEERS?

- And finally, why software testing is not a boring job?

Here is an attempt I made to address these questions.
As far back as my memory goes, I have been an advocate of testers involving themselves in the SDLC right from the beginning of a project. I have questioned when no testers were invited to the Architecture Review Board meeting at a previous firm that I earlier worked with.
I strongly wish that testers start contributing to a project from it’s discovery phase. Right from when the decision is made to build the software. This means that we do contribute to building the product right from the beginning and are not mere time wasters of programmers (coder/designer) who have already spent considerable amount of time learning about the product, data modelling, coding, unit testing and deploying the code to the test server. And who then will have to pass on all the (or filtered) knowledge to a tester just before or during the testing cycle. Does it annoy you as a programmer?
Point to ponder here: Is this the reason why programmers are paid more as compared to the testers? Let me restate it for the testers: Is this the reason why the testers are paid less as compared to the programmers?
Moving on: How can I as a tester contribute from the beginning of a project?
Here are some solutions on how testers can collaborate with the client / Product Owner, programmer, designer, SEO engineer, security analyst and contribute to each phase of software development.
Requirement Gathering Cycle
When the client / product owner shares the requirement, resolve to this:
As a tester, I want to refine these requirements based on quality criteria so that I will not contribute to cost, effort and time wasted at the last phase of a project.
And do thisShare a clarifications log with the client with the assumptions, clarifications and suggestions to enhance the requirement.
The clarification log can consist of columns in a sheet with these details:

|Query |Clarification by the client / Product Owner |Priority| Implemented in sprint|
Example: The user is able to download the report. 
As a tester, you can ask:

Query |By user do we mean a guest user or a logged in user in this context?
Clarification by the client / Product Owner | Both the guest user and the logged in user
Priority | Low / Medium / High 
Implemented in Sprint | Sprint number

Above is an example of the clarification(log) which we maintained throughout the product life cycle by the whole team in a startup I worked at. The programmers then become better equipped to add both the scenarios of making the report available for a logged in and a guest user.
Understand and refine the requirement/s when we receive it so that as a tester you can start contributing to the quality of the product and build credibility for yourself right from the early stages.
Design Cycle
Develop skills required to test the design / wire-frames. Some references are below:
Test for user flows / navigation, user behavior in the design cycle. Do not wait until the end of functional testing to begin with User Interface and User Experience testing. We are responsible for a user forming good habits when they use the software built. Let us make every click count :)
Development Cycle
Test the code that is being developed for missing validations, known vulnerabilities and bugs, ask for access to the code, database and learn what is being implemented as part of a fix and what is the impact of the fix. This helps us as testers to learn about the fix and the impact early on. And help identify a bug during the coding cycle and in fixing it then rather than wait for the fix to be made, unit tested and deployed on to the test server to be tested and then for the bug to be logged in the bug logging system to be fixed and re-tested.
This to me sounds like waste of valuable time for all involved.
Testing Cycle
Now that a lot of time has been invested by you in testing at different cycles of the project, utilize the testing time effectively to test the system post integration. Take time to learn about effective bug logging, interactions with the application, it’s users and invest time to gather user feedback and enhance the product suitably.
Release Cycle
Proceed confidently to the release cycle. Take time to test the release notes in dev/test/beta phase. Check for version numbers, fixed bugs section, whether adding this information creates an impact, can we do away without adding the trivial details. Those users who will read the release notes (which is not equal to the number of downloads) are unforgiving if there is nothing new that they can learn post reading the notes. Add value by bug logging and enhancing the product quality at this stage too.
Maintenance Cycle
Use this time to work on those low priority bugs and get it fixed and re-tested along with the other bugs found by the team / user feedback / suggestions / user reviews that you read.
Invest time earned to learn, take testing courses, give talks, attend webinars and conferences, invite users to test and to gather another test idea. Up-skill to remain relevant in the ever changing and ever growing industry.
Investing early efforts to test can help address major problems which we are facing as testers.
1. No time to test.
2. Building credibility early on.
3. Knowing that this credibility eventually gets translated to respect and testers being treated equally with the other roles in an organization.

My question for you today is: Do you recognize valuable respected testers around you? 
If yes, make them your mentors today. They are waiting for you too :)
Earlier published : https://blog.whyable.com/test-early-904c337696f1