Every organization, every system and every project is different, so every test project requires a unique approach. Situational testing offers various forms of testing and allows you to complete your testing projects flexibly, at the lowest possible cost and in the shortest possible time.
Among the forms of testing recognized within Situational testing are factory based testing, global scripting, session based testing, bug hunts, test tours and free style exploratory testing. Testers choose one or more of these test forms, depending on the organization, project and system. This way, Situational testing encourages you to approach testing in a flexible, structured and pragmatic fashion. With Situational testing you achieve better results than using a single specific approach.
Points to remember
How QAs work in an agile team:
Most people, even in agile teams, treat QAs as a sub-role or a separate role in the team.
I believe this is an outdated conception. The difference between a QA and a Dev lies in the mindset.
QA profiles can be sorted into three categories: Business, Technical and Dev. I call these the “Three dimensions of a QA profile”. QAs can have either one of these different profiles, or combine them according to the level of knowledge they have in each dimension.
The QAs in this dimension are really business driven. They have skills that will help their team understand the business context given by the client. They have good communication skills that will facilitate the team to focus on the business problem during the entire project.
Extracting acceptance tests from clients is one of their specialties and BDD is one of the techniques they use to break down barriers between business context from the client side and technical context from the engineers side.
They pair with developers to huddle with the client before they play stories, in order to get enough information for the story to be played. During this period, they drive the pair to write acceptance tests to make sure that the story is tested before they move it forward.
I relate to this dimension closely because the QAs here are really technical and have good analytically or programming skills. Ideally, there shouldn’t be any difference between a QA and a dev. In an agile team, everyone is an engineer and should be treated as such.
The technical QAs pair with devs to build the application without a technical gap. They support dev to foster good practices for clean code, design, and ensuring high quality product. They have a lot of knowledge on test automation and help the team choose the best test frameworks for the project. They are also responsible for making sure the team has a good test strategy in place.
The QAs in the technical dimension may also work on performance tests and security tests, depending on how advanced their knowledge on non-functional tests is. For performance tests, they work with the client and find out SLAs. They then create performance tests to measure and track the improvement done on the application related to these SLAs.
These QAs are also involved in security. They understand the business context from the client and analyze possible vulnerabilities. They then create tests to ensure that the possible vulnerabilities are being covered for a security mechanism.
How is Dev related to testing?
Short iterations help you track progress on a regular basis. It allows you to seek feedback regularly as well. Short iterations also help break the tasks down into smaller steps, thereby helping you make accurate estimates. Almost every project that I’ve worked on, we have implemented Continuous Integration. CI with a good test coverage is a must have for distributed teams. It helps you find the build issues immediately. Both teams endeavor towards a green build. CI is not about the tool, but more about the discipline and taking team responsibility to ensure a working application with every check in.
They introduce the practice of continuous delivery and help the team create a continuous integration pipeline in order to get faster feedback after each commit. This helps folks deploy new features to production more often, in some cases, they help by doing review, component tests ,functional tests before each commit goes directly into production right after successfully passing through the tests.