Task 9.1 - Top 10 tips for software testing

Here is a summary of all the key points that i picked out after listening to the CIO magazine podcast by Meredith Levison, discussing her top 10 tips for software testing.

Top 10 tips for testing:

1) Respect testers: recruit good testers; detail oriented, methodical and patient; people who know how to code (gains respect from the developers as well as enables testers to code their own tools)

2) Raise testers awareness of their value: highlight importance of testers work, amount that is saved cos of their work; improves morale

3) Co-locate testers and developers: often at odds with each other, so physical proximity is imp

4) Cross train developers and testers: fosters understanding, improves relations between both groups, and quality of apps since each group approaches their tasks with a broader understanding of the software development life cycle.

5) Tell programmers to chill out: programmers shouldnt get annoyed when faults are discovered; testers are just doing their job. Also assure developers that mistakes do not necessarily reflect on their job security.

6) Set up and independent reporting structure: don’t have testers report to the development group

7) Centralize test groups: ensures testers share best practices of testing, easy communication between testers.

8) Dedicate testers to specific systems: deepens understanding of how their systems work; also gives testers the expertise to identify problems that might not show up in a formal test document.

9) Give testers business training: allows testers to learn the business lingo, and better understand the systems they test

10) Involve business users in testing: ensure that the systems IT is developing meets their specs. Allows bugs and missing requirements to be detected that QualityAssurance have not identified

Consequences of inadequate testing:

• 
  Businesses and in some cases, lives, are at risk when organizations fail to adequately and effectively test sofware for bugs and performance issues, or to determine whether the software meets business requirements, or end users needs
• 
  There are a variety of best practices for testing software. These practices were learned from companies that have rigorous testing needs and standards.
• 
  These tips build beyond the “test early and often” mantra, and will improve IT organizations testing capabilities, not to mention the quality of the softwares that are released.
  
  
  
  

Week 3 - Studio 2

This weeks studio had 2 parts. The first part was to document and normalize the database that we had worked on in our last studio, and the second part was based on the HairCare case study that was introduced last week.

Part 1: Database Conversion

We had to do 3 things:

1. Document the schema of the old database.
2. Normalize the schema to at least 3NF.
3. Create a physical version of that new normalized database.

Task 2.1

The moment i opened the database, i realised that i had a gigantic task ahead of me. The schema was not structured in the Relational model, which i am used to, so it took a while to understand it properly.

Was the task difficult??.....

YES INDEED! There was just too much data! It took ages to sort out what pieces of info could go elsewhere, and after an hour or so, i kind of had created a new schema.
It seemed a very unrealistic task to complete, since we didnt use any tools as such to normalize this huge database. If we had a tool, im sure we would have finished it sooner, and gotten more of an understanding of the overall database schema...

i mean, this sort of thing is done in companies and organizations everyday! i wonder how they go about normalizing such huge amounts of data and information without going insane!!

hmmmmm....something to ponder over..



Part 2

Task 2.3:

My team consists myself and my friends Ken, Sheila and Ming

Discussing the nature of good teamwork..in one sentence i would say:

Dedication, experience, compromise, good communication, ideas, allocation of strengths...

Of course, theres more i can add, but at the moment, these few really stick out..

Well, we have the advantage of Ken's experience, and Sheila's sudden bursts of energy (which ends up in rly good ideas *wink wink* hehe!). Plus, we all can pretty much agree on certain issues, and come to quick resolutions on them...

All of us are pretty hard working, which i respect... so, if anyone decides to slack, im going to have to edit this post ! =D

Of course, we'll be communicating in uni, in out lectures and studios, as well as outside, when we'll have to meet up to discuss our case studies. We all live in the same neighbourhood, so finding a common place to meet up and discuss wont be that difficult.

I expect a lot of good things from this group...

So

Cmon guys! Lets earn our group points in style! =D

Week 2 - Studio 1

Hey guys!

I realized that its already week 5, so i decided to get all my portfolio material that i have so far and put it up ASAP! =D

Anyway, just to introduce the new studio concept. They're nothing like ive experienced before, with a lot more hands-on experience required from myself and my group members, as well as a lot more dedication. Its WAYYY more difficult than any lab ive attended so far...however, its a nice change to the usual practice of assignments...

SO!

hehe, no complaints so far..! =D

Alright then! On towards all the tedious tasks ahead!


Part 1: The Power of Relational Database Standards

Task 1.1:

1. I began the task by reading the database and client tasks we were supposed to do. I watched the video on how to create an ODBC link. However, remote connections are not possible..and since the server is located in Australia, and we're all the way in Malaysia, i couldnt create a link. Below are some screenshots of the process.





2. So, after that didnt work, i went on and downloaded the local copy of the database that we had to work on. There were some compatibility issues in the uni labs with MS Access, so i had to try opening it using MS Excel... and it worked! Woo! =D hehehe!

Below are some screenies i took...



Since i couldnt open the file with MS Access 2007, i tried converting the database to MS Access 2003 version... the conversion seemed to work.... BUT, for some extremely weird reason, the file STILL could not be accessed.... hmmm =\






3. When i opened the local database file with MS Excel, it worked fine.



Here is the view of the Grocery Table:




4. After going through all that, we were supposed to download an ODBS client tool. Since the lab PC's werent going to allow us to install anything anyways, i had to go home and try it out. Unfortunately, it was not very easy to use, and i got kinda lost after a while.

Summary:
Anyways, i did some research into what exactly ODBC was, and learnt how ODBC can be used as a standard which could allow applications and databases to be developed separately, yet allowing them to interface with each other, as long as the apt drivers are installed on the client.


Task 1.3:

This task is additional, but i still did it anyways...i mean, whats so crazy about getting a few more marks, eh? ;) hehe

We were provided with a chapter from a book called "The Invisible Computer" by David Norman (never heard of him..!)

It was basically about how society is moving from Technology-centered to Human Centered products...

Below are some of the key points i could extract:

1. In its early days, a technology cannot meet all the needs of its customers. Leading-edge adopters, the early adopters, need the technology, and they are willing to suffer inconvenience and high cost to get it. Meanwhile, they keep demanding better and better technology, higher and higher performance. With time, the technology matures, offering better performance, lower price, and higher reliability.

2. As the market develops, competition arises, the technology matures, and quality improves. This is the adolescent stage of a product. At some point, the technology can be taken for granted; that is, everyone has roughly comparable technology, so other dimensions of the product take on added relevance: reliability, maintenance, cost. This is where the pragmatic wave of adopters comes in, people who wait until they see whether the new technology stabilizes, whether it can actually deliver on its promises.

3. Eventually, the product reaches adulthood. It is mature, stable, reliable. Now, new dimensions are important; cost, appearance, and convenience play more important roles, with the technology and its functionality and reliability taken for granted. Now we get the late adopters, conservative purchasers who wait until the product has reached consumerhood, the final state of maturity.
Now, the product provides real value. The technology moves to the background. Convenience and reliability are more important than technological superiority. Appearance, prestige, and pride of ownership start to matter.


4. This is when companies have to transform themselves from a technology-driven to a customer-driven or a human-centered company.


In Summary:

What do late adopters want? Convenience, low cost, a good user experience. This is what Human-centered Product Development is all about.