QA moto should be Test early & Fail fast !!
“If things are not failing, you are not innovating enough.”- Elon Musk
Testing should start as early as possible in SDLC, but WHY?
- Planning: Requirements are expressed, few meetings takes place. Then the decision is made that we are going to do this project/sprint
- Analysis & Design: BA does Analysis and designs are prepared.
- Code/Build: Now developers write the code and hand it over to QA, in waterfall model after months and in Agile mostly at end of iteration.
- Testing: Now it’s QA turn: you can start testing.
Do you think this approach is relevant today? — BIG NO
Why QA should avoid this traditional approach?
- Business don’t want to move deadlines as commitment is already done with Stakeholders.
- Mostly testing time gets shrunk from what it was planned at early stage of planning.
- As a result, testing team needs to devote extra unplanned hours to test and retest defects.
- And then there is a high chances to leave critical defects in the system because at the last moment we keep working on high Priority task without considering that there could be some task with high Severity.
Impact when defects found at later stage
Example #1:
Example #2:
According to the company, the defective ignition coil can cause misfiring, compromise vehicle performance and also could cause an electric short circuit.
So can we say now?
- The earlier we find defects, cheaper it will costs to us
- Fixes cost will be nearly ZERO if we found it in Requirement gathering or Analysis stage but will can be 100 times expensive if we found it post release.
Now what should be we do? — We should start testing early and collaborate
- Make sure to include testing part at each phase.
- Start test planning the moment the project starts.
- Start finding the bug the moment the requirements are defined. (Yes! we can find loopholes or the missing part in requirements but could have negative impact on application.
- Keep on doing that during analysis and design phase.
- Make sure testing becomes part of the development process. This is the step where we can help dev team to build application which also fulfils QA team expectation.
- And make sure all test preparation is done before you start final testing.
Verification Vs Validation
Verification: Are we building the product right?
Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure whether the product that is developed is right or not. It verifies whether the developed product fulfils the requirements that we have. Verification is static testing.
Validation: Are we building the right product?
Validation is the process of checking whether the software product is up to the mark. It is the process of checking the validation of product i.e. it checks what we are developing is the right product. It is validation process of actual and expected product. Validation is the dynamic testing.
| Verification | Validation |
| It includes checking documents, design, codes and programs. | It includes testing and validating the actual product. |
| It does not include the execution of the code. | It includes the execution of the code. |
| Methods used in verification are reviews, walkthroughs, inspections and desk-checking. | Methods used in validation are Black Box Testing, White Box Testing and non-functional testing. |
| It checks whether the software conforms to specifications or not. | It checks whether the software meets the requirements and expectations of a customer or not. |
| It can find the bugs in the early stage of the development. | It can only find the bugs that could not be found by the verification process. |
| The goal of verification is application and software architecture and specification. | The goal of validation is an actual product. |
| Quality assurance team does verification. | Validation is executed on software code with the help of testing team. |
| It comes before validation. | It comes after verification. |
So conventional testers involves themselves at validations stage only, instead of verification phase which is bigger mistake as quality control of the product/application should be done from very initial stage.
Sprint Contribution
According to Scrum.Org, fundamental unit of Scrum is small team of people, a Scrum Team and it consist of One Scrum Master, One Product owner and Developers. It means there is no concept of Sub-team and it is a cohesive unit of professional having one objective at a time “The Product Goal”.
Do you agree Scrum does not care about Job titles? — It cares
Scrum cares, we need people who can do stuff (BA, Tester, PM) to deliver value
YouTube Resource: https://www.youtube.com/watch?v=0fW8aoxyVHs&t=1590s
Another myth: there is no task for QA on the first day of sprint as there is nothing to test?
How can it be the first day of sprint and one of your team members is already out of work?
Development team (Scrum development team), should make sure that their QA resources are used to maximum potential.
What are the roles of QA people in Agile?
Agile is an approach and process which consists of a set of engineering best practices intended to allow for rapid delivery of high-quality software, so the role of tester changed enormously compared to traditional tester.
#1. Beyond the writing “Test cases”
QA people should participate and accomplish various responsibilities jointly with other team members from an end-user perspective. They are engaged right from the starting point of the project. In an absence of a Product Owner, QA should help keep the team moving forward as a proxy product owner. Moreover, they can ask questions to the Product Owner/Business to help clear up the business requirements.
#2. Participate in activity such as “Estimating Stories”
QA people can find positive and negative test scenarios which will help team for realistic effort estimation. As estimation is a difficult task, entire team should take participate and here QA people can provide feedback from their past testing experience. Collaboration between developer and tester will reduce the doubts & queries and will lead to clear requirements. As a result productivity will increase and ample amount of time will save for both development & QA team to get quality product.
#3. Interaction with developers
QA people should have excellent communication with all team members specially with developers because tester is playing crucial role in agile methodology. QA should do peer review while module/feature is in development mode also can have in person meeting for quick demo for new feature/functionality. This will help QA people to understand it and they can raise their concern/questions to development team to accommodate any scenario if they missed it.
#4. Attend all scrum ceremonies including daily scrum, sprint planning & retro
QA should sync with development team from the beginning so that they can identify the potential risk and problematic area. Involvement in daily scrum will help them to keep up to date on development/project status also they will get a chance to update team with known and critical items to focus on. Sprint retrospective are the opportunity to define weakness and determine solution for them.
#5. Don’t save all testing for the end
QA should conduct testing throughout the entire duration of sprint so that the workload can be spread out. This also allows issues to be found at early stage instead of only at the end.
#6. Document all test cases
QA is a part of agile team, it does not mean they can skip documentation. Documentation is important and specially for QA, even minimum documentation can add a lot of value to our team.
QA role in different phases of Sprint
According to definition of done, QA is the final step in whole development cycle, and there are last minutes pushes always which makes it more challenging. This could be lead to defect leakage in production and can have impact on product/feature success.
To avoid it QA should involve in sprint at early stage and can play vital role in each phase of sprint.
Sprint Grooming
As an ongoing activity, PO (product owner) and scrum team should be reviewing their backlog and ensuring the work is appropriately prioritised and contains clear requirement. This allows each piece of work/stories to be more easily planned into the sprint and can be accurately estimated.
- QA can assess the requirements and information provided.
- QA can ask questions and gather information requirement for testing
- QA can prepare information on tools and environments required for testing.
- QA can identify a list of all risk and assumption
Sprint Planning (SP1) – WHAT
At the starting of each sprint, we do sprint plan meeting and in this meeting, we as a team collectively decide what work can be committed and can be done by the end of sprint. As a tester, it will be last opportunity to ensure that we have all information we need before we start the work.
- QA can verify if proper grooming is done or not, if not they should raise a flag.
- QA should identify the missing part of the task/story (if any).
- QA should know whether the story/task is testable or not. If not they should raise it with in SP1.
- QA should identify dependency and conflict and should discuss if found any.
- QA should ensure that all requirement are well written off as based on it, team will do the estimation. Remember that Story point = Dev time + QA time.
- QA can ensure that Success criteria is clear and well written. It should be conveyed to team so that we can ensure that team is on same page.
- In general stories are written in Use-Case so QA can prepare test plan and test scenario (at least high level).
- QA can play vital role to suggest on story priority in SP1 meeting.
Sprint Planning (SP2) – HOW
AS SP2 meeting is technical in nature where scrum team discuss it in details, it is the phase where QA can brush up their technical details with more and more technical implementation details
- QA can prepare and share Test case based on the test scenario prepared in SP1. If needed test case optimization can also be done for better test coverage.
- QA can re-verify story details and in scope items to double ensure nothing is missing.
- QA can discuss Positive and negative test scenario with team to ensure expectation is same throughout the team
- Story prioritization can be discussed and adjusted again if required.
- Blockers and dependency can be raised and discussed.
Daily Scrum
Daily scrum is an event with 15 minutes duration whose main motive is to inspect progress towards Sprint goal. It improves self-management and we only focus on “What we did yesterday”, “what are the plan for today” and “Impediments/hurdles (if any)”.
- As daily scrum improve communication, QA should raise each and every impediments. Detailed discussion can be after daily scrum.
- QA team should have clear indication what they are going to pick next.
- Any blocker or concern should be raised by QA.
