This week will be very similar to the previous one and you will have the same tasks, so have a look at the tasks here.
If you are the daily meeting organiser then look at the week 2 tasks to see what that entails.
If you are in the QA team then look at the week 2 QA explanation to see what that entails.
Remember the tips to a successful developer team!
Besides the normal 'working' tasks, this week has the following specific tasks:
-
- (QA) Exploratory testing
- Exploratory testing
- Debriefing
-
- (QA) Doing an exploratory test
This week we will be focusing on the topic of exploratory testing and the subsequent debriefing of it. This week there is also a practical side, it is up to you to do an exploratory testing session on your own and then plan a debriefing session with your QA lead to practice this!
It is a type of software testing where test cases are not created in advance but testers check system on the fly. They may note down ideas about what to test before test execution. The focus of exploratory testing is more on testing as a "thinking" activity. Exploratory Testing is widely used in Agile models and is all about discovery, investigation, and learning. It emphasizes personal freedom and responsibility of the individual tester.
The following course explains exploratory testing and how it's the key to effective testing:
Extra reading : Three Digestible Diagrams to Describe Exploratory Testing
Communicating your testing results is as important as testing itself, after running exploratiry testing a debriefing session is necessarily
Read what is debriefing and how it's done here:
We have gone through a few weeks of development now and even though we always try to only deliver outstanding applications there are bound to have been some bugs/inconsistencies/problems that have slipped through. This happens to the best and let's be honest here, we are not the best (yet). As a QA engineer you will want to do an exploratory test to identify parts of the application that can be improved and create issues to fix these things.
At the end of this week, you will present these findings to the team so that the product owner can decide what needs to be fixed before the final version.