Can you hear me… hellooo…

… I work with regional teams at work and obviously tele-conf calls have been a routine. Most people would tend to dial in from their computers which makes perfect for VOIP conference calls, however, I think there is still a lot of room for improvement in VOIP space, in terms of call quality, noise reduction, latency, etc. I have noticed that we often spend 10 to 15 percent of our 45minute conference call in –
> “Can you hear me?”,
> “you are breaking up”,
> ” you need to speak a bit louder please” ,
> “it is feeble” and so on…

and most funnier of all “Oh! sorry, I was on mute and the VOIP conf call window was lost on my computer” .. —> talk about multi-tasking going for mute/unmute option, conf call application gets hidden in bunch of other open applications on the computer.

Technorati Tags: VOIP,Communication technology

$10 laptop computer in schools and colleges in india…

FastCompany posts about $10/- educational laptop computer to be made available in schools and colleges across India. OLPC has come up with a One-Laptop-Per-Child-Program – see more about it here http://www.fastcompany.com/blog/chris-dannen/techwatch/indias-10-laptop

Functional Specification – a Bible?

In Software development arena, I often hear people saying, “Functional Specification document is like a Bible for us.” Well, I tend to question this statement. It is too much ambiguous to me. What does a Bible mean? Does it mean the key source of information? (note: I am not pointing to the holy Bible). I asked if that is what they meant – whether as a key source of information for application development and testing. I heard “Yes – the information in this document is fairly technical in nature and derived from the Requirements Document. ”

Great – so that means, somebody wrote the Requirements as the understanding from the Business owners. The requirements were reviewed by the business owner and the representatives, and perhaps few end users have reviewed the requirements and passed along the feedback. Let’s assume requirements on paper are according to what end users have visualized. Note – requirements might not have all the prototypes and the exact screenshots to help their imagination.

So, now, Functional document is a subset of Requirements depending on the functional ownership of the piece of application. Requirements on the other hand, supposedly, the end to end solution, as what business is looking for. Now, comes the functional dev and test teams, looking at Functional document ” so called the key source” that provides the subset of the requirements. My question is, if the key developers and testers are not even reviewing the requirements, as to what Business wants, how would they be able to translate the piece of software into what business wants. At the end of the day, what we develop is for the end users to be efficient in what they do and not become frustrated of not having the feature they were looking for.

I was often countered, “why would you even want to look at the requirements document when we are deriving the information into Functional?” my answer was “a big picture“. As a developer, at times be blindfolded on 4 key points and forget the rest

1. Object in question or to be coded
2. What are the input parameters
3. What are the output parameters
4. what are the business rules (logic) go into this object

Well, that does not work for a testing individual to know just that, to perform his job. He needs to know more and beyond the vertical object to ensure many many factors impacting or influencing due to one vertical piece. This kind of information can be obtained :

• partly from the functional,
• partly from the requirements and
• mostly from the end users or the product owner or from the user surveys depending on who the end users are.
• Additionally, having the prototypes to the end users would definitely be a big bet.

Additionally, being involved in FS development and reviewing the Requirements at the same time and having the prototypes up-front, would potentially save a lot of cycle time at the later time and potentially reduce or eliminate any re-work due to mis-representation during the requirements process. We are all humans, at times what we draw on a piece of paper might be different when translated to the prototypes and users would see in a different angle when presented with at least the prototypes than doing a visio diagram or describing 5 pages for a little dialog box kind of UI.

I just noticed a post from Shrini about testing the Requirements Heuristics. Quite informative.

In summary, please, involve the business owner and the end users as part of the functional development and through the process till the end of the development/testing cycles. This helps the end users feel they are involved and will certainly be a lot of help to the dev/test teams as part of this process and at the same time, they get what they want and be accountable for what they have asked for since they were involved in design and decision process. At the end of the day, product is something that should help the end users to be effective in their activities and not hinder their productivity with a new piece of software application.

From the dev/test teams perspective, it is the quality output that we deliver to the end users / customers (note: the term quality output might be debatable, but let’s go with whatever you define quality as. this post doesn’t go into that level.)

(note: this post was not reviewed before posting to the blog)

Dell: Hard disk partition option when ordered for new computers…

I had recently placed an order for an Inspiron 1720 with Dell. Back when I bought an Inspiron 8000 6 years ago, I was told they would not do the partition on new computers. So, I specifically enquired about the same this time, thinking if there was any change between then and now. The response I got was – No and they would still keep one single drive and no logical partitions. I literally wanted to have it partitioned when they build it so I need not to go over that rework once I receive it. Anyways, I just received it 3 days ago. Opened it up to configure it further. I noticed it was indeed partitioned with 30gig on a D: drive and the rest for C: (system drive) on a 250G m/c.

My question to Dell, why not give an option for at least one partition for the user and make it as appropriate. If they were going to make this partition for a smaller size, I would have requested for the size I wanted it to be. Now, I think I will need to start from the scratch for the size I want it to be and re-install all the programs it came with. Rep did mention about the package having CDs for all the programs they have the m/c installed with. so, I should be able to re-do it.  But it is a redundant task to scratch and re-do it.

