Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Tuesday, December 25, 2018

Manual Testing vs. Automated Tesing: How They Work

Mike Cohn and others divide testing into 4 types: Automated and Manual Testing, Automated, Manual, and Tool-Based. I suppose a footnote belongs here, but as this little tidbit is as much from experience and a variety of media as it is his book (I am not sure which one, sorry).

Manual testing vs. Automated Testing

Automated and Manual Testing involved prototyping, simulations, functional testing, and user story testing. I personally extend this to service testing (interface testing, touch point testing, etc). For all of these, we have information driving acceptance criteria (did it pass?) and the creation of the test (what are we trying to do?) These lead to trackable bugs and potentially, issues. “Fail fast” is made easy by prototyping. 

Automated Testing includes having a Continuous Integration server, Unit tests (this is looking at and optimizing actual code in an XP peer programming model or not and specifically not doing manual testing where you enter orders or send an email to multiple recipients), and Component testing (also done in Tool-driven testing if you have systems within the System configured in a way to allow for it). Your CPU and compiler will tell you a lot. Automatic processes should be set up so that they take place before anything goes live (or even into a sandbox environment). I have seen development shops where if one of these tests failed, a flashing red light went off and in Toyota’s “stop the line” fashion (“Everyone stops developing and looks at this!”) people fix what is broken before taking one more step. These lead to trackable bugs and potentially, issues, however, these are more likely to be pounced upon immediately because you do not want something icky in the soup, so to speak.


Manual testing is what we have been calling Unit testing: poking at the GUI, verifying data is validated, things work from a UX/UI perspective, UAT (User Acceptance Testing), and others. UAT is the most important in my opinion. The vendor shows the Client functionality and it either passes or fails. You can have formal acceptance criteria (unscrupulous vendors mandate defined and exact Scope as well as the leverage inherent in highly detailed acceptance criteria). When I am representing a Client who interfaces with vendors, I try to steer clear of hard acceptance criteria and change orders and instead I lean towards a reality where things change even if they are correct according to original spec. Clients have had bugs marked as fixed before anyone at the Client even checked or were able to check. This creates haze, and bugs are lost among larger issues, and the excuse is valid, a natural extension of chaos. Vendors have a professional responsibility, and this is not my opinion. A company I worked for lost a court case because they did not perform what the court considered part of their responsibility as a solutions provider: proper management of issues. That is why I stopped working for development shops. Being honest and forthright costs consulting teams money because delivering something measurable that cannot remain the same but must pretend to hold shape will lead to change orders and cries of “OOS! (Out of Scope)” while defining the system in terms of what it has to do at a high level leaves room for change in ways that do not impact behaviour. Maintenance contracts bring in a lot of revenue.

Finally, there is Tool-driven testing. This is load testing, security testing, and hardware testing. This is stuff that your point a tool at and let it crank away and come back with analysis. All projects have a front end that is connected to a back end (not ALL I guess) which is why separating the sites from SAP has always been something I have not understood and so Tool-driven testing is extremely important). Also in this group would be analytics, for SEO, SEM, E-commerce stats, etc).
So I would first recommend enforcing a real, proper, full lifecycle SDLC (Agile if the project is new but if the project is not new, something as close to what exists) and in doing that, most of the testing problems will fall away because Test-Driven Development would catch the silly bugs and if stakeholders change their mind, they will get to weigh the cost of changing their mind before altering something that works.

 Kết quả hình ảnh cho testing process

I would recommend an iterative (every 2 weeks or maybe 3) process where the developers are testing before they say their code is ready and the tasks/bugs that make up the body of work are both large and small but always high in value. That means, in part, developers have to know what they are building against and to have UAT feedback come back to them through a Product Owner (the singular person who approves the list of features and bugs that are coming in the next release and has final Product signoff).

I would also mandate a versioning tool like Subversion properly where you do not create a fork until there is a release or spawn a separate effort that will not be merged again down the line. Without proper version control, you can track bugs and issues all day and it will be rendered an exercise in futility if the software is not versioned correctly. There is a marked inability to define what code is shared and what code is not. Some like to track the version of the software where they found the bug. I find that annoying because we are moving forward, always.


Bugs: There are a billion tracking tools out there. I like any of the automated tools besides Trac (meant for developers, when you look at who winds up using it). The main things we want to capture as a team where vendors have an appropriate level of visibility into the open issues and the ability to assign items (again, keeping the power within the Client instead of the black box of “we understand and you will see it next build”) are present in all of them, by and large. Again, ask a friend. For bugs I think small teams can use Excel but like the workflow and quick views as well as processes that can be enforced by many bug tracking systems.


Identity Field: May was not visible to the user of an automated system, but if possible, I like to show it for purposes of quick reference.


What caused the bug? Evidence, like narratives, screenshots, are important and maybe even critical. If it cannot be reproduced, it should not be presented as a bug unless it cannot be reproduced on another machine but can be reproduced on a singular, or set of, machines. This would be the place for Brower type, version, OS, etc (if needed).


What can we call the bug? A summary of what is wrong.


Who owns it? If it is to make the entry in the tracker more informative, to gather more information, to approve in an approval queue, or to fix, this “owner” may be almost any type of team member. Product Owner will or should give the final approval that it is not active.

Monday, December 24, 2018

,

Explore Android Operating System: Architecture and Frameworks Side

Android, many times we all have heard about this, but few only know that what is actually an Android is? now this time we are with each and every detail of Android. Android is actually an Open Standard Platform for mobile devices, was released from Open Handset Alliance.


