Tag Info

I never see common agreement on any software-related titles. In some shops where I have worked "Architect" implies a thinker, not a doer. For QA Architect, it means someone who thinks about QA, researches and suggests improved methods and metrics. Sometimes it's someone who trains others. In other shops, "Architect" just means "very Senior". It's the ...

Eduard, welcome to SQA. I will assume you are that developer. I think there are a lot of ways a developer can help a QA team. The most obvious way to help would be to write automated tests or to write tools that make testing easier, e.g. creating test data or automating a deployment. You may have skills outside of coding that would also benefit your ...

A developer can be also useful to QA team in defect isolation. Having skills to read the code, understand the architecture of the system and debug a running program, you will be able to isolate the root cause of the defect you or the rest of your QA team has found. It is often faster to reproduce and isolate the issue, when you are performing the tests and ...

We have always called this bug bashes bug bashes Some guidelines we have used include: Set a date and put this on the team's schedule Provide guidance on the purpose/scope of the bash - specific area (at risk feature, globalization, security, etc) or anything goes Provide a template for filing bugs (including guidance for pri/sev, etc) Provide incentives ...

@user246 has some good options - the first that came to mind for me as well was the creation of automation and support tools. I think that another area where many test teams that I've been on could benefit is from having a deeper understanding of the system architecture and technologies. A developer has a different perspective on the system - they have more ...

That sounds like a great practice. You described at least two kinds of activities: Ten people clicking around in parallel on the same server. I would call this an informal load test. It is informal in the sense that the individuals are not coordinating their activities and may not be following a predetermined (or repeatable) process. While the process ...

One option is to have a Hackathon day between the different test teams. Hackathons come in many flavours and have different meanings to different people, so your test teams will need to figure out what does it mean to them? Ideally at the end of the Hackathon day, the different test teams should present (and share) their hackathon idea(s) to the other test ...

In the past, I've occasionally referred to this as a "Test Fest". Sometimes, I've formalized it a bit more, and even added the element of background load as well: http://www.allthingsquality.com/2010/04/automation-assisted-test-fest.html In the right circumstances, this can be a very useful practice.

Two Interesting reads, Offers great insights on Senior QA Roles What is a test architect? From John Morrison's Blog - Test Architect

Have you considered less competitive approaches to achieve your goals? Your teams may learn practical skills using deliberate techniques. I'm not sure how that increases morale (or team spirit), though. Note that for a deliberate technique to be effective, it must be: demanding targeted at improving specific areas of performance (so you must exactly know ...

The competition will not yield the results you are looking for. If you want to use it to increase bug count, you will get more bugs (and more "not a real bug" resolutions), for example. My previous experiences with in-house team competitions is that they are counter-productive and if the organization is smart, they are discontinued after a month or two ...

The term used at Microsoft and generally in the Seattle area (and undoubtedly elsewhere) is "Bug Bash". The link is to the Wikipedia article, which describes what you have described (it's not a good article at the moment, but can at least confirm that the term is used this way). The general style of testing where someone tests without test cases is called ...

In the section "Where to draw the line?" of "How to Make your Bugs Lonely: Tips on Bug Isolation" the author says: There is no clear dividing line between the bug isolation and reporting that the tester does and the debugging that the programmer does. The authors lists then: factors in favor of having testers put significant effort into isolating ...