On the other hand, DELL could rather ship a raw machine for users to install as they want it to be providing a bootable disc.

I am kind of unhappy about this re-inventing a wheel situation. Anyways, I will if I can find somebody who wants to build install operating systems from scratch 🙂

 

Enough Time and Buddy Testing for a quality output

Give time to your team to be creative and teams do the miracles. Well, it depends – you may say. This was my recent experience and I have experienced a few times before in our application development processes. Several years ago, when we first implemented the buddy testing for couple of applications, teams followed these steps

a.       Both dev and test get-together to discuss about the approach

b.      Dev team wrote the code while test team wrote the various scenarios to test a piece of application

c.       Dev completed the code with a unit testing as much as possible (no, it was not a TDD back then)

d.      Test team did a buddy testing on that piece of code

e.      Code integrated later on and released to the functional testing.

f.        Functional test team did a thorough testing on a new environment à resulting in no defects found in this environment .

5 key positive things happened during this course:

1.       Dev and test collaboration increased

2.       Dev and test teams were on the same page with respect to requirements

3.       Most defects were found as part of the buddy testing and the feedback was passed on to the dev team right then. This resulted in quality code released to the functional test, and saving the cycle time during the functional testing phase.

4.       Since dev folks been open as part of this collaboration, and increased the thought process and increased the programming quality over time.

5.       Built a Trust relationship between dev and test teams à resulting in more open and honest in accepting criticisms and better feedback comments.

Apparently, we had our team members going through similar exercises lately, and seeing better results in building the quality code. I could tell, there was more sense of satisfaction between the teams for getting things done in right way than keeping eye on the bug counts and keeping the defects slip through different functional phases.

Guidelines for Buddy Testing:

We didn’t have any specific guidelines however, we did make it up during the process.

a.       Scripted test scenarios with necessary steps and prep data

b.      Used a Heuristics cheat sheet [link] for data type scenarios

c.       Performed more functional work flow scenarios than we had scripted for.

d.      Run through the scenarios to cover the code path to some extent (note: it is a fine line, but we had scoped it for mere UI testing)

Outcome:

a.       Quick turnaround during functional testing phase

b.      User Acceptance Testing team was happy

c.       Ultimate end users were satisfied with the product they received

Next Steps that would be ideal to these dev/test teams:

a.       Other area to explore into would be TDD (Test Driven Development)

b.      Agile project management viz., SCRUM

c.       Leverage code between dev and test teams and build better automation

  

Exploratory Testing and documentation…

Talking about Exploratory testing and the project management  [link] a few weeks ago, Pradeep from Bangalore, had shared a fable about TestTrimming or shortcuts. It is a good story of what it takes to bake a cake and how shortcuts would not provide a quality outcome.

From the fable’s example, it is agreed that the 3hrs of effort is what it takes to bake a cake and no shortcuts. However, 3hrs is an estimate that was given by the baker and he/she knows it takes taht time to complete. So, back to my ad-hoc testing – considering we have provided a similar estimate and what I referred in previous paragraph as Mar 15 – what is the level of confidence to say, I can be done by then. OR, does it mean, I won’t know about it until I am done. This is something I heard from someone working on SCRUM project model.

I have also come across few articles [link1][link2] while learning about the technique / approach for ET, and i have noted that the documentation or heuristics can be used along with FTT (Features to be Tested) docs to learn about the product. I also remember reading on Satisfice or somewhere else that the last few minutes of the ET session should be kept for reporting the bugs / issues etc. I was having a similar conversation with someone recently. So our conversation was, though having the reference materials like mentioned before, how about keeping a log for what was exactly tested or at least the scenarios touched upon during the session. We had mixed thoughts, given the time constraints for the project, on

1. whether to be documented on those or not
2. if documented, then to what extent? I understand it is relative comparison. so my answer was, we need to document at a higher level to an extent of the scenarios touched upon, for others to understand the areas touched, helpful pointers as appropriate etc. And it doesn’t have to be detailed to include the sample data, outcome of that data (in case the software resulted as expected) [again “as expected” could be like from a spec]
3. why document that – because it ad-hoc and the bugs/issues will be reported anyway. –> it probably makes sense, but I probably have to disagree with this and I think it is always better to have some sort of documentation, even if it is a one liner as mentioned in #2 above – i understand there are chances of ambiguities if we start documenting things. Well again, we need to draw a line somewhere. I have also noticed a blog post by Pradeep on mixing Scripted and ET. This is another resource with good examples listed.

It looks like I am wandering around these thoughts on ET, agile, TDD, etc etc as I think about Agile project management.

So, your thoughts on ET and documentation? please share here in comments….

thanks

{tags: project management, agile , exploratory testing}

Training: Visual Studio Team System – part2