What is Open Handset Alliance?

Open Handset Alliance (OHA), dedication of several companies which includes Nvidia, Qualcomm, Samsung Electronics, Sprint Nextel, Texas Instruments, Broadcom Corporation, Google, HTC, Intel, LG, Marvell Technology Group, Motorola and T-Mobile was revealed on 5th of November, 2007, with their main aim as to develop Open Standards Platforms for Mobile devices. (Wikipedia). As the formation of Open Handset Alliance takes place, along with that Open Handset Alliance also released their first Open Standard Platform for Mobile devices, named Android which was built on the Linux kernel version 2.6.

What is Android?

Android is essentially a mobile operating system, or a platform for mobiles that includes an operating system following with middleware, and key applications. Android was developed by Android Inc., which was later renowned by web giant Google, which was further renowned by Open Handset Alliance. Android provides various tools and APIs to the developer, for developing applications on the Android platform by managing the code in the Java language. The release of Android was officially announced under Open Handset Alliance, a syndicate of hardware, software, and telecoms dedicated to open standards for mobile services. Google reveals many Android codes under the Apache License.

Features
  • Android is adaptable to larger The platform is adaptable to larger, VGA, 2D graphics library, 3D graphics library based on OpenGL ES 1.0 specifications.
  • Android enables users or developers to reuse and replacement of components.
  • The Database Software SQLite for structured data storage.
  • Android supports GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, and WiMAX.
  • Android supports the MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF audio, video and still images formats.
  • Android is based on the open-source WebKit application framework. The browser scores a 93/100 on the Acid3 Test.
  • Android is hardware dependent with Camera, GPS, compass etc.
  • Android includes  SMS, MMS for messaging including threaded text messaging.
  • Android also includes Integrated browser based on the open source.
  • Android includes a device emulator, various tools for debugging, memory and a plugin for the Eclipse IDE.
  • Android also supports Multi-touch feature which is now available on the latest HTC Hero.

What is Android Architecture?

 

Hardware running Android

The first Android supporting mobile was HTC Dream, brags out on  October 22nd, 2008.
And according to Google, there are around 14 models which were supporting Android worldwide successfully. Some users with some sort of hacking or by unlocking the device they are able to install Android on the handsets which are not coming with Android. Up till now, there are many Handsets available in the market with Android, such as HTC Hero, Nexus, Motorola Droid and many more.

Application Framework for Android

Android being an open development platform, it allows developers to use their hardware to the level an developer can, or to build his own innovative applications he needs. Developers are totally free from hardware side to work in the manner as he wants like running backgrounds services, adding notifications, reminders and many more applications which a developer needs.

Android gives developers full access to the same framework APIs used by the core applications. Application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user. Attractive views are allowed by the Android to build an application, including lists, grids, buttons and web browser also.  Sharing can be easily done by Content providers that enable applications to access data from other applications such as contacts etc.

All Alerts are displayed in the Status bar with the help of a Notification Manager.
The Lifecycle of an application is managed by the Activity Manager and provides common navigation.

Access to non-code resources such as localized strings, graphics, and layout files are possible with the help of a Resource Manager.

Libraries

Android includes C/C++ libraries for various operations that are to be performed by the different components of the Android operating system. These Libraries are exposed to developers by the Android Application Framework. Some Libraries are as follows:
  • SGL- a 2D Graphics engine
  • LibWebCore- it is the modern web browser which enhances the power of both Android browser and embeddable web view.
  • 3D Libraries- an implementation based on OpenGL ES 1.0 APIs, and included highly optimized 3D software rasterizer
  • Freetype- rendering of Bitmap and vector font
  • SQLite- it is a database engine available for all applications
  • System C Libraries- a BSD-derived implementation, tuned for embedded Linux-based devices or models
  • Media Libraries-  depends on PacketVideo’s OpenCORE
  • Surface Manager- manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications

Android point in time

Android includes a set of core libraries that that avails maximum functionality available in the core libraries of the Java programming language.

Each and every application of Android runs its individual process, with its individual instance of the Dalvik Virtual Machine, because of this device can run multiple VMs efficiently. The Dalvik Virtual Machine executes files in the .dex format which helps in minimal memory footprint. The Dalvik Virtual Machine is register based, which executes classes compiled by the Java language compiler that is transformed into the .dex format by the included ”dx” tool.

If you Like This Post Please Leave A comment

Sunday, December 9, 2018

, ,

Top Reasons Why Agile Adoptions Fail

Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project. Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product. Agile methodologies consist of 4 major roles which are the product owner, scrum master, developer and end user. 

Mistake to avoid

1. Lack of communication and trust

 

Lack of trust among members will kill any team project. In the agile methodology, there are multiple dynamic pieces and members need to work together with new features on a week-to-week basis. Thus, this may result in miscommunication between team members. Moreover, to ensure that the ideas and requirements from the client are clearly passed onto the development team, both the client and developers should work closely together. If there is a lack of transparency in client’s requirement, developers will produce an application that is far different from the one the client had in mind. Therefore, it will not be labelled as a success. Hence, team project developers should commit to realistic deadlines and work together to achieve common goals.

2. Resistance to change


Change is the only thing that is consistent and software developers know about it more than anyone else. Changes may appear during the development process such as new ideas, ways to build an application or ways to achieve certain objectives. There are two methods used in software development: Agile and Waterfall. Agile method is more flexible in structure and allows change and redirection. Agile may take times to get right, however, by acknowledging the issue that other organisation faced, they can take it into account. On the other hands, the Waterfall method is more linear and does not accept any changes in the development process. Which means each step is completed after the other and cannot be returned. 

