Showing posts with label software testing ideas. Show all posts
Showing posts with label software testing ideas. Show all posts

Monday, August 11, 2014

My First Thirty Days as a Test Lead: Expectations and Reality

Starting a new job is a little stressful but a lot exciting. Whether I left a job because of something positive or negative, there are high hopes for what I might learn and work on in my new role.
I recently started with a new company, filling a role I have never had in title: test lead. I wrote this over a thirty-day period while observing what really happens when changing jobs, not just what you’ll see in the new-hire paperwork. My goal during this month is to become as effective as possible in a short period of time without draining resources by having someone sit with me constantly.
Defining Your Role and Setting Expectations
What you see in the job listing you applied to, what you’re told you might be doing during the interview, and what you actually end up doing are all a little bit different. A typical tester job advertisement will say something about writing and executing test cases, maybe with a list of desirable skills. That doesn’t tell you a whole lot about the conditions you’ll be using that stuff in, though.
Defining your role is finding where what was written down and what you were told intersect with how you will actually work. Maybe you excel at a certain type of testing; maybe you want to work paired up with a developer; maybe you have a mind for usability and want to work with the design team a lot; maybe there is a group of developers you groove with. The first thirty days is a great time to explore where you fit and how you can be useful to the team.
My new job was described as a lead for an existing test group. I’ve never been in a lead position before and companies seem to have varying expectations for this role, so I spent a lot of time learning about and setting requirements.
To move this process along, I set up a weekly one-on-one meeting with my supervisor to talk about what I’m doing and what I plan to do and see how that matches up with his vision. This was a nice, informal chat, and the end result was both of us having a good understanding of each others expectations.
When I applied, there were actually no job specifications. A friend saw a Twitter post and generously mentioned me. I sent an email to the company giving a brief introduction along with an invitation to chat on the phone. Because there was no description of what the position required, we spent a lot of time talking and figuring out what each party wanted.
My expectation for this (or any) job is that I would get to do self-directed work on challenging projects with motivated teams, with the possibility of jumping between projects as needed because I really like variety in work. My new employer had the expectations that I would do some coaching and training and bring fresh perspectives and ideas to the organization, in addition to my normal testing work.
One potential conflict was that they were looking for someone to fill a management role. I love doing hands-on testing and was not really interested in managing people 100 percent of the time at that point. Knowing expectations on both sides saved them from being disappointed and me from being unhappy.
I had similar chats with my new test team to see how their test lives were going, what they wanted to learn about, and how I could help them be awesome. I make it a point to see how they are doing every few days, but not so often as to crowd them. These conversations are fun. The test group is two people at this point. Both of them are interested in learning about testing as a craft, so I started planting seeds of ideas like moving from traditional test cases to session notes, using mind maps to develop test ideas, and bug reporting as a skill. A culture that welcomes positive change made these talks easy.
To read more My First Thirty Days as a Test Lead click here 

18 Testing Challenges from Santhosh Tuppad - Part I

My friend cum colleague Santhosh Tuppad posted 18 testing challenges to the testing community on his blog a month ago. I have had lengthy conversations on security testing with Santhosh for a while now. The work that follows in this blog post is dedicated to him as I learned a lot about security and usability from him. I wasn't too happy when I asked him a lot of questions on his test challenges where the context was not clear. He clearly mentioned that he wants me to let my imagination free and work on the challenge. There you go.

1. What if you click on something (A hyperlink) and to process or navigate to that webpage you need to be signed in? Currently, you are not signed in. Should you be taken to Sign up form or Sign in form? What is the better solution that you can provide?

Why take the user to Sign In page? 
I always face this problem on FashionandYou :-). If I had to click on a hyperlink which required me to Sign in, I expect to be taken to the Sign In page where a message “This requires you to be logged in” is displayed to me. This solution offers 2 benefits - one, it tells me why I am taken to Sign In page. Two, it takes me to the correct page. 

Why not take the user to Sign Up page?
It’s incorrect to assume that all users who are not logged in are new users. There could be few existing users who are interested to browse without logging in. Taking existing users to the Sign Up page might offend the users.

Why display a message while taking the user to Sign In Page?
Some users won’t understand why clicking on a hyperlink is taking them to the Sign In page. It’s better to display a short and crisp message to the user about the need to login to view that page. Please note that forcing users to login to view the content on retail websites is a bad idea. Users must be allowed to login if they need to make a payment or save something to their cart. Eg. Flipkart.

Why not display a dialog with a message while taking the user to Sign In Page?
A dialog just to convey a message is an overhead. Expecting the user to perform an additional step to click ‘Ok’ or whatsoever is a bad usability expectation.

To read more about 18 Testing Challenges click here.