I had posted about an online training / presentation pointer that I had received from someboday before. Looking at web / MSDN blogs, I found few more such resources to learn visual studio team suite / Team foundation server.

Team System Rocks –> There are a lot of resources on this site.
Some FAQs
customizing your own process templates
Customize tool kit
MSDN – Team foundation blog

Training: Visual Studio Team System

Came across a great online audio/video training on Visual Studio Team system. I went through couple of modules yesterday and it looks great. Modules covered are: 
Overview and Architecture
Deployment and Maintenance
Extensibility
Reporting
Team Projects and Template Customization
Team foundation Version Control
Team Foundation Build
Team edition for different disciplines

I was more interested in Reporting and Template customization and going through these sections. They seem to be very good. Do take a look if you are curious to know and learn about Visual Studio Team System

 {technorati tags: VSTS, }

Taking Shortcuts in Software testing and Quality outcome…

During the conversation about project management, scope, schedule and functional disciplines with Pradeep, he pointed me to a fable titled “Test trimming“. It is very impressive. The moral of the fable is applicable for any context. It also reminds me of quotes like “Pay the price it takes”. That’s very true. Take every day examples in our lives. We get the quality for the price we pay. It could be for any service we get.

I have experienced the example quoted in this fable, at work and life many times. Depending on the context, taking shortcuts and not paying the right price only gets us into frustration. Let’s take an example of project management and scheduling: especially if you are on a waterfall model and have an end date for a deliverable, how would a schedule look like often? No matter how well project is planned, if there was no contingencies allocated, it is very likely that product analysis and requirement slips, Design slips, the difference in time gets absorbed in development phase and pushing the dev tasks into the testing task. Usually the functional testing and the user acceptance happen just before the hard end date. so, if  end date deliverable cannot be moved, guess what, testing phase gets compressed like anything. However, I was part of several negotiations where we had to build, make the teams understand on what it takes from Quality angle and readjust 2 of the triple constraints (viz., scope, schedule, cost). However, it is very interesting that we don’t see Quality in PMI’s triple constraints. well, I will get into that on a separate post.

I have been in the projects at my home town (Bangalore), and other places where people wore all the hats for waterfall. I have had titles like AnalystProgrammer. I now realize it meant, start from the requirements with the customer, do a design (no reviews), go into development and wear a test hat (kind of unit test) and work with end customer representative for user acceptance test. I wasn’t happy with the quality but I wasn’t aware of specific displines and functional teams back then. Our marketing person was our product manager. He collects the information from the customer and transfer that information to us. That’s the filter right there. We learned very hard from the consequences we had. Remember this picture, this was almost exactly what happened. Well, this was almost a decade ago; but it was a good lesson.

So, you reader, if you are involved in software project management of any sort, how do you manage your schedule, deliverables, project development, and yes,Quality?

{tags: project management, software quality }

Exploratory Testing and Project Management

I have read some material about Exploratory testing, Rapid Application Testing etc on James Bach and CemKaner’s sites. From there I also got access to Pradeep’s blog. He has very interesting scenarios, user stories, hueristics, etc that are helpful for Exploratory testing. I read something about what kind of preparation is required for such an approach. I also talked to few architects in my local area and most people were positive about it. However, most organizations do believe in test cases, test plans etc.

Preparation is the Key! – Yes I do believe in this phrase. Prepare for Great and Worse situations and you will be better off in knowing and being capable of handling either way. So what kind of preparation made in traditional waterfall testing approach? Most organizations write Test Scenarios and Test cases during the Build phase when the application is being developed. And of course, the basic reference will be the Functional Specification document.

Based on documentation, Test plan, Test cases, it is kind of helpful from the Project Management perspective on a better planning. Does it mean testing will be complete in a planned time. May be or May be Not. It completely depends on the code quality.  So then, does it mean there is a good coverage in test cases and if you blindly execute the tests / test cases, you are done testing? No – way. There is never 100% testing complete in Software world. I once heard, even an airline industry has .001 defects in their products.

So, my point is, with all these pre-planned test plans, test cases, scenarios, Test Cases reviews, corrections, addition of more scenarios etc etc, it is hard to keep up the schedule and most time we will be able to keep up the schedule as well – but at least you have something to plan against and reference against. But as I read in Exploratory Testing, the Prep time is rather used for data preparation, scenario planning etc. One said, if you are trying Exploratory testing for the first time, set aside some amount of time in project deliverable for exploratory testing. Likewise, you would be able to base your test results / execution on test cases and still be able to go through the rapid testing.

Being directed ad-hoc in nature (or may be I am not knowledgeable enough make such comments),

1. how would you plan for the execution time?
2. What kind of commitments / goals would you set to the project management?
3. How would you track the progress on your testing between a given time frame for testing? (let’s say you have 5 days on a medium sized application)
4. when and how would you know you have tested enough? (remember you have some basis in traditional test case writing approach to track on – though with constraints)
5. etc.

<updated tags>

{tags: project management, agile , exploratory testing}