3. Poor leadership


In any team, strong leadership is extremely important for managing project. He should have skill, knowledge, and experience of leading in order to eliminate any obstructions arise during the project. Moreover, the leader is the person who interacts with the end users and the developers, guiding them toward the needed business solution.  

4. Lack of experience with Agile


According to a survey by VersionOne in 2016, one of the main difficulties in adopting agile method is lack of skill or experience with agile methods (41% of respondents). Based on the survey, one of the possible causes may be the lack of training in agile methods and techniques. As researched, teams tend to run into trouble if they are deficient in the ability to apply basic practices. In order to solve this problem, companies should invest in foundation training in agile techniques. 

Monday, December 3, 2018

,

Top 7 most frequently asked AWS developer Interview questions

When looking for a cloud computing job, you will need to prepare for a set of questions that can guarantee a successful job interview. These are the most frequently asked AWS developer interview questions that you may encounter if you would like to become an AWS Solution Architect.


1. What do you understand by AWS?
This question checks your basic AWS knowledge so your answer should be straightforward - you should define what is AWS as well as the characteristics of the services of the platform.

2. What are the main elements of AWS?
This is one of the most frequently asked AWS developer interview questions. Just get the interviewer mind and answer accordingly either with components name or with the description along with. - Route 53; S3; SES; IAM; EC2; EBS and CloudWatch

3. What do you mean by AMI? What does it include?
It is very likely that you will meet many questions about the AMI at the interview, so you may want to prepare a pretty good knowledge about this subject. Define what is AMI as well as the key features, and the components of the AMI.

4. Is vertically scale is possible on Amazon instance?
The answer is Yes - it is possible. If the interviewer want a more detailed answer from you, just explain the procedure for vertical scaling.

5. Can you define the connection between AMI and Instance?
Many different types of instances can be launched from one AMI. The type of an instance generally regulates the hardware components of the host computer that is used for the instance. Each type of instance has distinct computing and memory efficacy.

Once an instance is launched, it casts as host and the user interaction with it is same as with any other computer but we have a completely controlled access to our instances. AWS developer interview questions may contain one or more AMI based questions, so prepare yourself for the AMI topic very well.

6. What is the difference between Amazon S3 and EC2?
At any AWS developer interview, you should prepare yourself with the concepts of Amazon S3 and EC2, and the difference between them. You can tell the difference between S3 and EC2 based on these criterias: Definition, features, requirements to run a server,...

7. How many storage options are there for EC2 Instance?
Amazon EC2 is the common topic you may come across in an AWS developer  interview. Get a thorough knowledge of the EC2 instance and all the storage options for the EC2 instance. For suggested answer, your response to the interviewer should fully cover the four storage options for Amazon EC2 Instance, namely Amazon EBS, Amazon EC2 Instance Storage, Amazon S3, Adding Storage.

We have compiled a list of most popular and most frequently asked AWS developer interview questions in a typical interview for a AWS solution architect job, as well as the suggested answers for those questions. Different interviewers may have different set of AWS developer interview questions, it depends on the characteristics and requirements of the jobs at the company you are applying for. However, once you have prepared carefully for these questions, you can totally think about the prospect of a successful interview.

Thursday, November 29, 2018

What is the most important of Agile Method?

It is true that within Agile method you have the notion of being free of a set method and allowing the team to decide. I have heard all the arguments. Some say the team will not decide. Some say it does not work. Some say it works under certain conditions. Some say it works but only if the organization is ready. Scrum, by being a formal methodology, automatically negates what is at the heart of the Agile Manifesto and the Agile Manifesto is regarded as a kind of 10 Commandments of Agile Development but the truth is something altogether different.

We did Agile development before it was called Agile development. My coining a phrase, you create an entity (real or not – you have heard of a Unicorn, no?) and by setting forth a method by which to accomplish the goals in mind such as Scrum does you in no way break any tenets.


Agile is not unique to software. Nor is lean, Kanban, or any of the new buzzwords. They are buzzwords. They make enough money and generate enough revenue that PMI is starting to incorporate Agile methods in their PMBOK.

A bunch of guys in a cabin in the woods is not necessary in this day and age and only serves to add to the mystique behind the Agile Manifesto. As far as I am concerned, people who write Manifestos in the woods are suspicious and up to something. Not all of them are planning on blowing something up. Some are just meeting so there will be no distractions. Yeah. Because it requires complete concentration to chase a Unicorn. You cannot do it head on, after all.

I hate to say it, and I will hear about it, but Scrumban and all the over-intellectualization of what amounts to getting work done as a team is a symptom of big brains without enough to do. Or, and equally as valid, are those big brains who see the ability to make money off of the latest fad. It is nothing new, but the buzzwords are. There was always a brownie with less calories. It was not called a Light Brownie until someone marketed towards people who wanted a less fattening brownie. And that is all it is. Less fattening.

I have wondered a bit about why this bothers me so much. In a world that does not seem to reward honesty, why would I insist on calling like I see it? Saying that I care sounds and even resonates a bit hollow because I really cannot care about you if I do not know you.

I guess it boils down to a disdain for bullies. People throw words like punches and get all bent out of shape and worked up because of something as idiotic as what “done” means. Have we forgotten that everything is in context and everything has eyes upon it, therefore perspective, and that there is no judge without an opinion?

