Wednesday, May 29, 2013
Hi everyone,
I moved my website (sqaevangelist.com) to a dedicated hosting server rather than a shared hosting, so I had to get that setup today. Domain (DNS) has been setup and now just waiting for it to propagated to worldwide DNS server network. The website should be back up in less than 24 hours.
I moved my website (sqaevangelist.com) to a dedicated hosting server rather than a shared hosting, so I had to get that setup today. Domain (DNS) has been setup and now just waiting for it to propagated to worldwide DNS server network. The website should be back up in less than 24 hours.
Monday, May 27, 2013
New SQA Evangelist website
Hi everyone, I hope you are enjoying your day.
I have a new website that I have started for representation of all of us SQA professionals.
http://sqaevangelist.com/
It is still under construction, but I thought it was better to just get it out there and get some response to the content and find out what the QA community needs.
Please review and provide feedback. I need your help in making it better and understanding how it can help you in your daily SQA activities.
-m-
I have a new website that I have started for representation of all of us SQA professionals.
http://sqaevangelist.com/
It is still under construction, but I thought it was better to just get it out there and get some response to the content and find out what the QA community needs.
Please review and provide feedback. I need your help in making it better and understanding how it can help you in your daily SQA activities.
-m-
Saturday, May 25, 2013
Successful QA using Agile process - QA milestones during a sprint
Most companies are just now starting to integrate the Agile process into their software development teams, but I have seen that companies are mostly unaware of what the QA activity milestones are within each sprint.
Most of us know the typical activities of QA for a project, tasks like:
1) Create a test plan
2) Create test cases
3) Review and approve test cases with Product Management and Development team.
4) Execute tests manually
5) Perhaps even automate some of them
6) Update wiki
7) Update Story status (using something like Rally, for example)
So when do these tasks need to be done and finished within each sprint? This is the topic of this blog post. Following the milestone dates in the example is critical to the success of insuring the quality is met.
Let's say, for example, your Agile team is using 2 week sprints, or 10 working days. (It's also easier to demonstrate task time in regards to percentage using a 10-day sprint rather than a 3 week or 15 day sprint.)
Day 1-3 tasks:
1) Create test plan and test cases for each story. The test cases are determined by the QA team, Product Manager, and development team.
2) Document the test cases for each story that has QA tasks. Purpose (what is being tested), Test Case Steps, and Acceptance Criteria (what needs to happen in order to determine that the test case passed during testing) needs to be very clearly documented.
3) An email, with test case documents and/or links to all story test cases is sent to the Product Manager and development team with a request to review and approve the test cases.
4) The approval emails must be received by end of day 3 for all stories.
Milestone 1 - finished by first 30% of sprint duration: Approval of all identified Test Cases and Acceptance Criteria for all stories by all stakeholders involved.
Day 3/4 -7 tasks:
1) The time for testing a story will be different. It is entirely dependent on the size of the development task. There may be times when no mock testing can be done, or anything to prepare or be proactive until the story is ready to be tested.
Milestone 2 - Make sure that the development team sends an email to the QA person indicating when development is finished and when each story is ready to be tested in the QA environment. This is very important because the QA team must know asap when a story is ready to be tested at the earliest possible time.
2) Proactive writing of mock tests until development has completed their part of the story, if possible.
3) Updating of wiki and Agile story progress
4) Execute the test cases when story is ready to be tested in QA environment
5) Reporting of bugs found during testing
If the QA person has not received email and the story is not ready to be tested by the 60% (6 days) timeline, that is introducing risk into the quality of the product, quite simply because the QA team may not have adequate time to test the story. This risk needs to be relayed to the all involved stakeholders, so send an email indicating this.
Milestone 3 - All sprint story testing needs to be completed by the 70% (7th day) stage.
Day 8 - 10 tasks
1) Validation of fixed bugs
2) All regression testing run and determination of any bugs found.
Milestone 4 - Must verify no P1-P2 bugs exist in QA environment by 80% stage (8th day). Your team needs to determine if even P2 bugs are allowed and known into the product at this point.
3) Push the product into the staging environment. All testing needs to occur and be finished within the next 24 hours.
Milestone 5 - Must verify no P1-P2 bugs exist in the Staging environment by 90% stage (9th day). Your team needs to determine if even P2 bugs are allowed and known into the product at this point.
The final day is for story completion updates in Agile tool (Rally, etc) and updating of test case results/documentation in test case management tool (QMetry, etc). Update wiki to document any updating of test procedure changes. Send emails updating all stakeholders of final test results. Include links to any Continuous Integration test results for proof of any automated testing that might have occured also.
Milestone 6 - Assuming no P1, P2 bugs were found in staging environment testing, send email to all stakeholders that the production release can proceed and that QA is finished for all stories.
Most of us know the typical activities of QA for a project, tasks like:
1) Create a test plan
2) Create test cases
3) Review and approve test cases with Product Management and Development team.
4) Execute tests manually
5) Perhaps even automate some of them
6) Update wiki
7) Update Story status (using something like Rally, for example)
So when do these tasks need to be done and finished within each sprint? This is the topic of this blog post. Following the milestone dates in the example is critical to the success of insuring the quality is met.
Let's say, for example, your Agile team is using 2 week sprints, or 10 working days. (It's also easier to demonstrate task time in regards to percentage using a 10-day sprint rather than a 3 week or 15 day sprint.)
Day 1-3 tasks:
1) Create test plan and test cases for each story. The test cases are determined by the QA team, Product Manager, and development team.
2) Document the test cases for each story that has QA tasks. Purpose (what is being tested), Test Case Steps, and Acceptance Criteria (what needs to happen in order to determine that the test case passed during testing) needs to be very clearly documented.
3) An email, with test case documents and/or links to all story test cases is sent to the Product Manager and development team with a request to review and approve the test cases.
4) The approval emails must be received by end of day 3 for all stories.
Milestone 1 - finished by first 30% of sprint duration: Approval of all identified Test Cases and Acceptance Criteria for all stories by all stakeholders involved.
Day 3/4 -7 tasks:
1) The time for testing a story will be different. It is entirely dependent on the size of the development task. There may be times when no mock testing can be done, or anything to prepare or be proactive until the story is ready to be tested.
Milestone 2 - Make sure that the development team sends an email to the QA person indicating when development is finished and when each story is ready to be tested in the QA environment. This is very important because the QA team must know asap when a story is ready to be tested at the earliest possible time.
2) Proactive writing of mock tests until development has completed their part of the story, if possible.
3) Updating of wiki and Agile story progress
4) Execute the test cases when story is ready to be tested in QA environment
5) Reporting of bugs found during testing
If the QA person has not received email and the story is not ready to be tested by the 60% (6 days) timeline, that is introducing risk into the quality of the product, quite simply because the QA team may not have adequate time to test the story. This risk needs to be relayed to the all involved stakeholders, so send an email indicating this.
Milestone 3 - All sprint story testing needs to be completed by the 70% (7th day) stage.
Day 8 - 10 tasks
1) Validation of fixed bugs
2) All regression testing run and determination of any bugs found.
Milestone 4 - Must verify no P1-P2 bugs exist in QA environment by 80% stage (8th day). Your team needs to determine if even P2 bugs are allowed and known into the product at this point.
3) Push the product into the staging environment. All testing needs to occur and be finished within the next 24 hours.
Milestone 5 - Must verify no P1-P2 bugs exist in the Staging environment by 90% stage (9th day). Your team needs to determine if even P2 bugs are allowed and known into the product at this point.
The final day is for story completion updates in Agile tool (Rally, etc) and updating of test case results/documentation in test case management tool (QMetry, etc). Update wiki to document any updating of test procedure changes. Send emails updating all stakeholders of final test results. Include links to any Continuous Integration test results for proof of any automated testing that might have occured also.
Milestone 6 - Assuming no P1, P2 bugs were found in staging environment testing, send email to all stakeholders that the production release can proceed and that QA is finished for all stories.
The milestone completion dates are very important, especially if your team is using 2-week, or 10 day, sprints.
Even 1 day delays can introduce much risk into the product quality. You, as the QA person, are responsible for managing these timelines and doing as much as possible to reduce product stability risk.
Thursday, May 23, 2013
The goals of manual QA are not the same as test automation QA
The goal of manual (non-test-automation) QA is not necessarily the same as test automation QA.
The goal of the manual QA tester is to test as much of the product as possible, and, hopefully, find as many bugs as possible.
Test Automation is an internal corporate product solely to assist the manual QA tester in expanding their code coverage and feature testing so they can eventually focus on finding the exception case bugs (where most bugs occur - this is especially true in mobile applications). Most of these test cases are product features where test automation code is not recommended for a variety of reasons (asynchronous behavior, high maintenance costs, etc).
If your test automation test code is covering 100% testing of smoke test cases, then your company is in a great position to free up the manual tester to have the time and creativity to attack these exception test cases and hopefully find any bugs that real users will experience.
The goal of the manual QA tester is to find as many bugs as possible in the product.
The goal of test automation QA is to assist the manual QA person to expand and cover their testing of the product to the greatest possible extent without the physical use of their time. It is a tool to assist the manual QA person (who should be considered the subject matter expert and have greatest knowledge of test cases, steps to execute the test cases, and acceptance criteria) to allow for basic smoke testing and eventually, in time, expanded testing, so that the manual QA person can execute corner/exception cases which, as expected, will uncover and find most of the bugs in an application, web or mobile.
The goal of the manual QA tester is to test as much of the product as possible, and, hopefully, find as many bugs as possible.
Test Automation is an internal corporate product solely to assist the manual QA tester in expanding their code coverage and feature testing so they can eventually focus on finding the exception case bugs (where most bugs occur - this is especially true in mobile applications). Most of these test cases are product features where test automation code is not recommended for a variety of reasons (asynchronous behavior, high maintenance costs, etc).
If your test automation test code is covering 100% testing of smoke test cases, then your company is in a great position to free up the manual tester to have the time and creativity to attack these exception test cases and hopefully find any bugs that real users will experience.
The goal of the manual QA tester is to find as many bugs as possible in the product.
The goal of test automation QA is to assist the manual QA person to expand and cover their testing of the product to the greatest possible extent without the physical use of their time. It is a tool to assist the manual QA person (who should be considered the subject matter expert and have greatest knowledge of test cases, steps to execute the test cases, and acceptance criteria) to allow for basic smoke testing and eventually, in time, expanded testing, so that the manual QA person can execute corner/exception cases which, as expected, will uncover and find most of the bugs in an application, web or mobile.
Monday, May 20, 2013
Hello everyone! I have a Twitter account now! I encourage you to follow it for expert mentoring and advice on SQA/QE activites: https://twitter.com/SQAEvangelist
Subscribe to:
Posts (Atom)