Blog

Testing Best Practices.. (The Pragmatic Testing)

On October 18, 2011, in Syndicated, by Association for Software Testing
0

Originally posted at SQABlogs.com on { 02:14, 2009-Sep-9 } { Posted in Software Testing } { 0 comments } { 7867 trackbacks } { Link}

If you ask me, I would strongly disagree that there are any best practices in testing. I have worked with many companies, big or small; and in my honest opinion, there are no best practices in testing. It is always and always context driven. You follow those practices that suit and fit well in your context. If you are testing a life or mission critical software, you will adopt different strategies than testing a “Hello World” program. Isn’t it? 

I see that some people consider it quite unfortunate that we in testing do not have consistent methods, methodologies, terminologies, common ways of working etc. In a way, it is good too. Don’t you think we will not be able to think “out-of-the-box” if a speciific way of thinking is imposed on us? Okay, let me put it in a simple way. As a tester, I always needed the space and time to think beyond a developer thinks. And for this, I never wanted to be bound in some typical processes and best practices.

However, one can adopt best practices for her testing project that are common in nature. I recently asked my team to adopt to some best practices and we were successful in delivering our project. I am listing down some of those practices that we followed:

1. Training and knowledge gathering: Since the system was new for us, we prepared training documents of our understanding. These docs included presentations, checklists and word docs. We got these docs endorsed by the business. We also maintained a somwhat similar set for new joiners of the team, so that they get to know the system without bothering others.
2. Project Structure in a checklist: I asked two of my team leads to prepare the project directory staructure in such a way that it doubles up as an audit checklist. The structure was broken down till fourth level and all these levels were hyperlinked to the exact location of files. The first level was the root of the project name.

Next thing that we did was to add a new column showing options like Avaiable and Not Available. This helped us in knowing what documention was available and upto what extent. This also helped us in more effective SQA reviews. (I will be honest here, I don’t like SQA reviews. Those guys never put themselves in our shoes and don’t want to understand how we delivered the product).


3. We planned for weekly brainstorming sessions. We also made sure that one of the team members play the role of a moderator. This not only help all the team members become aware of all the project activities, but also made them more confident.

4. Checklists for resource movements: Since resource movement was very high in this programme, we made a handover-takeover checklist for the smoother transition and to bridge
the knowledge gap.

5. Mentoring: Every new or junior member was assigned to a mentor. Mentor was responsible for reviewing the email content of junior members being sent to the client. We had to do that because client interaction was high and we did not want to take risk of mis-communication to clients.

6. Query resolution Process: A formal process for query resolution was defined as the domain, the technology and the system wa new for us. We maintained a log of queries that was discussed as & when required. We made sure there are no repeat queries so that time can be saved.

7. One to One discussions:  Stakes were high and stress was high. I planned for 1:1 discussions with the team members so that they can use me as a punching bag and share their issues and concerns with me. I wanted to keep them as motivated as I could.

8. Reviews: We did at least two levels of reviews of all test artifacts so that we make less mistakes. This ensured the full coverage of testing and produced good quality test artifacts. We also made sure that every testers uses a Self-review checklist before publishing her test cases. It actually helped us minimize review and rework efforts.

9. Matrices: Since stakes were high, we had high visibility to programme stakeholders. I was supposed to publish a snapshot of testing results to programme management everyday. I used MS Excel extensively to prepare project matrices.  And we made it quite a useful document by putting n-number of formulae and hyperlinking it with other sheets and workbooks. Similar spreadsheets were prepared for Release Management too.

The points that I made to the team was to keep in mind the attributes like Quality, Traceability, Reusability, Tracking & monitoring, Performance, Team & client Satisfaction and Knowledge.

We did it!
 

Comments are closed.


Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!