Then there are those who think it really is important to define what done is aside from any actually physical project. I will tell you what it is: an idea. A Unicorn.

Get your work done. Inform yourself. Learn. Be wrong once in awhile. Be honest even if it hurts. Scrum, Kanban, Lean, and the like are all meant to take your attention away from what they entail and that is delivering software. I did not say good software. There is no such thing. There is software that does what it is supposed to for some people and not others and there is software that plan stinks because nobody likes it.

Do your best and keep learning and dont let the intellectuals bully you into thinking you need ScrumLeanBan in place. Muda… why do they use a Japanese word? Like the cabin, it makes things more mythical. It is what it is.

Monday, November 26, 2018

,

The Most Reason I Like Making GANTT Charts in Project Management

Okay, so I am at a bit of an impasse. Problem is, I see value in the Agile approach but I also see the need for something tangible to pass around the conference table. Something like a GANTT chart. I hate GANTT charts. They are one of those things that are too easy to make in a meaningless way that satisfies 90 percent of your stakeholders, but to satisfy the other 10 percent, you have to do stuff I don't think can be done (like, tell the future… and if I could I would not be writing this blog… I would be living off of lottery money and dictating the blog entry to someone).

example of gantt charts in project management


I am not talking about GANTT charts that show blocks of development or releases or sprints. I am talking about the ones that show development tasks and dependencies and draw a nice line from the beginning to the end. David Christiansen says:

Gantt charts look cool. The ones I can make using MS-Project show task names, durations, assigned resources, and milestones. All in color…in whatever fonts and fill patterns I want to use. In my experience, few things about a project proposal impress people so completely as a really nice-looking Gantt chart. Sad, but true.

ASSUMING you have adopted some flavor of Agile, you could, of course, produce these charts with a lot of wiggle room by organizing them in blocks that are understood to be malleable. However, this is not what a GANTT chart is supposed to be. At least, not classically. I am all for breaking new ground, but the 10 percent I mentioned before will be of two types:
  1. Where is the detail?
  2. Why are you making GANTT charts?
In case (1), they will also want to know “how much and when”. In case (2), they will want to know how much and when but understand you are not building a shed with supplies from Home Depot.
You will have to read what Ambler says about GANTT charts on this cached page, but to save you the trouble, he came to find they are regarded as the least valuable project asset.
I am a fan of educating Clients. Agile works, although for me it can be a bit cowboyish without a good leader on the team. Accordingly, I try to be that leader and explain THE PROCESS without sounding condescending, preachy, or singing. I tend to break into song when discussing THE PROCESS. It is majestic, after all.
Recently, I learned a nice lesson, again (and this time it will stick, truly). Education is great, but among the people, you are educating needs to be the person who sits at the conference table waiting to flip out when what may be perceived as ambiguities cost money. It is not even education, now that I think about it. It is more explanation. So, THE EXPLANATION needs to reach the right ears and mind. THE EXPLANATION makes sense. THE EXPLANATION is no good if it is on some random PM’s notebook and the CFO says, “I need to know when this project is going live and how much it is going to cost by end of the day! Why don’t you know this? And don't give me that EXPLANATION!”

So again, this stuff all starts with people, not technology, and not THE PROCESS. It might not always be easy to do, because the people at the conference table are often busy, but you really need to reach them, even if indirectly.

GANTT charts are also BRUF and detailed specifications for System features that are a glimmer in someone’s eye. Now, maybe BRUF is bunk, but RUP, or better, what has been termed GRIT, has value. Even if you are going into a cave and know you don't know which way it will twist or turn, you bring a flashlight and good boots (I guess… I don't know much about spelunking).
The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high-level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.

Thursday, November 22, 2018

, ,

The Anatomy of Agile Software Development Methodology


There is something kind of funny going on right now that I can’t help but notice. Agile development has real traction after being around for over 15 years and various flavors of the agile theory have manifested as shrink-wrapped development methodologies. I would argue that there is an attempt to eclipse the role of the project manager with that of the scrum master.



Big Mistake or Noteworthy for Agile Movement

I happen to think this is a big mistake in most cases but could be viable in a small instance of circumstances. Like PMI created the PMP, the Agile movement is producing its own collateral materials. This is not bad, but it is noteworthy. It is a little industry now, with substantive artifacts, proven success, and mention in mainstream journals, etc.  I am grateful for this, as I am grateful for anything that makes developing software more disciplined.

Actual managers and salespeople, like the one pictured to the right, like to tell each other that their development team is “doing Agile” even if they all they know about development are that developers do it. I think by now, because of all the questions that the notion of agile development mandates, they know better than to think it means people are lithe and quick, jumping over hurdles as they code.

Agile based Team



Still, you will notice that the manager in question seems to be insecure about something. Look at the eyebrows, notice the uneven, forced grin. He is faking it. Clearly. I happen to know this fellow, and he is not thinking about agile teams, but I owe him some publicity at the very least after all he has done for me.
Anyhow, there is Agile with a capital A. Wittgenstein and Russell would refer to this as a Universal and note that they do not exist in actuality. All that exists are manifestations of Agile; agile practices that are in play are real, while Agile theory remains an amorphous object of study, though, and guest speakers.
Recently, I heard someone on Twitter say that this other person’s team was not an agile team because they did not use story points. This is just an example, and there are others. I have been told that a team I worked with was not agile because they did not have 2 week long sprints. We did UAT every 5 days.

Why User Acceptance Testing



There is a reason we did UAT every 5 days, and there was a reason, I am sure, that the Tweeter did not use story points. The fact is, I would have to explain the notion of story points to the more “mature” developers who are used to coding against a thick spec and more often than not, the learning curve comes at an inopportune time.

This is especially true at small software development companies who cannot send their development team to training. So, we have daily stand-up meetings and do the whole “What did you do, what are you doing, what’s in your way” thing. I tend to *expect* that scrum masters know that asking the questions is not enough and that they are there to grease the wheels where they can and remove obstacles if possible. Maybe they would even recognize patterns if they are truly sharp. However, this is also more theory than practice.

 I have seen scrum masters behave in a way other than they were taught when they paid for their ScrumMaster certificate. In some cases, the developers were so on the ball that they removed their own obstacles. Valid? Sure. They cranked out releases on a regular basis and had happy clients, useless PMs that they ignored, and did what was almost development ballet. As to my UAT every 5 days, it was in the contract. Do any of these things mean that our teams are not agile?
No. There is no litmus test. There are best practices, but even they are subject to context and interpretation.

Should Move toward Agile?

Agile development is based on a manifesto and foremost, people over process. Change hurts, and moving towards Agile can be painful, but the Barely Good Enough principle applies here, I think. While Ambler may have taken it a little far with the Agile Unified Process, I do like the more practical idea that what is just barely enough is actually optimal.
How many million dollar projects will not have a CEO or Manager among the stakeholders who will expect or even demand to see an old-school GANTT chart? Most of the ones I have worked with do in fact want this. Now, regardless of what our development methodology, I can deliver artifacts that are required. Agile would tell me that this is useless and waste. Not true. The relationships (people) is at least as important as the process. Again, building software services is not just about sitting devs at their desks, having daily meetings, and forming burn-down charts, velocity graphs, and backlogs. It is amorphous, involving everyone from the insecure manager mentioned at the beginning of this post to the happy, secure, million-dollar smile manager pictured to the right.

Practice Agility

My point is this: anything that adds value is worth it. Anything that improves without causing undue pain is worth exploring. If *only* doing a daily standup enforces accountability yet nobody has heard of a sprint, what is wrong with that? It is a place to start, and it is inspired by Agile, which is inspired in truth by what is practical when dealing with the slippery devil that software development can be. I know when my wife goes out, I am calling her every hour (I am getting better). This is because I know there are lots of variables out there that need to be taken into account and checking in never hurts (part of why I am getting better is because she actually *did* hurt me with a frying pan after I bugged her all night, but I digress again).
Don’t try to be Agile. Actually, practice agility. Study Agile methods, but practice agile techniques. The CMMI for Agile environments is interesting in that it doesn’t appear to assume a particular flavor of Agile. I am not a fan of XP at all, although I have worked with developers that rock with peer programming. That was them, and part of my toolbox is a lens that lets me recognize value. I let them rock. Of course. It was cool as can be and I learned another face of Agile. I love being around people who know more than me and are smarter than me. It isn’t usually hard. Still, the point is that no one way is right and no one way is complete or incomplete. Everything is in context.

Spread the word and share:

Monday, November 19, 2018

These Software Development Facts You Should Know

Agile Development is subject to all kinds of theories, including my own (which is really a mishmash of what other people have said and what other people have did – I cannot pretend to have walked down the mountain with stone tablets dictating the Commandments of Building Software and I think the Agile Manifesto – the first page at least – is common sense).

Yes, a lot of this stuff is simple but taking the simple and fine-tuning it for a specific environment takes discipline and skill. The traditional project manager blankets a methodology over a project and tucks it in here, loosens it there. They are nervous right now, except in large organizations where silos hold the place up (and those same places will be overtaken in my opinion by leaner, more Agile, more realistic and “human” organizations).



Agile, in my mind, is undergoing a bit of a transformation at least in part to Mark Kennaley’s book: SDLC 3.0 Beyond a Tacit Understanding of Agile.  It turns out that the “Waterfall” approach is an erroneous interpretation of a paper from the 70’s.

At least, I will try to not assume one or the other before going down a mental path. As a side note, mostly for Scott Ambler, I do not think that calling someone a Certified Scrum Master implies superpowers any more than calling them a Scout Master or Master of Ceremonies does. People are not silly enough to accept things without asking questions, although I have had HR approach me saying they want a CSM with 10 years of SharePoint 2007 experience. HR is a different animal.

We want to be in the middle somewhere but above all else, I believe we (as Clients) want to be the place where the information is and the center of collaboration. The Client organization, if possible, wants to be the “Single Point of Truth” for both documentation and process control. That is the knowledge that will be invaluable at some point and it will prevent obfuscation. If a vendor already has something like Bugzilla mastered, you want a login. Do not force change where it will not be helpful, please.

The funny software developers call bugs “features” and I guess after 20 years that is still funny. I prefer separating bugs from issues at least in category buckets myself because then the difference between them becomes more obvious and they are handled differently. If math is being executed and addition is inaccurate, we have a bug/issue but if we are not sure if interfacing with an overseas payment processor is possible without their being PCI audited, that is an issue. An issue I actually encountered not too long ago: a development shop wanted to build a RoR font end on top of Ektron.

This was one of those delicate issues that were tracked offline. As with most things, our objective should be to prevent the disease instead of band-aiding the symptoms. To do that, you also need visibility into the overall project health. You do not need granular detail, but if you know that we have 100 units of stuff to fix last week and this week we have 140, things are not getting better.
This concept of assigning points to features can be applied to bugs as well.

It is all is the estimate and difficulty level. You wind up getting a very visible “velocity” over time where you can see time on the X-axis and total open points of the Y-axis… you want that line to wind up at zero by a date you have in mind or, more realistically, let it tell you when you will hit zero and adjust the feature/bug (product backlog) accordingly. A tell-tale sign that your vendor is not as familiar with bug tracking or issue tracking is, in my opinion, if their unique identifier (ID) changes or if both entities are tracked in the same manner. The idea of velocity and the multiplicity of velocity is staggering. It does not simply apply to Scrum burndown charts.

What is its Business Impact?

From low to high and “showstopper” with numeric values attached to the single decimal point. I maintain that with every bug there is associated Business Value, Difficulty, and User Value. These things are not obvious to the tester but they are to the Product Owner. They combine, via simple math, to give a final value. The “showstopper” assignation is there to really propel the bug’s value into the stratosphere. If low is 1 and high is 3, the showstopper is 100. How severely will this impact the business if it is not resolved by go-live?

What is it’s User Impact? Like Business Impact in the calculation, but answers the question: is this just annoying, or does it require a disturbingly complex UX?

How hard will it be to fix? This is often a tie-breaker between bugs when creating the next iteration of work and is also potentially an indicator of weaknesses in the team.  I like it when these are estimates or are story points.

Status: Unassigned, assigned, UAT, accepted. You can add or remove as you choose but I like this foundation. When in UAT, it is waiting for Client approval. These should be no bugs that depend on other bugs if possible, and if a bug can be broken into separate bugs, they should be. Open is vague and not required. If it is assigned to someone or a group, it is not closed.

It makes sense to run through bug priorities as time allows to be sure that their values have not changed. If functionality has been cut out, those bugs will have less Impact. However, one bug does not lose value simply because 8 other high-value bugs have been found. New functionality should *not* be added until a development team that is constrained by resources can catch up. It is better to have 50 percent of the features complete with 50 percent buggy than 100 percent of the features unusable. Maybe the System cannot be used with 50 percent functionality, but you have value in your pocket there and have paid for something that can be moved to another vendor, another release, or re-purposed or sold. Always try to retain rights to and a copy of your source code in your contracts involving custom development. Otherwise, with a new vendor, you are better off starting over. Earned Value will be nil. This is only one of many reasons why “percent complete” is a false indication of anything. Others include that the task/bug changes has facets revealed that were hidden before, and are as apt to change as anything else.

When a bug is introduced, anyone can introduce it. The default owner should be the Project Manager / Coordinator / Technical Liaison, or whatever the role is called. The Product Owner may also do this but are better off using their time in other ways. This is where the traditional Project Manager can breathe a little sigh of relief amongst all the talk that Agile and Scrum are making the PM role irrelevant.

The Project Manager, in a technical setting, should have knowledge of technical systems. They can and should work with the Product Manager to tune value and assign bugs or issues after they are introduced into the System. However, the project manager does not assign to a person. People come and go. They get hit by the proverbial bus. Bugs and tasks are assigned to groups, such as “Development” and then divvied up within that group (hopefully using the same tool) so people are mapped to bugs and there is a face at the standup who will be speaking about it.

Also, much as we get a sense of project velocity, we can get personal velocity. I say that and bite my lip because there is always the “X factor” leaning on everything we do and using pure metrics to ascertain the value of a person is bad, bad, bad, and horrible. This, again, is where the classic project manager could be knowledgeable. You may notice that I am mixing and matching Scrum terms, Agile terms, and more common terms to describe roles.

That is not without reason. There is a basic methodology-independent rationale here: keep track of things, limit dependencies, keep visibility and communication high, and stay flexible. Look at what work there is to do and compare it to your deadline instead of trying to shove 10 pounds of tasks into a 5-pound box.

How is a bug tracking system working

  1. Reported By
  2. Date Reported
  3. Owner (defaulting to the PM/Technical Liaison)
  4. Summary/Description
  5. Acceptance Criteria
  6. Supporting Documentation (documents with screenshots, etc)
  7. Site/s
  8. Business Value (1-10 or 100 with one decimal place)
  9. User Value (1-10 or 100 with one decimal place)
  10. Technical Difficulty (high value means it is more difficult and risky… a risk mitigation worksheet is already available and complimentary).
  11. Status
  12. Date of Status Change (so if something lies around for a week, for instance, it is obvious).

Wednesday, November 14, 2018

2 Easy Ways to Show Percent Complete in Agile Method


1. Plain old Metrics

The above is pretty easy to understand, but the percent complete field comes from the total number of story points in a given feature (the pure sum of the points belonging to stories within a feature) and the number of points for features that have had all stories complete.

There is your number, viola. Is it accurate? As long as nothing is added to the feature, sure I guess it is as accurate as anything can be given context. The better question might be “is it wrong or misleading” and the answer would be “depends, but you are not lying or misrepresenting what you are being asked for.” If I ask you to poke me in the eye, you might do a really good job at it and blind me, but does that mean you completed a valid task? Depends on who you ask, their mental state, their goal, and a number of things but overall – yeah, you did. Thanks a lot.

2. Colors…

People like colors. With this method you get not only more detail but what might be a more accurate (or complete) view of what is complete. Your “not started” line will look smaller, but that is not a function of misrepresentation, only of the technique. “In Progress” might mean it just started or that it is almost done, but it is just a tool.

Something besides Excel would be better than this, as the legend states (may a .mpp format although your PMPs might freak) because your Story Points could be numbered left to right with a degree of accuracy that I cannot provide at the moment. Again, the goal is the same. You get the block which represents features but the WIP (Work In Progress) exists as something real and tangible. For the overall Epic, you could, in theory, have a giant list of these that together spelled out the whole shebang and I do expect this may only serve to elicit “so, how close are we?” at which point you can either stare like a gopher who just popped his head out of his hole or be almost as cool as a quick draw cowboy and whip out the first diagram.

Friday, November 9, 2018

,

Why PRODUCT ROADMAP is so IMPORTANT in AGILE DEVELOPMENT?

What is product roadmap in agile development?

In order to achieve a goal, you should always work with a plan. A product roadmap is an outstanding action plan which construes how the product is expected to evolve over time. It allows you to express where you want to take your product, and why it is worthwhile investing in it. Moreover, an agile product roadmap expedites the learning curve and adopts reforms. A goal-oriented roadmap focuses on project objectives, business goals, and outcomes like customer acquisitions, augmenting engagement. In simple terms, a product roadmap initiates the emergence and development of a product or solution to a project.

 Technology is rapidly changing which means new and unexpected markets will open up. With upcoming markets, business will boom or suddenly drop, and all of these changes will affect what you are able to build both in the short- and long-term. In addition, you cannot exactly know what you are going to build ahead of time, however, you can plan for how to respond those changes in order to keep on track with your innovative vision. Product roadmap encourages the project team to work together to achieve long-term goals for successful project delivery in agile development. For this reason, a few agile teams tend to share a unanimous product roadmap. A roadmap is not a plan that you develop once and adheres forever. The plan remains agile which means brainstorming, prioritizing ideas, discussing and adjusting your process roadmap is needed when the environment changes.

Reasons why product roadmap is needed in agile development?

Make adjustments during long-term plans

For example, like airplane instruments, a good roadmap will tell you if you have reached cruise altitude or if the product’s engagement needs to boost. In order to do so, you should compare your current metrics with the ones you have previously defined with your team when building the roadmap. Base on what you have found, your team can refine the features, sprint’s goals, make decisions based on data or, at least, realize sometime in advance that some desired outcome is not going to be achieved, enabling you to activate your plan B. Otherwise your team is just working sprint after sprint with no acknowledgment about the impact of its work on the business.

Roadmap connects pieces into a big picture

 
It is much more motivating to know what your team is going to deliver as a whole. This is where the real meaning of work takes place, instead of just delivering tasks that were assigned to you through your team’s board. Moreover, the roadmap should be accessible and visible on a daily basis, so everyone can take a look at it every day and feel the importance of their hard work.

Clarifies priorities and improve setting


Another important skill that a product team should know is the ability to reject. Because users are going to make requests, stakeholders are going to have opinions and even the CEO of the company may issue some special feature requests. However, if you are going to satisfy all of them, you will not do any good for anyone. In order to refuse requests that are not related, you should have a clear vision about what you are doing.

Product roadmap motivates the team



There are a lot of technical issues and things that go wrong when delivering a feature. As a consequence, the motivation to work and overcome will decrease. To avoid these problems you should have a clear vision of what is going on and the importance of it.

The clear vision for stakeholders


The product roadmap will help you to avoid as many meetings as possible. Nowadays, we are working in an agile environment and we do not have to report the status of the task to stakeholders. However, your product is a part of a bigger company strategy. Thus, goals and progress towards it must be accessible for everyone in a company. Moreover, if things will not go as expected, you can adjust it. Finally, it creates a sense of collaboration with everyone involved.

Monday, November 5, 2018

,

Difference between Quality Assurance and Software Testing


What is Quality Assurance (QA)? What is Testing? 

These are common questions for those who first go into the software development industry. It is particularly important for software managers to know the differences between these two terms as they could help in risk management during the software development process. Below is the definition of each term:
  • Quality Assurance includes activities to ensure the quality in the software development or maintenance process in order to ensure the software will fulfill its ultimate objectives.
  • Testing includes activities of executing a system in order to find bugs/errors/defects in the software.
Basically, there are 6 stages in the software development process: Planning → Analysis → Design → Development & Implementation → Testing → Maintenance. The software testing stage is considered the most important one in the process. QA Leader and Test Leader are the key members of the team, who have the clearest understanding of process and methodology. QA Leader is considered the captain of the ship. Meanwhile, Test Leader is QA Leader’s right hand who has a clear understanding of not only the software development process but the customer’s requirements as well.

It’s is absolutely crucial for the QA Leader to have a deep understanding of the testing process, data management, trouble reporting, and resolution and ensure the software will be given to the customers with high quality, on schedule and satisfying their expectations. He/She will be responsible for:
  • Defining quality metrics.
  • Defining testing strategies.
  • Deciding the test budget and planning the entire testing process.
  • Identifying the testing activities for other team members like testers or test engineers.
  • Checking the availability of the resources to execute testing activities.
  • Managing Risks.
  • Reporting to the project manager.
The Test Leader is responsible for organizing and examining the testing process to ensure the high quality for the software. Those are their tasks:
  • Defining the scope of testing
  • Staying updated about the latest test approaches and tools.
  • Validating the quality of the testing requirements such as testability, test design, and script, test automation, etc.
  • Implementing the test process.
  • Writing summary reports on test status.

Conclusion

A number of people are still confused about the difference between quality assurance and testing. In fact, they are closely related but have some considerable differences that I have mentioned in this blog. However, they are both absolutely necessary in the software development as they ensure the final high-quality product will be delivered to the customers.

Thursday, November 1, 2018

,

Why Software Testing plays important role in software development?

We all make mistakes, some of those mistakes are unimportant, but some of them are expensive or dangerous. We need to check everything and anything we create as things can always go wrong – humans make mistakes all the time. That’s why, software testing is an indispensable part in any project.



What is Software Testing?

Software testing is the process of executing a program or application for the purpose of finding software defects. In other words, it is the process of validating and verifying that a software program, application or product is functioning properly, or meets the customer’s business, technical, design and development requirements or not.

Read more:

Why software testing is important in software development?

Since we assume that our work can be wrong, so all we need to do is test our work. However, some mistakes come from bad assumptions and blind spots, so we can make the same mistakes when we examine our work, as we do and have done. it. So, we can not see the mistakes in the process.

Ideally, we will pick up someone else to test our own work. Because they are likely to be more likely to spot our mistakes.

There are a number of obvious reasons for us as to why software testing is important and the main things that we should consider when examining any product or application.

So, why is software testing important? Some of the reason are listed below:
  • Software testing is really necessary as it points out the defects and errors that have been made in the development phase.
  • It is important because it ensures the reliability of the customers and their satisfaction in the application.
  • It is very important as it ensures the quality of the product. Quality products delivered to customers help in gaining their confidence. (Know more about software quality)
  • Testing is necessary as it provides facilities to customers such as delivering high quality products or software applications that require lower maintenance costs and thus results into more accurate results, appropriate and reliable.\
  • Testing is required for an effective operation of the software application or product.
  • It is important to make sure that the application does not have any failed results, because it can be very expensive in the future or in the later stages of development.
  • That is the essential requirement to help the product survive in business.
What are the main goals and objectives of software testing?
  • Software testing has different goals and objectives. But its main goal is:
  • Find defects that can be created by programmers when developing software.
  • Gain confidence and provide information on quality level.
  • To prevent defects.
  • To ensure that the final results meet the business requirements and users.
  • To gain the credibility of the customer by offering them a quality product.
Software testing will help to complete the software or product applications versus business requirements and users. It is very important to be able to guarantee to test the software application completely and make it sure that it works well and according to the specifications

Wednesday, October 24, 2018

,

TOP 5 Manual testing interview questions with answers you SHOULD KNOW

Manual testing interview questions are the questions that you may encounter when applying for a developer job. In this post, we will cover some popular manual testing interview questions as well as the best answer to these questions.


1, During testing, you find a bug and assigned it to developer. But developer rejects the bug saying that it is not a defect. How you will handle this situation? (one of the most challenging manual testing interview questions)

First of all bugs should be logged with proper reproducible steps, screenshots etc…
If developer rejects the bug, we should first look out for the reason or justification on why the bug was rejected. If the justification is valid I would agree for the rejection. On the contrary, I will go back and try to reproduce the bug with the steps I had provided earlier. If it is still reproducible, I shall reopen the bug with valid comments and will provide additional information (if I found any). Then I would go back to the developer asking for justification on the rejection. At this point I shall include BA and technical lead also is to take confirmation on the defects

2, What is your approach in case there is not enough time for test execution?

In that case, my first focus will be on the priority of the requirements and the functionality would be the first tested, followed by the areas where the probability of finding defects is high. I would also analyze by test cases and execute the high priority test cases first followed by medium and low if time permits. If I know the application well and have previous experience about it, then exploratory testing is a good approach when there is limited time left. All these should be approved by the Test Manager and documented in the test strategy. 

3, What is exit criteria of testing? / When to stop testing? (This manual testing interview question is the easiest question to answer out of the 5 covered in this post)

It is almost impossible to make sure that an application is completely defect-free. At some point the testing should be stopped and we have to give a sign off so that the application can be released. The exit criteria of testing will be mentioned in the Test Plan before testing itself. We consider a lot of criteria to decide when to stop the testing. All the defects have been addressed and closed, all the test cases have been executed, traceability metrics is done (which means test cases have been executed for each of the requirements). Some factors should be considered for stopping the testing.

4, Have you written any test plan? What are the contents of test plan?

(Yes I have been involved in writing test plan). Test plan will contain the scope and all the activities of testing. The main contents of test plan is the scope, approach, resources and testing schedule. In testing scope we will say the testable and non-testable functionalities. In testing approach we would mainly mention the testing environments, different kinds of testing, testing cycles, the test cases which will be executed, testing data and scripts.…It will also say the test entry and exit criteria. Which means when testing will be started and stopped. The roles and responsibilities of each resources would be mentioned and testing schedule and timelines are also mentioned in the test plan. In addition any risk/assumptions and dependencies are also mentioned in the test plan. 

5, Have you done any reviews for QA deliverables?

(Yes, I have reviewed QA deliverables mainly test plan and test cases). QA checklist is maintained for each of the deliverables and the reviews will happen against the checklist. First of all, I do a self-review for all the deliverables that I prepare. Then I would give it to my team member for peer review and vice versa. Before the review, walkthrough of the document is done for better readability. All the test cases and test data is inserted, risk and dependencies are described etc… During reviewing test cases I will first check the requirement traceability, which means for each requirements if the test cases are available. Next my focus will be on test coverage. I will check of all the scenarios have been covered etc…

Above are some of the most popular manual testing interview questions and some of the best ways to answer.